On 24 March 2010 17:06, Sylvan Heuser <[email protected]> wrote: > As I see it, we have two approaches between we must decide. > > The pure P2P approach: > *snip* > > The network of independent servers with small user groups approach: > *snip*
I'd second the idea that there are hybrid approaches that are readily possible. I think even in the hybrid case, you need a shared addressing space. The reason you need a simple, shared addressing space is so that people can add each-other on contact lists. Once you have that, then two people who meet at a bar or on a bus can exchange contact information. So far, Webfinger (i.e., email-like addresses that point to HTTP discovery resources) and WebIDs (i.e., URLs that point to FOAF documents) have been proposed in this context. Webfinger can satisfy WebID's requirements (by pointing to a WebID) but the reverse is not true – that is, WebIDs do not meet the "simple, consistent, and understood" property that drove Webfinger's creation. Now, assuming you've followed me this far, you can use your Webfinger (or WebID) address to point to your current P2P location. It is possible through various mechanisms (which I'll skip here for the sake of argument, but not to downplay the importance of the suitability of the solution) to ensure that only pre-authorized entities are allowed to access this data at any given time. Once a 3rd party knows your P2P location (or vice-versa), truly decentralized, persistent P2P data exchange of the sort that Elijah discusses can occur. Alternatively, based on that same discovery data, compatible systems can interact with more "centralized" systems, probably HTTP or XMPP based, whether those systems are large (e.g., Twitter/Facebook) or small (e.g., a SheevaPlug in someone's home running a non-P2P Social Network instance on dyndns). The way I tend to think of these things is, what's the solution with the smallest possible change set to how things are currently done that will get me closer to my goal? My analysis leads me to the following lists: Problems facing the adoption of a pure P2P decentralized social network: - Establish a P2P socket-level protocol that satisfies all the below requirements, and get everyone on board with it. - Fix the problems faced by GPG trust model to ensure that two parties can verify (with some degree of trust) that the other party with whom they're communicating is, indeed, the person they expect. - Settle on SSL client-side certificates or GPG public keys, promote adoption of that standard in the context of every place that might need to interact with the P2P network (in the face of 10+ years of non-adoption in those contexts) - Explain to users how to discover and engage other users on a P2P network (again, something that hasn't happened in almost all previous P2P networks). - Deal with synchronization and persistence problems facing intermittent P2P networks, keeping in mind that "Heading to the bar for a few pints" is exactly the kind of message that people want to see on these networks – that message implies that the user is going offline, so this is a major problem. Elijah points at a few potential solutions, although in a separate problem space. - Deal with permissions problems in the context of a pure P2P network. What happens when the crypto is broken? We have a good understanding of how to deal with privacy in the closed context, but private data over (open source) P2P is very new. - Deal with data formats; special credit for dealing with data formats in a network which by design promotes at least as many running networks as there are people using them, and encourages iteration on data formats (which I think could be a good thing - but it does make things harder). Problems facing the adoption of a server-centric (edge - 1) decentralized social network: - Determine a mechanism for human-level sharing of identity. - Figure out a method for sharing private data. - Figure out how to translate data between potentially incompatible sources. By my count, we have #1 solved (webfinger), #2 is well underway (and actually comes down to a policy decision - it's trivial to implement in XMPP, but PSHB needs a small amount of protocol work), and #3 is a non-issue if we can assume Atom for most operations. The smaller number of participating softwares means it's somewhat simpler than the P2P case. So, in all of this, I'm *not* saying that having a fully decentralized / P2P approach to social networks isn't something I'd like to see – just that from a purely pragmatic perspective, it's unlikely to happen tomorrow, next week, or this year. Heck, it probably won't happen in the next 2-3 years, minimum, barring very marginal experiments. I want projects like GNU Social to succeed, and I can't see how a P2P model is going to do that anytime soon. Continued research and though is definitely worthwhile, but keep in mind that hub-and-spoke models to social networking have been brewing basically since the inception of social networking, and we're only just starting to get to the point where multiple organizations and individuals are truly working towards real interoperability. Which is to say, my take on where GNU Social should be going is that of a hub-and-spoke model, with an eye towards taking advantage of P2P features where and when possible. b.
