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

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


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.

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.



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