Re: Let's blow some new life into this community group

On Sat, Jul 14, 2012 at 6:13 PM, Melvin Carvalho
<melvincarvalho@gmail.com>wrote:

>
>
> On 4 July 2012 14:22, Michiel de Jong <michiel@unhosted.org> wrote:
>
>> Let's blow some new life into this community group. The approach to
>> federating the social web so far has been concentrated on taking
>> hosted applications that run server-side code, and opening them up by
>> adding more powerful and detailed APIs to these servers. Basically
>> turning the internal functionality of hosted applications into
>> something that's part of the web. But we can also start from the other
>> end, with the web as such, and add functionality to it. This paints a
>> different perspective on the same topic. I divide it into 6
>> requirements, or steps if you will: Indie Web, Webfinger, Read-Write
>> Web, Chat, Inbox, Comments.
>>
>> Step 1: "The Indie Web" - to be a citizen on the web, you need your
>> own web page which you can edit. It can have its own domain name, or a
>> subdomain, and it can be publically readable or restricted to a
>> specific audience, but the important thing is that there is content on
>> the web about you. An easy way to achieve this is for instance with
>> WordPress, but if you're a bit more technical you might prefer for
>> instance github pages.
>>
>
>
> Rich User Profiles
> ==============
>
> I've been thinking about the term, 'Rich User Profiles'.
>
>
> What do I mean by this?
> ===================
>
> Essentially on most sites on the web, you are allowed to have a user
> profile.  However, it's up to the provider of that software, to choose
> exactly the fields that they will allow you to fill in, in order to
> describe yourself.  This is a form of data restriction, as opposed to, data
> freedom.
>

Well if "freedom" means you don't want to define anything, then that's not
really very useful, is it.
But I agree you should be able to choose yourself what fields you want to
have on your profile

It's really hard to come up with a good schema for a Persona, or even to
choose one out of the many existing ones.
There's FOAF, there's hCard, there's http://schema.org/Person, or here is
another one: http://wiki.eclipse.org/Persona_Data_Model_2.0

Also, some of the companies here <http://pde.cc/startup-circle/> are
defining their own Person schemas/ontologies.
One of them (Mydex) has an ontology with 1000s of fields, supposedly
anything you would ever want to be able to express about a person.

I think the HTML5 data layer, can be a game changer, in that it will offer
> the user new possibilities, in terms of what you are able to do with data.
>

What is the "HTML5 data layer"?
- There are the data-* attributes, which are meant for use by JavaScript
within an HTML5 page.
- There is also HTML5 microdata, i.e. simple semantic markup for embedding
data in a page.
- Or do you mean Linked Data, RDF, JSON-LD, that sort of thing.


> Why would a user want to do this?
> ===========================
>
> It's a about freedom.   You make something free, and you make it better.
> The can apply to data as it does to free software.
>
> Simple example.  Allow a user to share their birthday and you can allow
> friends on the system to know when someone they know is about to have a
> birthday.
>
> More complex example.  If you let a user put a public key into there
> profile, then assuming they control the private key, they are able to login
> to any application on the web or on their desktop that can perform a PKI
> challenge (your private key is a way to prove you own the public key).
> With this simple step you change a static profile page, into a first class
> identity provider.
>

Sounds exactly like WebID.


> That was just an example, but the real story here is the law of
> "unintended consequences".  You allow people more freedom, and they will
> surprise you on the upside, in ways that you had never thought of.  This
> (data freedom on the web) is alo one of the main motivations behind the
> read write web.  Successful apps on the web, have proen that when you start
> trusting your users, to create content, they way they want to, you can
> start to gain exponential returns.
>
> Perhaps, one great place to start, is with Rich User Profiles.
>

I think this is what the WebBox is all about. Based on WebID and other web
technologies, you have your (flexible and extensible) profile and can
control who can access what.


