Re: Federation protocols

Dnia piątek, 31 maja 2013 o 14:36:49 Michiel B. de Jong napisał(a):
> On 2013-05-31 13:37, Michał 'rysiek' Woźniak wrote:
> > The whole world uses name@example.com
> 
> On 2013-05-31 12:50, Sandeep Shetty wrote:
> > I think interop on the web should be based on URLs not email
> > addresses
> 
> Looks like a blocker, right there. Let's see if we can fix that! I
> propose a simple rule:
> 
>     "If it exists, then it is correct."
> 
> Do email-like identifiers exist? Yes, several systems use them. So then
> they are correct.
> 
> Do URL identifiers exist? Yes, several other systems use them. So then
> they are also correct.
> 
> See what is out there, and federate with it. Just federate with
> everything that exists, in the other system's native protocol (even if
> their identifiers look so funny to you) instead of trying to evangelize
> your "esperanto language" to them. I wrote http://useraddress.net:12380/
> last year to explore that approach, and I think it can work.
> 
> I think in a polyglot mindset we should allow both email-like and
> URL-like identifiers, and I even think that it is the only way forward.
> If we can apply polyglot thinking at that most basic level of the user
> identifier, then we will also be able to apply it at all the other
> levels, and can achieve interop without having to discuss superiority of
> certain design choices over others. It is actually a beautiful thing
> that all our systems are so different and unique, that's part of the
> richness! :) Let's try to federate them with each other in a polyglot
> way.

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.

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.

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.

Interesting perspective, I guess.

[1] http://sockethub.org

-- 
Pozdrawiam
Michał "rysiek" Woźniak

Fundacja Wolnego i Otwartego Oprogramowania