Federation & Storage Design

This is only relevant to private spaces

Requirements

• Real-time sync must be possible (Relaying over 1-2 servers would be fine)
• We space membership we need linear ordering: we either move it on chain or we have dedicated lead sync server per space

Ideas

Proposal A

• Multi-sync server architecture where sync you can host your own
• Each space defines a dedicated sync server.
• On the sync server we one sqlite per Space.

Implications

• could mean that clients need to connect to a lot of sync servers if you subscribe to several private spaces. Chrome e.g. has a limit of 255 Websocket connections. That said subscribing to multiple space on one sync server could re-use the same connection.
• real-time sync is easy to achieve in a space
• migration to another server could be get the sqlite db and upload it there
• could be that we can leverage Cloudflare for this (they have Sqlite + Websockets and scale well)

Open questions

• How can I list my private spaces?
• Where can I find out about which sync server to use for a private space?
• We have little experience with sqlite per space. Bluesky does it and it seems to work well
• Has pros and cons regarding versioning (larger eco-system that moves slower, but we also can experiment easier)

Proposal B

One centralized system maintained by the Graph Foundation, Edge & Node, Geo.

Implications

• the easiest to implement and maintain
• not decentralized

Proposal C

• Federation between servers
• There is one main sync server for each space, but message can be forwarded in a peer to peer network

Open questions

• I think we have little experience with federation and not sure there are many benefits

The issue names no files, tests, or entry points. Start by resolving the three federation and storage proposals and their open questions; it is done when an architecture is chosen and the private-space sync, membership ordering, and server-discovery requirements are documented.