Re: Federation protocols

Simon from buddycloud here.

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. In Facebook I can
post into your stream. In Twitter not.

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.

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

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.

S.


On 31 May 2013 09:05, Mikael Nordfeldth <mmn@hethane.se> wrote:

> 2013-05-30 20:26 skrev Michał 'rysiek' Woźniak:
>
>  Hi there,
>>
>> I'm #NewHere, to use a popular cliche on federated social networks. I am
>> an
>> active user of Diaspora, Friendica and StatusNet (soon to be converted to
>> pump.io).
>>
>
> Greetings, you're very welcome!
>
>
>  What I feel we need is a single, extensible, well-defined protocol, or
>> suite
>> of protocols, that we can build a single, compatible, interoperable
>> federated
>> social network upon.
>>
>
> When speaking to Simon of Buddycloud, http://buddycloud.com/, last
> FOSDEM, he sort of persuaded me into thinking there is no actual need for a
> single, well-defined protocol. It's made me accept that there are always
> kinks in how things should be interpreted in a social environment - what is
> a friend/contact/group/list/tag/**grouptag for YOU?
> (my personal self-persuading argument is that it's more like the evolution
> of anything - no genetic implementation is guaranteed to live forever).
>
>
>  Right now we have OStatus, Diaspora's protocol, DFRN (used by Friendica)
>> and
>> the protocols that are used by Red, tent.io and pump.io, that I am not
>> even
>> sure are properly defined anywhere.
>>
>
> What I believe is important is what you stressed above, the proper
> definitions (btw, pump.io API is on https://github.com/e14n/pump.**
> io/blob/master/API.md <https://github.com/e14n/pump.io/blob/master/API.md>). Not just in API specs or protocol RFCs, but in actual implementations
> and libraries. If we want StatusNet to talk to Diaspora and then bounce
> that off to pump.io and Friendica/Red instances, these software must
> exist in a plugin-able form for others to use. That's what I believe is the
> hard part today, making an effort in "someone elses" codebase to support
> "one's own" implementation.
>
> Other than that, of course, there is the requirement of some global unique
> id which can somehow let the web know which protocols are supported and
> preferred. Which today seems to be email-like identifiers which get looked
> up with Webfinger, so that's not really a problem.
>
> --
> Mikael Nordfeldth
> http://blog.mmn-o.se/
> Xmpp/mail: mmn@hethane.se
>
>


-- 
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP