Re: RE : Re: Federation protocols

On 12 June 2013 11:40, Michiel B. de Jong <anything@michielbdejong.com>wrote:

> On 2013-06-12 11:16, Nick Jennings wrote:
>
>> On Jun 12, 2013 10:22 AM, "Goix Laurent Walter"
>>
>>> Should we formalize these 2 teams to start some concrete collaborations?
>>>
>>
>> Sure, that could help to avoid these kinds of "chasing our tail"
>> discussions in the future.
>>
>
> from my point of view, maybe we can describe it as "bottom-up" (build
> stuff, use it, and see what synergies emerge) vs "top-down" (document and
> discuss things that we already know could work for everybody, to avoid
> reinventing all sorts of wheels).
>
> i don't see them as "camps" but just a distinction to help us all
> understand each other. i think we need both approaches to work in tandem,
> for best results.
>

We've learnt over the past few years that people independently creating
protocols, has almost never lead to interoperability.  The result is a
balkanized network effect that benefits the larger players at the expense
of the smaller ones.

Certainly there is no lack of willingness to co operate *in principle*, but
we have yet to find a way to translate that into concrete results.

Maybe try and establish some of the reasons why?

*Some Technical Barriers to Federation*

*1. Identity,* people conceptualize and denote identity in different ways.
Often in ways that collide or make it impossible to interact.   Possible
Solution:  each system needs to have a well formed description of how to
identify a user, and publish it.

*2. Naming,* people often name things in different ways, and often in ways
that collide with other systems.  This means that it can be hard to map one
concept to another.  Possible Solution: allow name spacing.  Where one
system has a registry, apply a name space to prevent collissions.

*3. Modelling*, things are modelled in different ways.  For example one
relation may be one to one in system A, and one to many in system B.  The
one to many system can handle one to one, but the one to one cannot handle
one to many.  Possible Solution: this requires finding the differences, and
coding or protocol changes to allow interop -- this is perhaps the greatest
challenge of the 3



>
>
> my 2ct,
> Michiel
>
>