IPFS+PubSub, Re: "Listening on IPNS updates" - any work in progress?

[fubar-1]

Are you aware of any efforts to implement IPFS PubSub via "Listening on IPNS updates" as you mentioned here? ipfs-inactive/2016-IPFS-Workshop-Lisbon#17 (comment)

Your approach looks workable and efficient, esp in pubsub hierarchies and simple enough to be implementable by one or a few developers in just a few days. I'm thinking of throwing together a prototype of what it might look like but wanted to ask before diving in to dedupe effort & avoid wasting cycles.

[elimisteve]

@Dave--G Did you get an answer to this? Thanks.

[fubar-1]

@elimisteve No. Which is why I closed the bug. Fyi my prototype is half-finished & stalled due to competing priorities + issues related to immaturity of js-ipfs (but rapidly improving)

[nicola]

Have you seen the new work on floodsub?

[fubar-1]

Very interesting, thanks for the reference!

The API looks spot-on, at least for persistent data. Anyway, ideally any pubsub hierarchy would dynamically self-organize by the back-end and would be hidden from the API.

Hmm, self-organizing pubsub trees could start with a flood, which could dynamically partition into sub-floods, etc based on the usual metrics (subject, available capacity, net hops, etc). Sorry, just pondering...

This is only partially relevant, hope you don't mind some word-salad here, but my thinking has evolved a bit. You guys seem to be focusing on more highly static persistent data, but when I have time (not often) I'm focusing how high mutability could be supported, orthogonal persistence & how distributed memory would hang off a reactive framework. The grand idea is to build a unified distributed memory that can handle highly-mutable and static data via the same API by using some sort of hidden and/or exposed commit mechanism.

Basically I want to break all the rules of REST and get away with it :)