Open nicola opened 8 years ago
Snapshot from Etherpad
pubsub subscribe --{topic, content, type, concept}="[...]" --auth=/iprs/QmHash
Creat shared multiplayer environments, potentially thousands of users. Similar requirements to chat, but events are more frequent and smaller
Speaking of papers and the above-referenced issue, here's a link to the pdf that reviews pub/sub systems.
Also, (aside from the livestream) did anyone manage to capture video of this discussion?
@gavinmcdermott I, too, am curious about a video of the discussion
I'm interested in watching the discussion video as well
Has any thought been given to the issue of ethereal vs. persistent in the context of collaboration via pub-sub on IPFS? I.e. is it efficient to capture every fine-grain update from every node into the merkle tree just to enable collaboration? From a distributed data model state transition (i.e. collaboration) perspective, this seems sub-optimal for highly dynamic data.
The holy grail is a unified interface to a local/remote model, allowing an app to deal with data in a way that's abstracted from locality. The key seems to be to enable triggering serialization of ethereal to persistent at appropriate times. I.e. application accesses data in a local paradigm, PubSub syncs updates in an optimal (ethereal --> networked p2p but non-persistent) way, then at some point the 'transaction is committed' which triggers serialization of current state down to IPFS.
A key thing here is a collaborative proxy interface exposed to app layer needs to be async and type aware. Something similar to this https://github.com/tycho01/proxy-dsl
Hope this is constructive & makes sense. Let me know if not welcome.
@Dave--G Good points. Might be good to raise those issues here, https://github.com/libp2p/pubsub, though, as this issue is largely just for the notes for this event.
PubSub
Different designs
Need to design Interface
PubSub means
Lit. review
Action points:
cc @haadcode, @jbenet, @diasdavid