Re: [foaf-protocols] replacing email with atom and foaf+ssl

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:

  http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html


Full application of REST leads one inevitably to linked data. RDF provides
the semantics for that. (important note, that is still worth repeating:
RDF is not a format! proof: the RDFa html markup in the latest Facebook 
for example http://rdfa.info/2010/04/22/facebook-adopts-rdfa/ )


> Linked Data can represent anything we want, surely to use linked data
> rather than Atom would allow the scope of this to be so much more,
> allowing any kind of "message" to be sent.

See above.

But atom is widely used, widely understood. There is no reason atom 
cannot join foaf+ssl, so why not work together? Together we can
go much further.

> 
> Sioc:Container and Items together with the additional sioc type
> extensions would appear to cover 99% of scenarios.

Yes, with Atom/Owl they just provide a semantics for Atom xml. The 
thing is that a lot of blogging clients understand Atom publication protocol.
It would be very easy for them to add foaf+ssl support - that would just
require at the minimum adding ssl support! 

> Considerations of SPARUL, SPARQL and SPARQL+Pubsubhubbub for custom
> notification streams.

Those are nice. But why use them when they are not needed? They will
be useful at some point. Let us use them, where and when they are needed.
The time will certainly come for them. But this application does 
not require them, and it could be really big.

But I see you agree with me below... :-)

> 
> However, Atom(/Pub) is already here, defined, widely accepted and would
> allow a quick implementation without too much work, and you could ensure
> that each message could be handled due to having set parameters in Atom
> (whereas in linked data it could be any ontology with no guaranteed
> presence of rdfs:label or suchlike)
> 
> Further, Atom(/Pub) would add in much scope for current work on the
> likes of activitystrea.ms to be incorporated / made interoperable etc.
> (and possibly OData/GData..?)

Yes. Possibly. I have not followed those that closely, so I can't comment
on them.

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.

> 
> Best,
> Nathan

Received on Monday, 3 May 2010 20:43:55 UTC