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

On Wed, Jul 18, 2012 at 1:39 PM, Melvin Carvalho
<melvincarvalho@gmail.com>wrote:

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

I would say maybe in the current implementations of FSW you can't do this..
But I don't think there is anything in OStatus or XMPP that mandates a
specific person schema or prevents implementations from letting users add
their own fields..

In Salmon, you have the ability to discover one's public key from a profile
page.


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