Re: [Social-p2p] P2P XMPP

[Ted Smith]

On Wed, 2010-07-14 at 09:46 +0200, Dan Brickley wrote:
> Hi folks
> 
> Great to see this initiative; it nicely complements the
> StatusNet-based codebase.
> 
> I wanted to float a technical possibility. There are already a few
> mentions of XMPP in the documentation, and in parallel other Social
> Web efforts are taking XMPP quite seriously. However XMPP as normally
> deployed typically depends on something playing a 'server' role. While
> there might be scenarios in which decentralised peers do more of that
> work, I'd like also to draw attention to "XEP-0174: Serverless
> Messaging".
> 
> From http://xmpp.org/extensions/xep-0174.html --
> 
>  "This specification defines how to communicate over local or
> wide-area networks using the principles of zero-configuration
> networking for endpoint discovery and the syntax of XML streams and
> XMPP messaging for real-time communication. This method uses DNS-based
> Service Discovery and Multicast DNS to discover entities that support
> the protocol, including their IP addresses and preferred ports. Any
> two entities can then negotiate a serverless connection using XML
> streams in order to exchange XMPP message and IQ stanzas."
> 
> There are two pieces to this; discovery and messaging. The XEP-0174
> assumption seems to be that the nodes are talking directly on some
> local network, but there's no huge reason they couldn't be linked
> through the public network (even, with some tricks, behind
> NAT/firewall). I think the general precedent here is quite interesting
> --- that XMPP-based conversations can be conducted between independent
> parties *directly* rather than always through server-mediated means.
> In a GNU Social P2P context, I'd suggest considering this as an
> abstraction for the messages that pass between peers, since it could
> allow developers to get a quick understanding of what's going on,
> re-use work on extension markup, and give a model for
> application-level protocol extensions. GNU Social P2P could use
> different mechanics for discovery and comms than XEP-0174, but still
> adopt this general principle of using/extending XMPP for P2P work.
> 
> Thinking out loud,
> 
> cheers,
> 
> Dan
> 

This looks really interesting - at worst, it's another transport, but I
think we could use it for more.

signature.asc
Description: This is a digitally signed message part