• June 19, 2025
• 5 min read

2025.06.19 - OS2.0 Meeting Notes

Attendees: Corwin, Jason, Jeff, Sofia, William Purpose: Jeff called meeting to discuss hosting and programming.

Action Items

• Corwin:
  • Present the request to resolve project ownership to Aradia.
    • Suggestion list: Jeff, JD (CA), William.
    • One of these folks can add others as members of the group.
    • Currently everyone is some form of external contributor (repo-specific).
    • Easier discuss/setup now vs after there are lots of contribs.
• Jason:
  • Continue working on OAuth.
• Jeff:
  • Secure funding for hosting.
• Sofia:
  • Create proposal to move domain from SquareSpace to a better registrar giving options. Upload notes.
• William:
  • Upload notes.
  • Continue documentation development.
  • Write crontab to automatically archive Git repo and run git clone.
  • Explore unit testing.

Notes - Sofia

Github Ownership

The issuer of github project 'ownership' was discussed. The major concern raised was that 'ownership' being consolidated to one person presents risks and limits productivity. A point was made that as an open source project 'ownership' is more symbolic, but on github it is signifigant for managing a repo. A consensus was reached that addition 'owners' should be added to the project with Jeff and William being good candidates. Corwin volunteered to present the request to Aradia, but requested that the team makes a plan and we resolve funding hosting first.

Github vs Selfhosting the Repo

The team discussed the benefits and risks of self hosting the repo vs using Microsoft owned GitHub. The major concern being that Microsoft could be pressured to remove the project. Reflecting on past Microsoft actions against projects like 'yt-dl' shows that it is a real threat. Further discussion lead the consensous to be that is an ulikely threat and would likely cause a 'Streisand effect'. Consensus was reached to keep the project on GitHub, but to avoid becoming dependent on it's proprietary features.

Security Methodology

The topic shifted to risks more generally. Sofia raised a question 'what are the easy opportunities to improve security?' Corwin made the case for a 'Formal Risk Analysis Program'. That should follow principles of not invent things, simple principles, and layered principled tech. (?) And that the process should flow from policy to practice to review.

Adminstrative Productivity

Sofia raised the question of how to collaborate on documents and spreadsheets and inquired about alternatives to google apps. Jeff suggested Proton which is a secure option for private documentation and free. William suggested Github Pages which they setup recently. - https://github.com/GS-US/strikecard-backend/deployments/github-pages A general concensus was reached that if private documents are generated we should like to them in some form of public documentation. Corwin suggested a tool they are self hosting for ephemoral documents, but to not share it publicly - https://www.pad.bru.st Consensus was reached that for emphemoral or private docs proton would be the likely best choice. Finalized public static documents should be uploaded to github pages. - https://github.com/GS-US/strikecard-backend/tree/main/docs/blog/posts A general data policy was suggested with three levels of secuirty. Restricted - Need to know, Sensitive - Right to possess, and Public - General Access That concept needs to be examined further in the future and codified.

User Authentication

The question was raised should user authentication (for facilitators) be handled server side or a service like OAuth implimented. Server side would be simpler and less secure, OAuth more complex to setup but more resilient to a compromised system. Jason suggested using the django-allauth package.

Hosting and Domains

The question of which host to use was called again. Corwin strongly endorsed https://www.hetzner.com as reliable and secure though not the cheapest option. Recieving a second opinion was advised. The question of how many VPS should be requisitioned was discussed. The final number was decided between 2 and 3 for the purpose of siloing data and operations in the event of a failure. One server would serve as the gateway, another as the application server, and potentially a third for the database. This also has the posibility of allowing different servers to have different owners to limit individual risk. Similarly utilizing additional domains were discussed as a way to avoid single points of failure and separate public and private functions. Leaving SquareSpace was discussed, but higher priority being to move the domain to a more reliable registrar.

Tangent - Decentralized Server Images

Corwin brought up the topic of decentralization as a design principle to eventually strive for. The idea of eventually building images that can easily be spun up by chapters to host services for their members independently. Sofia brought up how Mastodon would be well suited for such a deployment and how federation would make a resiliant community. The topic was tabled by consensus to the distant future.

Notes - William

Operational Hosting

• Important considerations
  • Reliability/SLA - what level?
• Ensure backups of data

Project Hosting - GitHub

• Aradia has ownership of GitHub organization. Corwin volunteered to get Jeff co-ownership.
  • Suggestion list: Jeff, JD (CA), William.
  • One of these folks can add others as members of the group.
  • Currently everyone is some form of external contributor (repo-specific).
  • Easier discuss/setup now vs after there are lots of contribs.
• Risk to code and data is relatively low at this time.
• Risk is somewhat greater for communication hub.
• Ensure backups of code and full repository.
• What alternatives exist?
  • GitLab
  • Forgejo
  • Gitea
• What are the costs of changing?
  • Dollars?
  • Time/effort?

Security

• How to?
  • Start formulating a list of specific security concerns.
  • Add issues to dev-sec-ops repo.
  • Perform analysis and address issues.

Data

• Data Classification
  • Public: Visible to All
  • Sensitive: Right to Possess (I should have access because of my association with the data)
  • Restricted: Need to Know (I can only be granted access when authorized)
• Documentation
  • Philosophy: Keep a public record.
  • Static documents:
    • Finalized, (mostly) immutable
      • Records
      • Notes
      • Procedures
      • Policies
      • Instructions
    • Classifications
      • Public: keep in docs of repo(s).
      • Sensitive and restricted: keep in proton (?), link in docs (where relevant) with instructions on how to access.
  • Live documents:
    • Editing using collaboration tools like etherpad, Google Docs, or Proton Docs.
    • Ephemeral, when finished we move the document into the repostory or another secure document depository.

OAuth

• Purpose
  • Managing authentication for admin and dev-sec-ops.
• Options
  • Forgejo
  • Gitea
  • GitLab
  • Framagit
  • GitHub
  • Discord
  • Facebook (business account/busn verification required; this has changed in the last few years)
  • Microsoft (still fighting this one; costs money and is a pain this ass)

Architecture

• Gateway (web)
  • Open to the internet (HTTPS/SSH access only)
  • Should be stateless and ephemeral
  • Could have piggy-backed services (future)
    • Mastodon
• Application
  • Should be stateless and ephemeral
• Database
  • Carries acquired data

Automated Testing

• https://docs.djangoproject.com/en/5.2/topics/testing/overview/

Domain

• Use a different domain for email than current GS-US website for prod application instances.
  • May reduce end-user trust.
  • Who has responsibility?
• Use the same email domain as GS-US.
  • Requires us to build a solution.
  • App authorization with Google and so forth, or another email provider.
• Subdomains are a must.
• Time-to-live.

Future Discussion

• Discussion: We should generally follow good team practices, e.g., rotating owners after the new version is stable, etc.
• Getting primary website off of SquareSpace.
• Design a technology asset ownership strategy.