Front page | perl.perl6.users |
Postings from May 2022
Re: author specification
From: Brad Gilbert
May 12, 2022 00:19
Re: author specification
Message ID: CAD2L-T1s5PUc666Ys4435Vh+wktm+ZLGMfWMNPfHq8HiL-7OBg@mail.gmail.com
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
On Wed, May 11, 2022 at 4:02 PM Darren Duncan <email@example.com>
> This discussion thread has excellent timing, because I was otherwise about
> come here and start a thread on the topic.
> I have been interested in the weeds of Raku's fully qualified compunit
> 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
> For a key example, Raku's fully qualified compunit naming convention has
> analogy in the Java world for versioning of JARs in Maven Central et al,
> Raku's base-name plus "auth" plus "ver" correspond to Maven's "groupId"
> "artifactId" plus version number. Or somewhat like "groupId", the typical
> package naming convention that starts with a reversed internet domain name
> 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
> Muldis Object Notation (MUON) and Muldis Data Language (MDL). Both my
> format/language specifications and artifacts/compunits are versioned with
> base name plus authority plus version number triplicate.
> The Raku docs seem to have evolved since then but the original mention of
> 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-http://www.some.com
> class Dog-1.2.1-mailto:firstname.lastname@example.org;
> class Dog-1.2.1-JRANDOM;
> class Dog-1.2.1-http://www.some.com/~jrandom;
> class Dogemail@example.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
> 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
> In the modern day, I see that the internet domain name system is the
> thing we have to a universal long term identity broker. A creator
> their name by registering and controlling the internet domain name.
> While possibly not strictly required, I believe this is that the Maven
> 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
> 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
> 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
> persons/orgs to distinguish themselves.
> When you have a Raku compunit Foo that is declaring its own fully
> 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
> compunit Bar by authority Y. This is like pointing to a fingerprint
> 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
> long as it is the same Bar.
> So if an author decides that their id is "CPAN:jrandom" then they should
> using "CPAN:jrandom" no matter where the artifacts are actually
> 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
> their own policies that identifies itself as "CPAN:jrandom".
> Independently from this, various repositories can have constraints that
> someone who has proven they own "CPAN:jrandom" on CPAN etc can upload
> 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 "http://muldis.com"
> 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"
> such, with the web in general treating unencrypted HTTP like an obsolete
> protocol people shouldn't be using anymore because security, it made me
> 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 "muldis.com" or alternately its reversed
> form, as an "auth" while making it explicit that this is an internet
> name, but without naming any protocols like "http" or "https" etc.
> Is there some kind of best standard format for indicating this, eg
> "domain:muldis.com" 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
> > 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
> > 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
> > development). She decides to distribute new Raku projects in zef
> > mirrored in CPAN because she loves metacpan's API and interface.
> > 3. New contributor has modules in GitHub account, is agnostic as to
> > 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
> >>>> goodies it offers. Now I see//that fez wants to start with
> >>>> and when I look at the raku.land site for a module of mine I
> see a
> >>>> remark /'/The uploading author of cpan:MARTIMM does not match
> >>>> META author of github:MARTIMM.' because I upload it to CPAN
> >>>> 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
> >>>> 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
> >>>> and changed by someone else or that it is still the same
> >>>> working on it?
> >>>> Regards,
> >>>> Marcel