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. -- http://youbroketheinternet.org ircs://psyced.org/youbroketheinternet _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