>
>
>>
>> Step 2: "Webfinger" - Webfinger is the official way to publish your
>> public profile information on the web. It takes a user name and a
>> domain name as its parameters, and returns information like full name,
>> avatar picture in different sizes, home location, possibly some public
>> keys that the user has on the device(s) she often connects from, and
>> other contact information. It also links to any other information
>> sources about the user, like a foaf profile or an activity stream, and
>> possibly non-web contact methods like email addresses and jabber ID's.
>> Webfinger makes "users at hosts" into something the web as such can
>> understand in a unique and well-defined way.
>>
>> Step 3: "Read-Write Web" - the user should have full control (through
>> her preferred tools) to edit her web site. WordPress uses an
>> integrated hosted editor for this; github pages uses git. There was a
>> time that FTP and SharePoint were popular ways to update your website.
>> Now, there is a w3c community group call Read-Write Web that aims to
>> standardize the way editing tools interact with websites. It is
>> important that the user can choose whether data she stores becomes
>> public, private, or accessible to a limited audience. We are
>> finalizing a standard that unites three options: WebDAV, CouchDB, and
>> GetPutDelete. It allows for cross-origin access through HTTP CORS
>> headers, so your editing tool does not have to be hosted on your
>> website itself. You can edit website A with a tool that is hosted on
>> website B.
>>
>> After these three steps, you exist on the web as "you, 'at' your
>> domain", and that 'social web account' is already capable of storing
>> and retrieving private user data, as well as public and
>> limited-audience data. The web is useful for publishing public data,
>> but also for storing your own private data, like for instance your
>> address book, your calendar, and your diary or notebook. On top of
>> this, we can define semantics like html and ActivityStreams that
>> define how the content of these hosted documents should be interpreted
>> by the tools that read them and write them.
>>
>> This is basically where the web is now IMO. But there are three
>> functionalities we would really like to add to the web IMO:
>>
>> Step 4: "Chat" - receive pro-active updates about content, without
>> having to poll it, while you're online. This basically gives us chat.
>> It is not something the web has right now. Bosh seems to be the most
>> popular option for this right now, with research being done on webrtc
>> and xmpp-over-websocket. I'm working on an idea for websocket-hubs
>> myself as well, but haven't had much time so far.
>>
>> Step 5: "Inbox" - receive pro-active updates about content you follow,
>> without having to poll it, while you're offline. This is basically
>> (private) messaging. For this it's not necessary to receive the
>> messages instantly, it's good enough to require the client to retrieve
>> the pending messages once when connection is re-established.
>> Pubsubhubbub (PuSH) is a generic protocol for this; pingback and
>> salmon are specific ones. Note that none of these services work
>> cross-origin by default. There are at least 3 points involved when
>> Alice sends a message to Bob: Alice's browser, Bob's server, Bob's
>> browser, and possibly also Alice's server.  - If Bob's server does not
>> support CORS headers for Bob retrieving his messages, then that means
>> that the message viewing tool that runs in Bob's browser needs to be
>> hosted on Bob
>> 's server (same-origin policy).
>>   - If Bob's server does not support CORS headers for receiving
>> Alice's incoming message, then Alice will have to go through her own
>> server as an extra step (or use a tool hosted on Bob's server, but
>> that's unlikely to be Alice's preferred tool, so let's not consider
>> that option).
>>   - If then Alice's own server also doesn't have CORS headers enabled
>> for receiving the message to be relayed, that means that the sending
>> tool that runs in Alice's browser needs to be hosted on Alice's server
>> (same-origin policy).
>>
>> Step 6: "Comments" - have your server follow your instructions to
>> automatically republish (links to) certain third-party content while
>> you're offline. I believe this is part of salmon and also pretty
>> standard for comments on blogs, although often blogs don't allow
>> people to post comments using their own preferred tools.
>>   SWAT0 can be accomplished by just publishing content and receiving
>> messages (steps 1-5). Dave publishes the photo and the photo tag, and
>> sends a message to Tantek. Evan publishes the comment and sends a
>> message to both Dave and Tantek.
>>   But I would like to define a variation on SWAT0 (maybe this has been
>> discussed already), in which Dave publishes the photo, but then
>> instead of Dave tagging Tantek, Tantek tags himself in Dave's photo,
>> yet still receives the notification of Evan's comment. This is extra
>> difficult, because it requires the cooperation of Dave in Tantek and
>> Evan establishing communication. So either:
>>
>>   - Dave republishes Tantek's tag (so that Evan's publishing tool
>> knows to ping both Dave and Tantek about the comment), or
>>   - Tantek subscribes to the feed for the photo, and Dave republishes
>> Evan's comment on this feed.
>>
>> In both cases we need step 6 for this. Probably the second option is
>> preferable because it (presumably) allows Tantek to unsubscribe at
>> will, and unlike the first option it would still work if there are
>> thousands of people following the same photo comments wall. Salmon is
>> specific for receiving comments on content you published. I know of no
>> protocol that does this generically (defining a generic way for
>> clients to suggest content for addition to a web resource (probably a
>> feed) that's hosted on another user's webserver), but maybe someone
>> else know. If not, then maybe we should be working on that in this
>> community group?
>>
>> These 6 steps describe at a very low level what would be needed for
>> users to interact on the web - of course a lot of work is also needed
>> at higher levels, for instance, deciding on what verbs to allow in
>> ActivityStreams, but i think right now it's more urgent to first get
>> these 'transport channels' working.
>>
>> Cheers,
>>
>>
>> --
>> Michiel de Jong   http://unhosted.org/
>>
>>
>