Re: Distributing the user interface for social networks

On 9 July 2012 16:13, Evan Prodromou <evan@status.net> wrote:

>  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.
>

Evan, the key here comes from the axioms of the web:

Give everything you care about a URI.  If you want it to benefit from a)
linkablility b) the network effect give it an HTTP URI.  There are
exceptions to this rule, but not many, for example email is such a big
system that we need to use mailto: in some places.

evan@example.org is not a URI, it's a string literal (note browserid is
falling into this trap too).  Generally it will be assumed by a client that
this is an email address.

What you need is essentially a dictionary (data store) perhaps with
autocomplete that can match the literal string to a more meaningful set of
data (name, avatar, profile etc.).

So you would do this in the profile something like

:me  :nick evan

or

:me :nick evan@example.org

In this way you bridge the universal and the local (but from the reverse
direction).


>
> 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.
>
> note/1 lets say is some microblog ... great start, it has an http uri,
we're in business


>
>    1. User clicks "like" button.
>
> Generates

:me :likes  <http://example.net/joe/note/1>


>
>    1. example.net server requests an identity from the user.
>
>
You'll need to identify & perhaps authenticate here. OAuth, OpenID, WebID,
username/password, session cookie, SAML, one time token, salmon?, are just
some options.  More below.


>    1. User enters "evan@example.com" <evan@example.com>.
>
> Also possible, this will need to be queried via your data store.  It's a
'reverse' lookup.  Sounds complicated but it's not.  A forward lookup is
when you supply a document URL and you get back text.  A reverse lookup is
when you supply text and get back documents.  Reverse lookup is what we do
every day when we type in a google query, or a facebook friend search.
It's the most intuitive type of search from the user's perspective.


>
>    1. example.net server discovers an ActivityPub<http://www.w3.org/community/activitypub/>endpoint for
>    evan@example.com.
>    2. example.net server use OAuth to request authorization to post
>    activities to evan@example.com's activity stream.
>    3. [OAuth dance happens here]
>    4. example.net publishes a "favor" activity to evan@example.com's
>    activity stream.
>
> Lots of ways to do this, including a well known lookup.  One day we'll
have a great lookup service like the Google Social Graph API used to be.
You can get back your Oauth server authenticate and verify the bearer token
just fine.  Notice here with these abstract principles, had you typed in
your full name, it would have gone away and found your record in the same
way?  The trick here is not to confuse the identifier you use on the front
end with identifier you use to tie everything together (which should be
your profile).


>
>
> After the first request, the user should stay "logged in" to example.netand 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.
>
> Some kind of HTTP POST would work here

You need a set structure for a comment saying what the text is, who the
user is and what the comment is in relation to.

post :hasComment
  { user : user, type : comment, comment : blah }


>
>
> 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.
>
>
Again easy:

:me :follows <URI of user>


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

Glad you mentioned widgets, timbl talks about this a lot too.  Once you
give everything you care about a URI, web pages can actually be divided
into different parts and widgets.


>
>    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" <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]
>
>
lol reminds me of 'goodfellas' :)


>
>    1. widget.example.net publishes a "favor" activity with an "article"
>    object with url "http://blog.example.org/article/1"<http://blog.example.org/article/1>to
>    jane@example.com's activity stream.
>
>
Once again this is almost perfect, but just replace strings with http URIs
where possible.  Strings and email addresses were not designed to link,
http way (and can do so invisibly).  It's possible that you can make
strings and email linkable, but it's a bit like trying to shove a square
peg into a round hole, hence why webfinger is still not ready after 3 years
(should be an instructive sign here).

Widgets can link to their whole own application flows.  So a like button
can use the same mechanism as a calendar etc.  Sharing then becomes an
interesting problem.


>
>    1.
>
> 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"<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.
>

Yes it's a good point.  Spam and trust are the next great challenges we
have to solve.  But it's going to happen.  Initiatives such as
<http://example.net/joe/note/1>http://www.trustmap.org/ are not bad, but
need to scale way more.  Of course there's always going to be people
telling you who you can and cant trust.  We just need to open this up to
competition, much as blogging was competition to newspapers.


>
> 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.
>

Pattern is pretty great, but understand that if you're going to do a lookup
on strings, make it a reverse lookup on a (hopefully cached) data store.
Try to give everything you care about a URI and ulimately link that from
your profile page.

A lot more needs to be done on access control, but we're working on it! :)


>
> -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
>
>