Re: FSW CG now has 100 members

> Thanks for the reply.  Yes, I'm glad you pointed this out, while
> 'friending' is a simple concept the devil is in the detail.
>
> I think we need to break down the use case into separate workflows
> e.g.
>
> 1. Facebook style (bidirectional) : user sends a friend request,
> request is either rejected or accepted -- this is what people are
> most used to today
>
> 2. Microblog style (unidirectional) : user follows someone on a
> network, this can be reciprocated or not -- google plus also does
> this
>
> "Activity streams solves that." -- No it doesnt, but it may in
> future.
>
> The more fundamental part of this is that one system needs to know
> how a user is identified on another system.  Easy, right?  No, wrong!
> Because everyone has a different way of identifying users.


Bingo. "Friending" is at its core a set of permissions. Nothing more. In 
order to have permissions across dissimiliar systems you need to know 
how to identify the viewer.

Message passing is a very simple case. Media and other HTTP access is a 
bit more complicated.

I've got a photo on my web server. I want to let Clyde see it. Clyde is 
a "friend". Clyde is on another network. How do I know it's Clyde?

Or I've got a web page for my business which should only be visible to 
existing customers - where I can interact with them. They aren't going 
to be signing in with their Facebook ID, and they shouldn't need yet 
another password/login just for my system. My business should be able to 
accomodate a federated identity and a federated login. Ideally this 
should be single sign-on.

If one has to login to every site on the Internet where they have access 
rights, this is going to be not just a user annoyance but a serious 
security issue - as it is today.

There are various approaches - webid, openid, oauth, ask for a password 
and provide an api at both ends to verify it, dfrn/zot single sign-on, 
"have a password on every site", etc. No matter what approach is taken, 
we need an identifier we can call (in this case) "Clyde" and 
disambiguate this from every other Clyde. Then we need to identify Clyde 
as the viewer in order to authorise access to the photo.

All of the current approaches are band-aids and hacks to make up for the 
fact that we really need these abilities in the core internet protocols, 
but this is the reality we are faced with today. As Evan once said, "My 
browser will gladly tell someone *where* I am, but it refuses to tell 
anybody *who* I am".

So we need various ugly work-arounds to the identity issue and none of 
them are really compatible.

What happens if Clyde moves his account from foo.example to bar.example 
or from Diaspora to BuddyCloud? All of a sudden Clyde's identifier isn't 
worth the cert it's signed by and I've got to edit all my photos and 
change the darn identifier. Sorry, but this is absurd. Clyde has not 
changed. He's still Clyde.

I've said this before - passing messages isn't rocket science. Neither 
is passing private messages. Nor is "making friends" for that matter. 
Decentralised identity, permissions and access control, and 
cross-site/cross-service mobility is where the fun really begins.

Unless people envision a future where these kinds of things are possible 
they'll probably continue to end up stuck in this "wannabe social 
network" mindset. The end-game shouldn't be a decentralised version of 
Facebook. In my view, it should be a free web with universal access 
control that just works. Federated and decentralised social networks 
would be a very small piece of this much larger picture.

Received on Monday, 1 July 2013 00:52:35 UTC