Re: Distributing the user interface for social networks

Hi Melvin,

Just a comment below on what you pointed out (I very much agree to  
what you suggested).


On 9 Jul 2012, at 15:59, Melvin Carvalho wrote:

>
>
> 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:
> 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
>
> User clicks "like" button.
> Generates
>
> :me :likes  <http://example.net/joe/note/1>

URIs is just a step, I think it is quite important to use an  
interoperable way of expressing this information, for example  
vocabularies available out there (schema.org, FOAF, SIOC, ..) Also,  
how to keep the provenance and allow some privacy control?

Another simple use case based on what we try to deal with, somehow  
similar to what Evan suggested:

1) I go to buy my flight ticket on orbitz.com
- I am searching based on the destination and decide to buy a ticket  
to e.g. Thailand
2) I continue my browsing session and go to Amazon.com
- It would be great if I could see a book "guide to Thailand" in the  
recommended items box

I think this is an interesting use case for the federated social web:
- data has to be interoperable/linkable between sites
- data processing has to be done using cross-domain and multi-source  
data
- user identity has to be preserved across multiple sites
- how to preserve privacy in similar scenarios? (i.e. Amazon should  
access my activity at orbitz to be able to provide those  
recommendations)

Regards,

Maciej

>
> 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.
>
> User enters "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.
>
> example.net server discovers an ActivityPub endpoint for evan@example.com 
> .
> example.net server use OAuth to request authorization to post  
> activities to evan@example.com's activity stream.
> [OAuth dance happens here]
> 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.net and may continue interacting with content there:
> User evan@example.com navigates to photo page http://example.net/joe/photo/2
> User enters a comment in the comment box and clicks send.
> 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:
> User evan@example.com navigates to user page http://example.net/joe
> User clicks "follow" button.
> 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.
>
> Author of blog at blog.example.org includes a like button widget  
> from widget.example.net.
> 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.
> User clicks the "like" button.
> widget.example.net asks for an identity from the user.
> User enters "jane@example.com".
> widget.example.net discovers an ActivityPub endpoint for jane@example.com 
> .
> widget.example.net requests authorization to publish to jane@example.com 
> 's activity stream.
> [Dance dance dance]
>
> lol reminds me of 'goodfellas' :)
>
> 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.
>
> 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.
>
> 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:
> The author of a photo album at http://photo.example.biz/ includes  
> the same like button widget from widget.example.net
> User jane@example.com navigates to a photo page on http://photo.example.biz/photo/1 
> .
> User clicks "like" button.
> 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.
>
> 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://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
>