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

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

>
>
> On 18 July 2012 12:42, Markus Sabadello <markus.sabadello@gmail.com>wrote:
>
>>
>>
>> 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.
>>
>
> So, this is what I mean by "Rich User Profile".  Putting the user in
> control of their data.  Another option would simply be to allow users to
> link to their own file using the "sameAs" property.  Cant, be that hard,
> can it, adding one field? ;)
>

Just a matter of getting the user interface right, not a matter of FSW
architecture or protocols :)


> If you can tell me how I can get my public key into a FSW via salmon I'd
> be very grateful (if that is possible).
>

When you install Diaspora or status.net, they generate a key for you.
You can probably get your own key into those installations by loading it
somewhere into their database or configuration file.
But I don't know if anyone has ever done that.

You can discover the key via Webfinger/LRDD according to Magic Signatures /
Discovery (here<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html#anchor14>),
e.g.
1. You start with danube.status.net
2. You retrieve the http://danube.status.net/.well-known/host-meta
3. You retrieve the danube.status.net/main/xrd?uri=danube@danube.status.net
4. There's the public key


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