[messaging] Distributed vs cloud vs federation

carlo von lynX lynX at i.know.you.are.psyced.org
Sun Jan 4 04:52:07 PST 2015

I was asked to fork the discussion of distributed technologies
vs federated or cloudy ones, even though some challenges in
messaging are similar and should be viewed from all of these
angles to be fully aware of what we are doing.

> carlo von lynX wrote:
> > The pubsubs I am talking about (and linked to documentation and
> > design paper in previous mails) are meant to reside on a backbone
> > of GNUnet relay nodes, somewhat akin to the Tor network.
> > Participating nodes would have an incentive to maintain a certain
> > amount of state and history of its channels, therefore the devices
> > can pick up messages and state changes at their equivalents of
> > Tor's EntryNodes. We are exploring two different models for
> > incentivation, but I will leave it to the next mail to go into
> > detail about this if you are interested. The end result however is
> > that it should become very hard for an outside observer to trace
> > each device's choices in EntryNodes and try to figure out how the
> > pubsub networks are structured. You can think of our pubsubs as Tor
> > circuits that split to as many recipients as necessary, yet each 
> > participating relay only knows its nearest neighbors - plus these
> > circuits can also host state which allows for many applications to
> > be implemented without dedicated servers.

On Fri, Jan 02, 2015 at 11:31:22PM +0000, str4d wrote:
> At first glance (I haven't looked at your pubsub system in any depth),
> it looks like this could easily run on I2P too. The way I2P tunnels
> are set up allows this kind of pubsub data handling, and we already
> have one example of it called Streamr for streaming audio and video
> over I2P [0].
> [0] https://geti2p.net/en/docs/api/i2ptunnel#client-mode-streamr

This is interesting and neat stuff, I do however not gather from the
docs if there is any one-to-many distribution going on. The Streamr
API doesn't look like it. I do know that some of the I2P docs mention
multicast and I exchanged a few words with zzz on the topic at 30c3
but from what I gather I2P currently has no native multicast support,
correct? Also the distributed state that comes with our pubsub
apparently isn't provided by the Streamr API, and that is essential
in order to remove the traditional dependency on servers - being able
to leave a message for the other entities to pick up later, which is
the open challenge we are debating on the "Multiple devices and key
synchronization" thread.


More information about the Messaging mailing list