Re: WebID default serialization for WebID 2.x

On Tue, 25 Jan 2022 at 11:33, Jonas Smedegaard <jonas@jones.dk> wrote:

> Quoting Jacopo Scazzosi (2022-01-25 09:36:31)
> > > Are you really sure that you want the *IDENTIFIER* to define the
> > > rules of the game - e.g. ensure future compatibility?
> > >
> > > I strongly recommend to place constraints on *extension* specs -
> > > e.g. Solid spec might say that it can only ever work with yellow
> > > identifiers.
> >
> > Jonas and Kingsley, I think I understand your point but I struggle to
> > reconcile it with those scenarios in which updating software might not
> > be as easy as we'd like it to be.
> >
> > I appreciate how your approach, by eliminating conneg and MUSTs, would
> > lend itself to a whole spectrum of WebID publishers, from static
> > resources to conneg-enabled multi-format WebID servers. However, I
> > can't see an easy way for WebID clients to keep up.
> >
> > For example, let's assume a super-successful WebID 2.0 and let's say I
> > am working on a device with an embedded WebID client. One of my goals
> > in building such a device according to a standard such as WebID would
> > be to decouple the lifetime of the device itself from that of the
> > company that makes it, at least to the greater possible extent.
> > Hardware should not break and become unusable when the manifacturer
> > ceases to exist. In this scenario, wouldn't a WebID spec without a
> > default serialization format enforced via MUST be extremely prone to
> > shortening the lifespan of the device itself even in a world that
> > fully embraces WebID?
> >
> > I do feel that I might be missing something but I don't want to
> > monopolize this thread. I would be grateful if you could point me to
> > any resources that might help me understand your approach, also
> > privately. You've probably been making these points for a long time,
> > particularly to those who prefer a single default serialization format
> > like I do, and I appreciate the effort in maintaining the kind and
> > welcoming attitude.
>
> Looking at "identifier" as a core building block, it makes some sense to
> compare with an image.
>
>   * 1990s best practice: encode as gif (jpeg is slow)
>   * 2000s best practice: encode as jpeg (gif has limited colorspace)
>   * 2020s best practice: encode as WebP (computation is cheap)
>
> Best practices change, but does not necessarily imply that old practice
> becomes incompatible for newer tools - sometimes it means older practice
> works equally well as before but newer techniques emerge that are more
> efficient and therefore preferred.
>
> Looking at "identification" as a core procedure to exchange and parse an
> identifier, it makes some sense to compare with providing live content
> on an otherwise static web page.
>
>   * 1990s best practice: embed Java content
>   * 2000s best practice: embed flash content
>   * 2010s best practice: code as ECMAScript, 5th Edition
>   * 2020s best practice: code as ECMAScript 2015 or newer
>
> Some of those older techniques still work today but some does not.  We
> could not have written a spec in the 1990s to future-proof techniques
> available back then - requiring specific techniques would only have made
> the specs *less* attractive to adopt.
>
> These are some draft specs we have today:
>
>   * WebID: how to identify in a way that is resolvable
>     + resolving MUST be possible using Turtle
>   * WebID-TLS: how to resolve and prove a WebID using TLS
>   * WebID-OIDC: how to resolve a WebID using OIDC
>   * Solid-OIDC: how to resolve some identifier using OIDC
>     + identifier format can be WebID, but Turtle is unused
>   * Solid: how to exchange messages identified somehow
>     + identifier format can be WebID, but Turtle is unused
>
> Notice how there are two specs for how to resolve using OIDC? Difference
> is that one is supposedly generic but you MUST implement support for
> parsing Turtle - the other is supposedly specific to Solid but really is
> the more generic of those two - it was created *only* to permit not only
> WebID but also NetID-same-as-WebID-except-not-mandating-Turtle.
>
> Creating duplicate specs is not helpful.
>
> Modernizing the specs by repeating same mistake just replacing "Turtle"
> with "JSON" or "JSON-LD" is short-sighted: It might feel simpler for
> current adopters but is the *opposite* of future-proof same as requiring
> Turtle was in the 2000s.
>
> What would be helpful was to *drop* the Turtle requirement (without
> replacing it with another serialization requirement), so WebID was
> flexible enought to be *the* identifier format in other specs:
>
>   * WebID: how to identify in a way that is resolvable
>   * WebID-TLS: how to resolve a WebID using TLS
>   * WebID-OIDC: how to resolve a WebID using OIDC
>   * Solid: how to exchange messages identified using WebID
>
> I want WebID to be *the* identifier format for RDF, not bound by some
> best practice of some age.
>
> Sorry if I monopolize this thread.  Please don't be polite but shout at
> me if you feel that I am wrong and this thread really is about something
> else than my pet vision of WebID.
>

I agree that SHOULD favours future proofing and MUST favours deployment --
I personally think deployment trumps future proofing

But I can live with either provided that clear examples and deployment
instructions are given.  Accessible to non-experts.  And deployable without
highly specialist software

The use case of an embedded agent that you can just leave running,
resonates with me alot.  That's basically a thing I also want to create

I dont see JSON being replaced before 2030 and I think MUST would get us
there.  Also versioning will be improved by then and upgrades smoother.

Someone asked me out of band if this tiny example would work as a WebID:

{
  "@id": "<webid>",
   "@type": Agent,
   "name": "whatever",
   "public_keys": [a,b,c]
}

While not perfect, its seems not far off at all.

Imagine if WebID were that simple.  You could use it today, already with
the public keys it will handle auth, and extensible to many other things.


>
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private