Relationship to Webfinger, OpenID 2.x, OAuth

[Markus Thielmann]

I'm delighted to see you guys working on a free distributed social
network software. Can't wait to test your code.

Since quite a few developers of Google, Yahoo and other parties are
working on related protocols (like Webfinger, Salmon, etc. pp) I
wonder if you already thought about interoperability?

It seems at least Google currently plans to base authentication and
authorization on OpenID (with e-mail-like-identifiers) and OAuth and
seems to prefer REST instead of XMPP.

I'd love to see both solutions somehow work together, since both have
valid use cases.

So thanks again for this project. Do you have any ETA on the code? :-)

[Laurent Eschenauer]

Hello Markus and thank you for joining the discussion !

> Since quite a few developers of Google, Yahoo and other parties are
> working on related protocols (like Webfinger, Salmon, etc. pp) I
> wonder if you already thought about interoperability?

Yes of course. We are not "married" to XMPP and REST is on the roadmap
at various levels. We even found out that you can achieve cool stuff
when mixing XMPP identity framework with REST APIs.. but more on that
later :-)

Two potential REST APIs:

(1) client - server API (which would also be used for third party
applications). Could be based on OpenSocial or the Facebook API.

(2) server - server federation over HTTP. No solution today in this
space, besides PubSubHubbub (PuSH) which only deal with Pub/Sub of
public data.

> It seems at least Google currently plans to base authentication and
> authorization on OpenID (with e-mail-like-identifiers) and OAuth and
> seems to prefer REST instead of XMPP.

Correct. However I don't see how they will be able to achieve true
federation, also supporting privacy, using just these protocols. There
is, in my opinion, a fundamental "gap" in the HTTP/REST world when
looking at server-server federation.

Last time I checked the PuSH API, I didn't see anything that would
enable to support fine grained privacy. As of today, all these
standards (activitystrea.ms, PuSH, Salmon, etc...) only deal with
public data.

This is why we decided to go XMPP. We are leveraging the very strong
security and identity framework of XMPP to support privacy in our
federation. I'm happy to elaborate on this topic on this mailing list.

> I'd love to see both solutions somehow work together, since both have
> valid use cases.

If Google, or any other player, propose a REST based APi for
federation, we'll be the firt one to look at it and embrace. This is
what we want: one social web :-)

> So thanks again for this project. Do you have any ETA on the code? :-)

We plan to release first elements end of march, but we need first to
get some level of agreement on the approach and the XMPP extension.
Any feedback is therefore greatly appreciated !

[Matt K]

I've been working on this idea of federated sharing and balancing it
with privacy.
For a centralized social network, it seems that they can just hide
items from users because they've all got it in one central
authorization place.

For a decentralized social network you can't unpublish to a recipient
once they've picked up the data (picture, status, or emo blog entry).
The only thing you could do is de-invite a recipient from picking up
the data.
How are you doing it? Are you going to be sending urls with some sort
of guid or key in them that gets deleted?

Very interested in this space, looking forward to the code, also
interested in seeing it all work over http.

Thanks much!

On Feb 11, 5:43 am, Laurent Eschenauer <laurent.eschena...@gmail.com>
wrote:

[tyler gillies]

PuSH does have support for private feeds. You supply a secret key to
the hub when you subscribe

--
Everyone Loves Tea
http://www.everyonelovestea.com

[Laurent Eschenauer]

> For a decentralized social network you can't unpublish to a recipient
> once they've picked up the data (picture, status, or emo blog entry).
> The only thing you could do is de-invite a recipient from picking up
> the data.

We are using fat push, this means that the whole activity is pushed to
the inbox of the user following you. When you edit or delete the item,
we push an update to the follower and his server is expected to delete
the activity. I agree with you that it is not bullet proof, but we
think it is enough for these use cases. Other solutions would add too
much complexity.

Now, this is only true for activities described in XML. The actual
media (i.e. binary files) are stored and accessed on your server only.
An authentication token is required to see the file.

> Very interested in this space, looking forward to the code, also
> interested in seeing it all work over http.

Thank you for the feedback. This project will definitively gain speed
as soon as we go open source in a couple weeks and we look forward for
collaborations !

Cheers,

-Laurent

[Laurent Eschenauer]

> PuSH does have support for private feeds. You supply a secret key to
> the hub when you subscribe

PuSH supports "Authenticated Content Distribution", in the sense that
it provides message authentication based on a shared secret key. I.e.
it allows the client to verify that a push message is indeed coming
from a server the client subscribed to.

To my knowledge, and understanding of PuSH, there is no provision for
entity authentication and entity based access control on a per item
basis.

More generally, I find that the Pub/Sub design pattern does not
support well per item access control, since, by definition, it
decouples the publisher from the subscribers by inserting a pub/sub
node in between. Where as in a per item distribution mode like the one
we require, you need the distribution node to understand and enforce
the access policy.

What do you think ? Am I missing something ?

[tyler gillies]

And here I thought decoupling subscriber and publisher was the best
feature of push

On Wednesday, March 3, 2010, Laurent Eschenauer

[Vishal Patel]

On Wed, Mar 3, 2010 at 1:09 AM, Laurent Eschenauer
<laurent.e...@gmail.com> wrote:
>> For a decentralized social network you can't unpublish to a recipient
>> once they've picked up the data (picture, status, or emo blog entry).
>> The only thing you could do is de-invite a recipient from picking up
>> the data.
>
> We are using fat push, this means that the whole activity is pushed to
> the inbox of the user following you. When you edit or delete the item,
> we push an update to the follower and his server is expected to delete
> the activity. I agree with you that it is not bullet proof, but we
> think it is enough for these use cases. Other solutions would add too
> much complexity.
>
> Now, this is only true for activities described in XML. The actual
> media (i.e. binary files) are stored and accessed on your server only.
> An authentication token is required to see the file.

This seems to be a reasonable approach. Its bullet-proofness is
similar to the centralized networks if you consider that anyone can
easily save/screengrab your photos/texts/etc. to their hard drive
where they will reside forever despite any attempts to "unpublish."

There's really no way to prevent this. There are cron/scraper scripts
for all the major social networks which will snag and cache any
updates from your friend network within minutes. Similarly, anyone
who writes a misbehaving OSW server will 1) ignore all delete actions
and 2) immediately request any binary data (with auth token) upon
receiving the push notification and cache it locally. As with all
social networks, prevention is the best medicine: think twice before
publishing. :)