Let's blow some new life into this community group

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.

Cheers,


--
Michiel de Jong   http://unhosted.org/

Received on Wednesday, 4 July 2012 12:22:53 UTC