Federation & Storage Design

Issue không nêu tệp, kiểm thử hoặc điểm vào nào. Hãy bắt đầu bằng việc giải quyết ba đề xuất về federation và storage cùng các câu hỏi còn bỏ ngỏ của chúng; công việc được xem là hoàn tất khi một kiến trúc đã được chọn và các yêu cầu về đồng bộ hóa không gian riêng tư, thứ tự thành viên và phát hiện máy chủ đã được ghi lại.

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