Re: Federation protocols

On Fri, May 31, 2013 at 3:03 PM, Michał 'rysiek' Woźniak <rysiek@fwioo.pl>wrote:

> Okay, I see the point of not enforcing any UID decision here (the protocol
> could simply state: "the UID is an URL with an optional 'username@' part;
> if
> the 'username@' part is not present, the URL is treated as the whole UID".
>
> However, the "polyglot" approach would need every. single. social network
> out
> there to implement all protocols. That's infeasible.
>

No, I think the key point to a polyglot solution is to have some type of
abstraction between implementations so that NONE of the social networks
have to implement any special third party protocols outside from, perhaps,
some form of identity management so that you don't have to have an account
on every single social network out there.


> So there are two ways to achieve interop, I guess:
> 1. create a protocol and try to convince most (or all) the large players to
>    implement it;
> 2. create a piece of software that would:
>    a). easily federate with any available libre social network;
>    b). be easily extensible as far as adding support for new social
> networks
>        is concerned;
>    c). would be easy to use in any social network project.
>
> So something like SocketHub[1], just not client-to-server, but server-to-
> server.
>

I meant to reply to your earlier message about Sockethub, but this thread
quickly grew :) so I will respond here. Yes - it's current focus is on
client-to-server abstraction. This is so that developers can build rich,
social, applications without crippling their relevance by having to pick
and choose protocols to implement.

That said, I'm curious what a server-to-server version would look like. The
main issues with this are identity IMHO, you don't have federation until
all the proprietary sites allow third party interactions using accounts
they don't manage or know anything about. This is a whole problem in
itself, and not something in the scope of Sockethub.

However, if you had accounts on each of the networks you chose to interact
with, Sockethub could be adjusted to poll and store messages from all of
the networks into one 'indbox', though - in the end - what would be the
difference between doing that during app-load (existing client-to-server
approach).

I guess what I'm getting at is that I think the issue is less about
protocols or APIs, and more about identity. Even the solutions out there
trying to address identity, Mozilla Persona, OpenID, or other "login with
X" services, don't really address the main problem standing in the way of
true federation. When you "sign in with Mozilla Persona", all you are doing
is providing a shortcut for account creation on that site. In the end you
still have to have an account with each site you want to interact with.
Whether Sockethub is doing it for you, or you're manually adding support
for these various protocols into your site, on some level you are signing
up with the site before you can interact.




> However, as 2.c) would require a well-defined and coherent API for
> projects to
> use, if successful it would create a de facto standard and at some point
> possibly would allow projects talking via it to talk directly.
>
>
No necessarily, I think it's safe to assume we aren't going to be able to
convince every "social network" site to actively reach out and interact
with 3rd party sites to deliver messages. So, polling these sites, speaking
their language, does not introduce any new protocol.