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

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? ;)

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


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