Re: Quick summary - Re: WebID lack of adoption, was Re: Turtle and JSON-LD Matter

On 20 Jul 2014, at 13:26, Sandro Hawke <sandro@w3.org> wrote:

> On July 20, 2014 2:42:17 AM EDT, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote:
>> On the Turtle discussion: I completely agree with Sandro's explanation 
>> for why one should restrict the syntaxes to a MUST for Turtle. Anyone 
>> is free to add more syntaxes to their servers, including JSON-LD. Later
>> 
>> we can revise this. Not having mandatory syntax lead to client
>> complexity 
>> that would create barriers for adoption. ( I will add a JSON-LD Parser 
>> as soon as I find one to rww-play )
>> 
>> As to Sandro's points about WebID+TLS's lack of adoption, this has more
>> to 
>> do in my view with lack of good applications being build. myprofile.eu 
>> currently WebID-Auth does not work for example. WebID Auth really comes
>> 
>> into its own with systems like LDP and Web Access control, and these
>> are 
>> just being finalised. So instead of wasting time discussing lack of
>> adoption,
>> I'd say just take LDP + WebID + WAC and write some cool decentralised
>> apps.
>> 
>> The rest of Sandro's arguments about hash uri's are just waste of time
>> arguments. 
>> - I never had problems explaining this to developers, and getting
>> very good understanding. If you explain it correctly as in the
>> diagram its easy.
>> - The WebID URIs are not meant to be viewed or written by end-user.
>> They go into certificates ( TLS or JSON LD ones when they come ) and
>> are linked to by other profiles. Users just click buttons. WebID Uris 
>> are efficient _and_ user friendly because no user needs to handle the
>> URIs.
>> 
>> 
>> The problem is that developing good LinkedData client apps is
>> difficult. It 
>> requires some excellent client side JS libraries to be developed that
>> deal 
>> with asynchronous processing, requires quad storage on the client,
>> partial downloads
>> of graphs, and many other things, as I discovered working with my
>> ex-startup
>> in Paris. This can be made easy by developing good client side
>> libraries. Which
>> is why we are working on this now
>> 
>> So the reason WebID has lack of adoption is that it requires one to
>> build
>> LinkedData apps, and few people know how to do this, in a way that is
>> appealing,
>> useful, beautiful and sexy. 
>> 
>> 	Henry
> 
> I'm confused by this last point, Henry.   I'd like a decentralized authentication system that works for all web apps, not just those built around linked data.  My critique of WebID is from that angle, but now I'm wondering if you share that goal.

Thanks for pointing this out. The word "required" was too strong.  WebID Authentication ( eg: WebID TLS, but one could easily imagine a WebID-Persona ), will work without linked data . 

I meant that the advantages of WebID-TLS are most evident when used with LinkedData:
 1. The efficiency gains over other protocols becomes more and more evident when you write apps that need to authenticate across many web servers. That is evidently what LinkedData apps need to do and so they are the prime use case for WebID. 
 2. The distributed trust system that LinkedData allows is what helps counter the need for Certificate Authorities which is a key notion many other systems are built around or which they lack. 

So don't be surprised if applications that don't use LinkedData can be happy using much less efficient
authentication systems like OpenId. 

WebID comes into its own when writing linked data apps. Without LDP, doing that was possible but was going
to be lacking in a lot of functionality. With LDP+WebID+WAC you still need to build very good client libs,
and build valuable applications. It seems quite obvious to me that this is where a lot of real work needs to be 
done. 

> (I am okay with requiring relying parties to run JavaScript in the browser; the system doesn't have to work for web apps that are entirely server-side.)

Yes, apps could be 
 1. entirely server driven -  server fetches data, pubishes it as static html 
    one could do this easily with rww-play 
     https://github.com/read-write-web/rww-play
 2. entirely client driven - eg: 
     - tabulator 
     - react-foaf https://github.com/read-write-web/react-foaf
      ( incomplete )
 3. a mixture of both.

Received on Sunday, 20 July 2014 13:42:06 UTC