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

I have a slightly different take on this.

The Web is designed to be the 'intersection of information spaces'.  This
includes documents and things, and was designed to be social from the
start.  But the web can also handle things like chat (gtalk, facebook,
webchat), email (hotmail, gmail etc.).  Whether you host it yourself or let
someone else host it should be up to you (pros and cons in either case).
The web was designed to be a read/write space, rather than, browse only.
Attempts to build this into early browsers were met with 'its too hard' as
a response, but we've not given up and effort continues.

There's no 'official' method of publishing, and every time you try and
constrain the web, it breaks free, due to it's scale free nature.  Certain
patterns (such as linked data) are recommended and growing.

Universal systems tend to be interoperable (the secret sauce is using a URI
to name things).  Local systems (often with local identifiers) or other
protocols at least the successful one will also probably in the long term
integrate with the web.  Kind of a democracy of ideas.  It's all good, and
let the best ideas rise to the top.  Hopefully it will all come together on
the Web, indeed, what may become named the 'Federated Social Web'.


>
> Cheers,
>
>
> --
> Michiel de Jong   http://unhosted.org/
>
>