- From: Nathan <nathan@webr3.org>
- Date: Mon, 03 May 2010 22:02:19 +0100
- To: Story Henry <henry.story@bblfish.net>
- CC: Protocol Atom-Protocol <atom-protocol@imc.org>, "public-lod@w3.org community" <public-lod@w3.org>, foaf-protocols@lists.foaf-project.org
Story Henry wrote: > On 3 May 2010, at 21:22, Nathan wrote: > >> Story Henry wrote: >>> [snip >>> 2. The Solution >>> --------------- >>> >>> 2.1 RESTful Identity and Authentication >>> --------------------------------------- >>> >>> foaf+ssl gives us WebIds, global identifiers tied to a public key, which allows >>> one click authentication. This works in all browsers. >>> There is more here: http://esw.w3.org/Foaf%2Bssl/FAQ >>> You can try some early demos out by going to http://webid.myxwiki.org/ for example or >>> any of the list of Identity Providers http://esw.w3.org/Foaf%2Bssl/IDP >>> >>> Without foaf+ssl this is not really possible. Getting a username/password for >>> each of one's friends web servers would be impossibly complex, tedious and >>> insecure. OpenId is close, but still too complex, though it can also be made to work >>> nicely with foaf+ssl. >>> >>> >>> 2.2 A ping mechanism >>> -------------------- >>> >>> It just requires one new relation to be added to a foaf file. A link to a simple >>> form, which could be a atompub:Collection / sioc:Container [1]. I went into this in >>> great detail in a recent post where I cover what I know of the pinging mechanism >>> history, and show how this can be simplified further. >>> >>> http://markmail.org/message/kzsg3qntovmqzbje >>> >>> Writing such a pinging mechansim is really really easy. Adding a relation to a foaf is also >>> easy, as we can see from the recent adoption by Facebook, which is rdfa enabling all >>> its web pages. >>> [snip] >> Henry, >> >> Good call, I've been thinking about this a lot recently and there is >> certainly a huge amount of scope. >> >> Things I'm certain of: >> >> - FOAF+SSL is needed >> - HTTP should be the interface >> - all communications should be handled RESTfully >> - Resources should be Web Access Controlled (via ACL+WebID) >> - The receive flow should be: notification of new message, GET message >> >> Thing(s) I'm unsure of: >> >> - Atom(/Pub) vs LinkedData > > I am not sure the 'vs' is justfied. Atom is a format, which can be GRDDLed > into RDF. See the Atom/OWL work for example: Agreed, more a short bit of focus or clarification on inserting additional meta/linked data in to Atom, but this is an aside.. main question below: > The great thing is that it ties atom very lightly into a global > social network, which means that it will be all the more powerful as > a result. > > >> Side: >> By defining a standardized HTTP RESTful messaging system with FOAF+SSL >> and Web Access Control you remove all implementation specific details >> and make something forwards and backwards compatible, so vendors could >> easily adopt this whilst remaining in control of backwards compatibility >> points (routing messages to email, xmpp, sms etc - preferences for >> notifications of messages from certain sources - prioritization of >> message deliver messages based on rules). > > yes. It would be very nicely backward compatible. A very minor tweak, > with a huge upside. > >> At the same time it would simplify many types of communication from >> service to service and encourage adoption of webid's, foaf+ssl. > > And of Atom itself. :-) > >> All in all: >> Sounds feasible and pretty much fully spec'd if going down the atompub >> route, perhaps linked data + sparql/sparul/pubsubhubbub is the long term >> route but I'm quite sure it would take a bit more work to both implement >> and encourage adoption. Brining the REST and Linked Data communities >> together is critical though, and can only be a good thing for the future >> of the web. >> >> Thanks for bringing this to the table Henry, > > Thanks for the feedback, and helping me clarify. > My primary question - in order to get on and start prototyping - is what to use as the property to link a webid to the atompub container(s). on second thoughts, I'd like to negate the container(s) above with preference going to a single notification stream per webid / persona which they can subscribe to from a variety of clients and devices. fully agree though, this is something that can be adopted very quickly and will have huge benefits. the costs of adopting are negligible compared to the benefits. any other details needing covered? Best, Nathan
Received on Monday, 3 May 2010 21:03:03 UTC