Federation & Storage Design

この issue では、ファイル、テスト、エントリポイントが指定されていません。まず、フェデレーションとストレージに関する3つの提案および未解決の疑問を解決してください。アーキテクチャが選定され、プライベートスペースの同期、メンバーシップの順序付け、サーバー検出の要件が文書化された時点で完了です。

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