Distributing the user interface for social networks

So, one of the things that has been a problem for users of StatusNet on 
the FSW is that you can't interact easily with people or content on 
other Web sites.

If evan@example.com goes to http://example.net/joe/note/1, he can't 
reply to, like, or reshare the note shown there.

I think we can significantly improve the usability of the social web 
with the following flow:

 1. User evan@example.com navigates to note page
    http://example.net/joe/note/1.
 2. User clicks "like" button.
 3. example.net server requests an identity from the user.
 4. User enters "evan@example.com".
 5. example.net server discovers an ActivityPub
    <http://www.w3.org/community/activitypub/> endpoint for
    evan@example.com.
 6. example.net server use OAuth to request authorization to post
    activities to evan@example.com's activity stream.
 7. [OAuth dance happens here]
 8. example.net publishes a "favor" activity to evan@example.com's
    activity stream.

After the first request, the user should stay "logged in" to example.net 
and may continue interacting with content there:

 1. User evan@example.com navigates to photo page
    http://example.net/joe/photo/2
 2. User enters a comment in the comment box and clicks send.
 3. example.net publishes a "post" activity with a "comment" object with
    inReplyTo = http://example.net/joe/photo/2 to evan@example.com's
    activity stream.

Also:

 1. User evan@example.com navigates to user page http://example.net/joe
 2. User clicks "follow" button.
 3. example.net publishes a "follow" activity with a "person" object
    with ID = http://example.net/joe to evan@example.com's activity stream.

I think this mechanism will also allow interesting widgets to work:

 1. Author of blog at blog.example.org includes a like button widget
    from widget.example.net.
 2. User jane@example.com navigates to a blog article like
    http://blog.example.org/article/1 . A "like" button is served from
    widget.example.net.
 3. User clicks the "like" button.
 4. widget.example.net asks for an identity from the user.
 5. User enters "jane@example.com".
 6. widget.example.net discovers an ActivityPub endpoint for
    jane@example.com.
 7. widget.example.net requests authorization to publish to
    jane@example.com's activity stream.
 8. [Dance dance dance]
 9. widget.example.net publishes a "favor" activity with an "article"
    object with url "http://blog.example.org/article/1" to
    jane@example.com's activity stream.

The first advantage being that blog.example.org doesn't have to figure 
out how to do the publishing. The second big advantage happens with 
other sites:

 1. The author of a photo album at http://photo.example.biz/ includes
    the same like button widget from widget.example.net
 2. User jane@example.com navigates to a photo page on
    http://photo.example.biz/photo/1.
 3. User clicks "like" button.
 4. widget.example.net publishes a "favor" activity with a "photo"
    object with url "http://photo.example.biz/photo/1" to
    jane@example.com's activity stream.

After the first authorization, the user can favor things on new, 
unvisited pages without re-authorizing.

Probably the biggest issue with these flows is that the content server 
or widget server get a lot of power. There's nothing in the system, for 
example, to prevent a content page from publishing millions of "like" 
activities to the user's activity stream.

I see two ways to deal with this:

  * Two levels of access: one for interactions with users and content in
    the server's own domain, the other for "global" users and content
    (for widgets). Second one would require, probably, a significantly
    better level of trust.
  * Implementation restrictions, such as: activity throttling or site
    blacklisting.

This will almost definitely be the mechanism we'll be using in StatusNet 
in future versions. I'd love to get some feedback from this list on the 
pattern itself.

-Evan

-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: evan@status.net P: +1-514-554-3826