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

On 18 July 2012 11:29, Markus Sabadello <markus.sabadello@gmail.com> wrote:

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

Yes linked data.  I would use RDFa 1.1 or RDFa lite 1.1, which were made
RECS last month.


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

It's just the old fashioned idea of displaying your public key.  Yes it's
100% compatible with WebID or another PKI solution.

But in the FSW you *cant* do this, as far as I know.  That is simply not
data freedom.  It's swapping one form of centralized control for another.


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

Again, it's not about the specific implementation, tho I'm sure WebBox is
one.  It's about data freedom.


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