hosted version

did:plc:rjhjcb3rgdsmdr6ykywuh63z opened this Apr 11, 2026 0 comments
did:plc:rjhjcb3rgdsmdr6ykywuh63z opened Apr 11, 2026

currently xpost only runs in single user mode (standalone), what would be great is a hosted version like https://skymoth.app/

the architecture of services allows them to be created and destroyed on demand, so that's already pretty good. for the first version of this, simply uploading a standalone config should be good enough??

  • restructure project

the standalone version should still be supported for selfhosting (it's easy to configure and run thanks to docker and uv)

something like this:

| - core
   | - mastodon
   | - atproto
| - standalone
   | - main.py
| - hosted
   | - main.py
   | - web
  • API and WebUI

API needs to implement auth, it's probably going to be invite only. SSR and no JS for the config only should be good, if i decide to implement a proper GUI, i think it's possible to do in pure html (i hope)

what framework should this be based on? i think Flask should be good for a project as simple as this.

  • service stuff
    • seq. per-user queue with multiple worker threads
    • figure out the db situation
    • store credentials

when someone submits/updates the config, the running services will be destroyed and recreated.

the standalone version uses a single-threaded queue for output tasks, but this wouldn't work for hosted, so that will need to be re-implemented. also the db is sqlite.. not sure what to do here. for standalone one db is fine, but for multiple users??? either keep one db and hope that user ids don't conflict (realistically they shouldn't), but concurrency is ?? or go the atp PDS way and partition the db into multiple files per user. how should the configs be stored?

also storing credentials is another big question, just dump them with the config?? but returning them through the API is an awful idea. probably the way secrets work on CI pipelines is good enough (submit a named envvar and then insert it into the config)

the data dir structure might look something like this.

| - ...[user_id]
   | - data.sqlite
   | - config.json
| - cache.sqlite <- atp ident cache and such
| - config.json <- for general instance configs.

No activity yet.

cospan · schematic version control on atproto built on AT Protocol