graphprotocol / graphprotocol/hypergraph
Federation & Storage Design
Offen
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 22
- Forks
- 12
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beschreibung
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
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Der Issue nennt keine Dateien, Tests oder Einstiegspunkte. Beginne damit, die drei Vorschläge zur Föderation und Speicherung sowie deren offenen Fragen zu klären; abgeschlossen ist dies, wenn eine Architektur ausgewählt und die Anforderungen an die Synchronisierung privater Bereiche, die Reihenfolge der Mitgliedschaften und die Server-Erkennung dokumentiert sind.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- sqlite, typescript
- Bereich
- databases, distributed-systems
- Issue-Typ
- Feature
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Veraltet
- Klarheit
- Muss geklärt werden
- Anfängerfreundlichkeit
- 25/100