Re: [Social-discuss] P2P or server approach?

[Blaine Cook]

On 24 March 2010 17:06, Sylvan Heuser <address@hidden> 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.