Federation & Storage Design

[nikgraf]

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

[baiirun]

I've been wondering how beneficial it would be to generalize the API of private spaces and the sync protocol so that anybody can build private space implementations across different types of servers. If we were able to do this then anybody could write a sync server implementation with any language and interop with every other sync server in Proposal A or Proposal C.

We could also generalize the Accounts system and the encryption scheme as a sort of "authorization" layer so that any server implementation can interact with a user's private data if they're given permissions.

My main motivation is to make sure that we have maximal flexibility for developers to build a rich set of tooling and infrastructure around Hypergraph and private spaces without being forced into a very specific implementation of the "Hypergraph and Accounts" protocol.

Doesn't have to be a thing to solve right now, but just thinking out loud.

[nikgraf]

yeah, totally agree that long-term it would be great to have utilities people can use to build their own servers. To do so I think we have to build a quite decentralized or at least federated architecture. Proposal A probably captures this the most?