You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
240 lines
6.8 KiB
Org Mode
240 lines
6.8 KiB
Org Mode
* nassella
|
|
|
|
A worker's co-op and self-hosting for anyone. <3
|
|
~nassella~ is the working name for the worker's co-op as well as the
|
|
current in-development software project, which is: to build a system
|
|
that enables anyone to self-host a specific set of apps.
|
|
|
|
* A worker's co-operative
|
|
|
|
I want to build a workplace where the goals are differently aligned
|
|
from that of a more common tech workplace.
|
|
|
|
** Goals
|
|
|
|
- worker control: 1 worker = 1 vote
|
|
- long-term, stable sustainable job's for members
|
|
- prioritize less work hours over growth/profit
|
|
- voluntary and open membership
|
|
- no discrimination including:
|
|
- gender
|
|
- social
|
|
- sexuality
|
|
- racial
|
|
- political
|
|
- religious
|
|
- provide a safe and inclusive work environment
|
|
- members must feel safe to make mistakes and voice different
|
|
opinions
|
|
|
|
- communication should be direct and specific
|
|
- expectations must be explicitly communicated
|
|
- boundaries must be listened to and respected
|
|
- members must not speak to or cooperate with law enforcement
|
|
- provide opportunities for members to learn and grow
|
|
- remain independent and autonomous
|
|
- outside capital, if any, may not have control
|
|
- cooperate with other cooperatives
|
|
- concern for community
|
|
- actively engage with local communities
|
|
- actively manage environmental impacts
|
|
- seek out, involve, and learn from diverse groups
|
|
|
|
** Bylaws
|
|
|
|
- Impactful decisions and bylaws can only be made by a vote of all
|
|
members (consensus)
|
|
|
|
- Hiring and firing of a member can only be made by a consensus vote
|
|
of all members
|
|
|
|
- The co-op and its members may not enter into any agreements that
|
|
would cause the change of worker control
|
|
|
|
* Product
|
|
|
|
The goal is to produce a product that enables less-technical people
|
|
the ability to self-host applications in a secure and auto-updating
|
|
manner. Self-hosting for anyone!
|
|
|
|
** Potential Qualities
|
|
|
|
- secure
|
|
- auto-updates
|
|
- host system
|
|
- container layers
|
|
- container apps
|
|
- manages dns records
|
|
- manages ssl certs
|
|
- reproducible (in a config standpoint)
|
|
- config is declarative
|
|
- load balances as needed
|
|
- collects and displays logs from all apps in a useful format
|
|
- data volumes/storage independent from containers
|
|
- can off-site backup automatically
|
|
- updates are run through CI before being made available
|
|
- can be moved between providers (no vendor lock-in)
|
|
|
|
** Potential Tech For Self-Hosted Cloud Infra
|
|
|
|
- DNS Registration
|
|
- Terraform via supported registry
|
|
- DNS Config
|
|
- Terraform
|
|
- resource management (VPS's etc)
|
|
- Terraform
|
|
- LB for apps
|
|
- docker-compose + caddy
|
|
- SSL
|
|
- LB + caddy
|
|
- apps
|
|
- docker-compose
|
|
- OS
|
|
- flatcar linux
|
|
|
|
** Potential Tech for Deployment and Config Node
|
|
|
|
Can be run locally or as a SaaS
|
|
|
|
- docker contained webapp for deploying/configuring/updating?
|
|
- needs to generate/init and store:
|
|
- terraform config and state
|
|
- docker-compose config
|
|
|
|
(this can be embedded in terraform config)
|
|
|
|
- can be used to:
|
|
- select apps
|
|
- resources (manage)
|
|
- view logs (stored on self-hosted infra)
|
|
|
|
** Potential Revenue Model
|
|
|
|
- End users pay for:
|
|
- a one-off version
|
|
|
|
This would enable using the product to create a self-hosted
|
|
instance with the apps of the users choosing. It would still
|
|
include automatic bi-weekly OS updates (via flatcar OS) but
|
|
otherwise may not include automatic updates for the platform.
|
|
- a monthly subscription
|
|
|
|
This would enable full automatic updates for the product, the
|
|
self-hosted instance, all apps running on the self-hosted
|
|
instance.
|
|
|
|
- Open source?
|
|
|
|
Likely the product itself can be open sourced (AGPL) and made freely
|
|
available. The target end user is not someone that would be likely
|
|
to setup and run it on their own anyways but it would be an option
|
|
if they didn't like changes made to the product in the future and
|
|
they gained technical experience or hired someone to manage their
|
|
own control node themselves.
|
|
|
|
- Target end user:
|
|
|
|
Companies or individuals that would like to have more control or
|
|
save on costs relative to pure SaaS solutions but do not have the
|
|
technical knowledge, time, or appetite for risk that would lead them
|
|
to run their own self-hosted infrastructure.
|
|
|
|
- Supporting open source: 1% of gross revenue donated back to the apps
|
|
used by end users and the company?
|
|
|
|
This could help create a self-perpetuating ecosystem. For example,
|
|
if users use this product to self-host NextCloud, then some of that
|
|
money can be sent back to NextCloud making NextCloud better which in
|
|
turn will help the end user as well.
|
|
|
|
** Potential Apps
|
|
|
|
- NextCloud
|
|
- Matrix
|
|
- Bitwarden
|
|
- Immich
|
|
- Jellyfin
|
|
- Gitea
|
|
- GitLab
|
|
- Cal.com
|
|
- VPN via wg-easy
|
|
- Jitsi
|
|
- StormKit
|
|
|
|
** Current status
|
|
|
|
A rough prototype of a docker compose based app running on flatcar
|
|
linux.
|
|
|
|
** v1
|
|
*** [ ] web interface for configuring / launching
|
|
**** [ ] configurable options
|
|
**** [ ] authentication
|
|
**** [ ] authorization
|
|
**** [ ] admin tools / management interface
|
|
*** [ ] App Infrastructure
|
|
**** [ X ] working implementation for deploying apps on flatcar linux
|
|
**** [ X ] app data stored on separate, durable volume
|
|
**** [ ] security audit
|
|
**** [ ] automated tests?
|
|
*** [ ] NextCloud
|
|
**** [ X ] working implementation
|
|
**** [ ] refine / investigate features or additions to enable/add-in
|
|
**** [ ] security audit
|
|
**** [ ] test upgrades
|
|
**** [ ] test backup / restore
|
|
*** [ ] wg-easy (VPN)
|
|
**** [ X ] working implementation
|
|
**** [ ] security audit
|
|
**** [ ] test upgrades
|
|
**** [ ] test backup / restore
|
|
*** [ X ] App logging (via Dozzle)
|
|
*** [ ] backups
|
|
**** [ ] select backup provider (tarsnap, borgbackup, etc)
|
|
**** [ ] implement
|
|
**** [ ] test
|
|
*** [ ] monitoring / alerting?
|
|
*** [ ] exporting
|
|
*** [ ] one time purchases
|
|
*** [ ] subscription
|
|
*** [ ] documentation
|
|
*** [ ] marketing site
|
|
|
|
** Unresolved Areas
|
|
|
|
In general, these have all been thought about and seem to be solveable
|
|
but still need more specific technical solutions.
|
|
|
|
- backups
|
|
|
|
|
|
The storage volume used on digital ocean already provides redudancy.
|
|
To provide complete, offsite backups, the /nassella folder just needs
|
|
to be backed up. (Could be something like just rsync or tarsnap, etc),
|
|
along with providing a backup of the config and terraform files internally
|
|
or via an "export" option.
|
|
|
|
Current recommendation: use the [[https://github.com/restic/restic][restic]]
|
|
library to allow backing up to
|
|
[[https://www.backblaze.com/cloud-storage][Backblaze B2].
|
|
- +logging+
|
|
|
|
|
|
Resolved for now with the [[https://dozzle.dev/][dozzle]] service
|
|
- monitoring / alerting
|
|
- exporting
|
|
- migrating between platform providers (VPS providers, etc)
|
|
- updating
|
|
|
|
|
|
Not fully implemented yet, but should be no more than updating docker
|
|
versions in the compose file and re-running ~make apply~ for each user.
|
|
Of course, long-term there should be an automated CI system to test all
|
|
apps after upgrading.
|
|
- CI system
|
|
- docs/auto-setup for app features
|
|
|
|
like helping users configure their phone to connect to NextCloud's
|
|
calendar for example
|