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 <dar...@darrenduncan.net> 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 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" > 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 "muldis.com" 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 > "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 > 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 raku.land 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 >
