FYI folks, I just sent this to the GNU Social project's P2P list. See http://groups.fsf.org/wiki/Group:GNU_Social/P2P/Design or http://lists.nongnu.org/archive/html/social-discuss/2010-07/msg00015.html for more background. Briefly GNU Social is exploring two related efforts; a StatusNet-based codebase and this exploration of a P2P app. In the note below I suggest it might make sense to use XMPP in serverless mode; I'd much appreciate any sanity checks folks here can offer...
cheers, Dan ---------- Forwarded message ---------- From: Dan Brickley <[email protected]> Date: Wed, Jul 14, 2010 at 9:46 AM Subject: P2P XMPP To: [email protected] Cc: Peter Saint-Andre <[email protected]> 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
