Re: Federation protocols

Hi Simon,

Dnia piątek, 31 maja 2013 o 12:37:25 Simon Tennant napisał(a):
> Simon from buddycloud here.

Great to see BuddyCloud here also!

> As Mikael was saying, eash of these networks has a different application
> logic. Imagine trying to unify Twitter and Facebook: Facebook has a one-one
> follower model, Twitter has a decoupled following model.

This can be achieved by having a protocol that permits follower relationship 
to be decoupled while making additional things possible if the relationship is 
bidirectional -- somewhat how StatusNet/Identica do that (you can only send 
PMs to contacts that you follow and they follow back).

> In Facebook I can post into your stream. In Twitter not.

That's a presentation layer detail, irrelevant to the protocol IMVHO.

Unless you're talking about *federating* what other people write to my stream 
-- I don't believe that would be a good idea, but maybe a server-side setting 
of "automagically republish everything these contacts publish" is not a bad 
idea, I can see some use-cases.

The protocol could allow for that, but not make it mandatory.

> I agree it's really good about mapping out a master protocol for new
> internet services early on to give a framework that can guide some sort of
> interop. In the case of social, I don't think there is one "right" way to
> do this. Each application is different and has different following,
> publishing and sharing models. Each of these is shaped by the requirements
> of that application or federated network. For example oStatus started with
> the assumption that everything was open. buddycloud started with the
> assumption that channels are private by default and can then be opened up.

But a single protocol can support both models! It can *support* private 
communication and public communication. This way both use cases are covered.

We already know that support for private communication ("aspects", "groups", 
"private messages") is a must, but that does not preclude supporting public 
communication.

> And then we get to names: pump uses something that looks like
> http://name.pump.io, buddycloud uses name@example.com.

The whole world uses name@example.com, pump.io decided they want to do things 
entirely differently... Which is yet another way of breaking compatibility and 
fragmenting the already dreadfully fragmented federated social web.

Again, this in no way helps us get people out of walled gardens. Every time we 
get more fragmented, Mark Zuckerberg kills a puppy in delight.

> The devil is always in the details and trying to mash together different
> protocols and apps will end up with some horrible grey good that is
>  software by the lowest common denominator.

Not *software*, *protocol*. That's a world of difference.

And while I don't think we would land in a "grey goo" scenario, I do believe 
that even a "grey goo" protocol that is interoperable and actually implemented 
across the board would be several levels of magnitude better than the sad 
situation we have now.

-- 
Pozdrawiam
Michał "rysiek" Woźniak

Fundacja Wolnego i Otwartego Oprogramowania