W3C home > Mailing lists > Public > public-solid@w3.org > March 2019

Re: W3C Solid Community Group Call in Details

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Thu, 21 Mar 2019 14:36:11 +0100
Message-ID: <CAKaEYhJERwYZ5Edqi8Ttbpb19mrnhnjmhcqKO3WMikWtMyBzLQ@mail.gmail.com>
To: Michiel de Jong <michiel@unhosted.org>
Cc: Mitzi László <mitzil@inrupt.com>, public-solid <public-solid@w3.org>
On Thu, 21 Mar 2019 at 14:08, Michiel de Jong <michiel@unhosted.org> wrote:

> The minutes are here: https://www.w3.org/2019/03/21-solid-minutes.html

Good minutes, thanks!

Dmitri, I've also been discussing a functional did spec with manu

There are some important design decisions which give different
functionality, and the devil is in the details.

It strikes me that there is a LOT of devil in the detail, which will
produce very different types of eco system.

The good news is that the DID specs lend itself to be able to work on more
than one, but it might make more sense to try and come up with a common
design goals

Examples being around the type of key material used, the serialization of
that key material, conversion via a trap do function (aka hash) to an UUID,
one-one relations or one-many relations, whether to use a block chain /
distributed ledger / or LDPC, bootstrapping a central registry, discovery,
importantly for solid turtle vs json-ld support and how that relates to
relative URIs and so on.

What I suggest is we start with something very simple which bootstraps our
existing infrastructure.  For example having a content addressable document
(did) for each key in a webid on a one-to-one (isomorphic) basis seems to
be low hanging fruit, then allowing the CRUD operations to happen via the
HTTP verbs and PATCH with our own dialect of sparql update.  I suppose that
will mean having to write up sparql-update-solid someplace.

With that part in place, we could perhaps look at various other directions
we might like to take it, as a more formal spec.  But having a long lasting
document for public keys is in itself valuable, keybase are an example who
found unexpected reuse in this respect.


> On Thu, Mar 21, 2019 at 8:08 AM Mitzi László <mitzil@inrupt.com> wrote:
>>  https://zoom.us/j/121552099
Received on Thursday, 21 March 2019 13:36:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:39 UTC