Support for collaborative replication

[Gozala]

I have being musing a bit on how one could collaboration work and wanted to capture some rough thoughts.

• I think single db for everyone is probably not the best direction as we'll need to figure out how to namespace database such that replicas would only sync relevant data. Going down that path I'm starting to think it ends up looking like separate db instances anyway.
• I think we want something like SSB feeds except instead of feeds we have DBs or rather persisted prolly trees.
  • Each instance could have a keypair associated with it.
  • Public key is a unique identifier
  • Private key determines ownership.
  • You can manage read / write access via UCAN delegations
  • Remote can manage access and rate-limits via UCANs.
  • Transactions are authorized via UCANs and signed.
  • Collaboration unit (think collection or a document) is effectively a public key identified the db instance
  • You can authorize assertion and retraction capabilities independently (maybe we'll have more)
• DB on device ends up being a union of all of my collaboration units
  • 🤔 So maybe we do want to use partitioning instead so we don't have to sync multiple replicas locally

[Gozala]

💭 Say I have two collaboration units "work" and "hobby" there could be some datums that I want to be part of both meaning changes could be mode by respective collaborators. When viewing data through "work" I may not want to see changes made by "hobby" collaborators, but when viewing data through "hobby" I may want to see changes made by "work" collaborators.

I think from the constraints above we can derive that:

1. Assertions and retractions need to have authority associated with a change.
2. At query time we want to be able to narrow down results by authority
   • Perhaps even multiple of them

If we namespace everything by authority we will fragment data by it which means we could easily sync only data that is relevant there. On the flip side queries that span across authority boundaries become less efficient. Perhaps solution is to have different upstream and downstream layouts for sync and for query respectively

Upstream Layout

• Does not need EAV, AEV, VEA indexes
• Could use separate prolly trees per authority.
• Each tree could simply be fact → datum kv.

Downstream Layout

• Downstream replicas initiate sync with upstream prolly trees per authority.
• During sync it derives EAV, AEV, VEA changes to an index.