After thinking on it, :auth<> is sort of an authentication chain. Just a
really short one.
To authenticate a module with :auth you have to first
authenticate zef.
On Wed, May 11, 2022 at 4:02 PM Darren Duncan
wrote:
> This discussion thread has excellent timing, because I was otherwise about
> to
> come here and start a thread on the topic.
>
> I have been interested in the weeds of Raku's fully qualified compunit
> naming
> convention for a long long time, since I first saw it in Larry's
> Apocalypse 12
> https://raku.org/archive/doc/design/apo/A12.html section on "Versioning".
>
> My interest is not only for the Raku ecosystem itself but also its
> generalization into programming languages or code repositories in the
> abstract.
>
> For a key example, Raku's fully qualified compunit naming convention has
> an
> analogy in the Java world for versioning of JARs in Maven Central et al,
> where
> Raku's base-name plus "auth" plus "ver" correspond to Maven's "groupId"
> plus
> "artifactId" plus version number. Or somewhat like "groupId", the typical
> Java
> package naming convention that starts with a reversed internet domain name
> of
> the creator.
>
> Many years ago (before I knew about Maven etc) I adopted the Raku fully
> qualified compunit naming convention for my own Raku-inspired projects
> including
> Muldis Object Notation (MUON) and Muldis Data Language (MDL). Both my
> format/language specifications and artifacts/compunits are versioned with
> the
> base name plus authority plus version number triplicate.
>
> The Raku docs seem to have evolved since then but the original mention of
> "auth"
> in Apocalypse 12 highlighted internet domain names such as "
> http://www.some.com;
> as an option, I quote (slightly paraphrased):
>
> The syntax of a versioned class declaration looks like this:
>
> class Dog-1.2.1-cpan:JRANDOM;
> class Dog-1.2.1-http://www.some.com
> class Dog-1.2.1-mailto:jran...@some.com;
>
> class Dog-1.2.1-JRANDOM;
> class Dog-1.2.1-http://www.some.com/~jrandom;
> class dog-1.2.1-jran...@some.com;
>
> For perhaps one of my most important contributions to this thread...
>
> The way I see it, the best interpretation of "auth" is the more abstract
> "authority" which is some kind of unique identifier for a real person or
> organization that is releasing the artifact. This should be abstracted
> away as
> much as possible from any actual repositories where the artifact is
> available.
>
> If the general form of "auth" is basically "foo:bar" where "foo" defines a
> delegating authority that controls a namespace and "bar" is the artifact
> releasor's reserved name in that namespace, then it means "auth" is more a
> lookup in an identity broker which is orthogonal to where the artifacts
> are
> distributed.
>
> In the modern day, I see that the internet domain name system is the
> closest
> thing we have to a universal long term identity broker. A creator
> reserves
> their name by registering and controlling the internet domain name.
>
> While possibly not strictly required, I believe this is that the Maven
> "groupId"
> and more generally the long-term practice of Java package names has done.
>
> For my part, long ago, inspired by Apocalypse 12, I started using
> "http://muldis.com; as the authority/auth for my specs and compunits
> etc. See
>
> https://github.com/muldis/Muldis_Object_Notation/blob/master/spec/Muldis_Object_Notation.md
> for a specific example, both the VERSION at the top, as well as the
> VERSIONING
> section at the bottom.
>
> The way I see it, though an author or distributor may use different
> repositories
> such as CPAN or Github to distribute things, all distributions by the same
> person/org should use the same "auth", and different "auth" are for
> different
> persons/orgs to distinguish themselves.
>
> When you have a Raku compunit Foo that is declaring its own fully
> qualified
> version, or is declaring its dependencies' fully qualified versions, they
> shouldn't have to be more specific than saying, I am authority X, and I
> want
> compunit Bar by authority Y. This is like pointing to a fingerprint
> identifier,
> and that association should not break just because Bar is being
> distributed in
> different places, and it shouldn't matter where the end user gets Bar from
> as
> long as it is the same Bar.
>
> So if an author decides that their id is "CPAN:jrandom" then they should
> keep
> using "CPAN:jrandom" no matter where the artifacts are actually
> distributed.
> This "CPAN:jrandom" isn't an instruction to get the module from CPAN, it
> is just
> an instruction to get a module from anywhere the user is comfortable with
> per
> their own policies that identifies itself as "CPAN:jrandom".
>
> Independently from this, various repositories can have constraints that
> only
> someone who has proven they own "CPAN:jrandom" on CPAN etc can upload
> things
> with that auth, or at least while claiming that they are the
