Pedro Teixeira
Pedro Teixeira
@aschmahmann @parkan perhaps you're interested in also reviewing the document?
@dirkmc I think this would work well. Ideally, we wouldn't need to send the entire state of the CRDT, but only the deltas as they occur.
@dirkmc perhaps we could just use the same stack as the collaboration data for syncing membership?
Right. Perhaps using the pull and push protocols? Would mean keeping a vector clock for each peer around (i.e., a special-case collaboration)..
Before that, I'm worried that an app-wide CRDT won't scale very well. IMO, having all the application peer addresses in memory may not be feasible. Also, the amount of concurrent...
Sorry about being unresponsive on this. I have to get me some more coffee and think about this one for a bit more.. :)
@alanshaw thank you so much for the headsup, we'll be keeping an eye for that on updating js-ipfs.
adding @aschmahmann to the conversation
@dirkmc It would be nice to not require interaction to elect a leader indeed, but if you don't require quorum over membership changes, you can get split brains. For instance,...
I agree with your point, but my point was that if the leader got (really) elected interactively, no split brains would occur, and thus no overwriting of IPNS by a...