Re: Federation protocols

On 6/1/2013 12:09 AM, Simon Tennant wrote:
> So it seems like the gist of feeling here is that we must create one 
> open standard and then crush Facebook. I'll stand to the side of that 
> vibe except to add that this will not happen. This is not a case of
>
> 1. create open standard
> 2. developers implement it/users leave facebook for an open standard
> 3. ???
> 4 profit!?!
>
> Not going to happen. Facebook is offering huge value to users already 
> on their platform. We're the rounding error in terms of people that 
> care about privacy, federation and distributed network design. There 
> are very few success stories of open replacements replacing the closed 
> incumbent by matching them feature for feature.
>
> Simply reinventing the posts, followers, wall model and writing up a 
> protocol will not work.
>
> Instead, think about the tools and services and protocols that solve a 
> real developer problem. We solve this by:
>
> 1. Why are developers going to the Facebook SDK pages to build their 
> social products?
> 2. and what we can be doing to a) understand their needs b) offer an 
> open, hopefully federated, alternative that solves their needs 
> quicker, easier and in a more open way.
> 3. ???
> 4. (a higher chance of success).

Bingo.  Thanks Simon.

I see too many people rehashing the same old thing, "social network" 
this, "Facebook" that. If that's what you're building or how you measure 
success - good luck.

I'm working on a nomadic web identity and application framework with 
decentralised "internet scale" access control - which coincidentally has 
the ability to communicate.  That's quite a mouthful and so may not get 
wide adoption precisely for that reason, but you notice that this 
mission statement does not involve "social networking" or "Facebook".  
They are completely irrelevant to what we are doing. Global 
(privacy-enabled) communications is something that web apps must have 
going forward. It's in our DNA. It probably should be part of yours. It 
isn't, however, the reason we exist.

If we can communicate with/between other projects, it increases the 
value of both projects - as they also build their next big thing. 
Identity is the biggest stumbling block we see, as API federation 
without identity is not really federation.  With simple API federation 
you would still need an account on every service.  That kind of defeats 
our network-wide single-signon.

Identity federation is also a hard nut to crack (in our case especially) 
because as mentioned earlier - our identities are nomadic. We can 
federate with other non-Red services as long as our members stay in one 
place; but then they can't experience the full range of what Red has to 
offer; which is the ability to pop up anywhere on the internet on any 
server and still have all their channels and permissions intact (that 
would be "friends" for those of you with more traditional permission 
models).  This is a tradeoff members will have to make on their own if 
they want their channels to interact with non-nomadic services. But 
passing messages back and forth in and of itself is hardly rocket science.

I don't foresee any other projects including a "Red stack".  It doesn't 
fit with their core mission and complicates their identity schema. So 
from the get-go we have to draw a line and say "this person is 
in-network. This other one isn't - you can talk to them, but different 
rules apply." Which brings us back to square one. What are we/you trying 
to achieve? Federation *might not* be the best solution.

Received on Sunday, 2 June 2013 00:33:01 UTC