develooper Front page | perl.perl6.users | Postings from May 2022

Re: author specification

Thread Previous
Brad Gilbert
May 12, 2022 00:19
Re: author specification
Message ID:
After thinking on it, :auth<> is sort of an authentication chain. Just a
really short one.

To authenticate a module with :auth<zef:b2gills> you have to first
authenticate zef.

On Wed, May 11, 2022 at 4:02 PM Darren Duncan <>

> 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
> 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 "
> 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-
>      class;
>      class Dog-1.2.1-JRANDOM;
>      class Dog-1.2.1-;
>      class;
> 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
> "" as the authority/auth for my specs and compunits
> etc.  See
> for a specific example, both the VERSION at the top, as well as the
> 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 same person.
> So "auth" is really about portable identities, not repositories.
> Now as for the original reason I was going to start this thread...
> Per the Apocalypse 12 example, originally I was using ""
> qualified with "https://" as a seeming standard way of being explicit
> that my
> "auth" is an internet domain name and not say a CPAN id or whatever.
> However, per developments in the last few years like "HTTPS Everywhere"
> and
> such, with the web in general treating unencrypted HTTP like an obsolete
> protocol people shouldn't be using anymore because security, it made me
> think
> that I need to rethink my own "auth".
> So something I was hoping to get input on is what is a recommended way to
> use an
> internet domain name, say "" or alternately its reversed
> "com.muldis"
> form, as an "auth" while making it explicit that this is an internet
> domain
> name, but without naming any protocols like "http" or "https" etc.
> Is there some kind of best standard format for indicating this, eg
> "" but standard?
> So what are thoughts on what I said?
> -- Darren Duncan
> On 2022-05-06 6:48 a.m., yary wrote:
> > But I'm understanding from this conversation is that people have
> different ideas
> > of what the auth field means.
> >
> > 1. It shows who is responsible for this code. It is independent of which
> home
> > the author chooses, where home is GitHub, gitlab, cpan, zef,p6c etc.
> > 2. It shows who is responsible for this code, and its main home. Auth
> does not
> > change when stored on other homes.
> > 3. It shows who's responsible for this code in this home. It changes
> depending
> > on which home it is being uploaded to.
> >
> > So it helps to consider some cases and how we handle it.
> > 1. Long time Perl contributor has a CPAN authority, and decides to
> migrate all
> > existing projects to github as a main home.
> > 2. Long time perl contributor has a CPAN authority, no Git account
> (local
> > development). She decides to distribute new Raku projects in zef
> primarily,
> > mirrored in CPAN because she loves metacpan's API and interface.
> > 3. New contributor has modules in GitHub account, is agnostic as to
> ecosystems.
> > Wants every ecosystem to reflect latest pushes to main branch in their
> git account.
> >
> > How should the auth field work for these cases?
> >
> > More cases welcome... (Welcome to the bikeshead? 🚲🏘️🔵💚💜😢)
> >
> >
> >>>>
> >>>>     On Mon, May 2, 2022, 3:23 PM Marcel Timmerman wrote:
> >>>>
> >>>>         Hi,
> >>>>
> >>>>         I was wondering about the 'auth' specification in the meta
> file or
> >>>>         on the class/module/package. I was used to specify it as
> >>>>         'github:MARTIMM' because I store the stuff on GitHub for all
> the
> >>>>         goodies it offers. Now I see//that fez wants to start with
> 'fez:'
> >>>>         and when I look at the site for a module of mine I
> see a
> >>>>         remark /'/The uploading author of cpan:MARTIMM does not match
> the
> >>>>         META author of github:MARTIMM.' because I upload it to CPAN
> nowadays
> >>>>         and have never specified somewhere that the auth has become
> >>>>         'cpan:MARTIMM'.
> >>>>
> >>>>         I feel that this is not useful (even correct) to pin someone
> to use
> >>>>         an auth specification with a defined prefix for some
> ecosystem one
> >>>>         is using. So changing to another ecosystem forces that person
> to
> >>>>         change the auth everywhere in its code and meta files to get
> rid of
> >>>>         any errors or warnings. Besides that, the change of the
> author on
> >>>>         the same code poses the question later on, if that code is
> forked
> >>>>         and changed by someone else or that it is still the same
> developer
> >>>>         working on it?
> >>>>
> >>>>         Regards,
> >>>>         Marcel

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About