dirkmc
dirkmc
The drawing really helps me visualize it 👍
To narrow down the possibilities maybe it helps to concentrate on the following use case: - Some state is shared amongst replicas, that all go offline - A new replica...
Right, it would be similar to how the push/pull protocols work for collaborations 👍
The use case is similar, but simpler. In comparison to collaboration state updates, membership changes are both less frequent and more urgent, so probably we don't need lazy / eager...
I think that makes sense, there would be some refactoring but the protocols would be essentially the same
I'm thinking of implementing the protocol such that we can keep track of members of the app and of each collaboration using a two-level CRDT: 1. an app-wide CRDT of...
That's true, there are some scalability concerns with this approach. What should the scalability limits be for a peer base app / collaboration? In order to form a Dias set...
I'm also thinking about it a little more :) Stepping back a bit, the end goal is for members of a collaboration to exchange state as quickly and with as...
@aschmahmann you're right, finding out which peers are interested in an app/collaboration is essentially the same problem as subscribing to pubsub topics. Currently we use pubsub topics to establish which...
@pgte and I had a conversation about strategies for implementing naming across multiple peers that perform writes (multi-write) using IPNS which is single-writer. ### 1. All peers write to IPNS...