Re: author specification

[Brad Gilbert]

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 

Re: author specification

[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 
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 

Re: author specification

[yary]

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 Wed, May 4, 2022, 6:43 AM Marcel Timmerman  wrote:

> Hi Vadim,
>
> I'd put it this way: this API has not been stabilized yet. Though at the
> moment it's coming to some consensus.
>
> Hopefully it would not be necessary to change the auth field which is the
> main issue of mine. Because fez is registering the user on its first run,
> the auth field is not needed to find the username later on.
>
> Come to think of it, starting the auth field with 'fez' when it is stored
> on the fez ecosystem, cpan on the cpan system, etc. is information which is
> redundant. fez is checking the ecosystems one by one to find distributions
> just to find an auth starting with the same name as the ecosystem it is
> accessing.
>
> Currently the only ecosystem with authentication is zef. In order to
> publish there fez would ask your password once in a while. This is also why
> all other ecosystems are considered deprecated.
>
> I still have some trouble with fez just because of this auth field I
> think. There are others with the same issue.
>
> Best regards,
> Vadim Belman
>
>
> Thanks for your information, I'll wait for its outcome,
> Regards,
> Marcel
>
>
> On May 3, 2022, at 11:59 AM, Marcel Timmerman  wrote:
>
> Hi Brad,
>
> Auth is for more than just the author. It is for author, authority, and
> authentication.
>
> There is no password or other cryptographic way, so authentication is not
> possible. Obviously, I might miss some insight here.
>
> In the documentation I read; ":auth generally takes the form hosting:ID,
> as in github:github-user or gitlab:gitlab-user". For me, hosting is e.g.
> on GitHub or Gitlab to store the software, and ecosystems are for spreading
> the word, i.e. telling that there is a software available somewhere, and
> this somewhere is not important. That is the work for zef to find out.
>
> And the word 'generally' means that it is just an example, it is in the
> end just a string.
> Furthermore, there is no mention in the docs of any use other than naming
> it in a useful way. No remarks of needing it to login into some ecosystem
> and no word about that separator, being a column, or split it up in more
> than two fields using an other character.
>
> Searching through some distributions I find 'zef:lizmat', 'github:MARTIMM',
> 'tonyo', 'cpan:WARRINGD', 'github:ccworld1000, ccworld1...@gmail.com,
> 2291108...@qq.com', showing that there is absolutely no clear way to use
> that field. For me, it means again that the auth field must be completely
> free and the same, independent of the ecosystem in use.
>
> CPAN can't authenticate github or fez modules, and vice versa. There is a
> reason the field is only the first four letters.
>
> The word 'github' is longer.
>
> That they are seen as different modules is an intended feature, not a bug.
>
> I didn't want to say that it was a bug, sorry for the confusion.
>
> I would like to know how you would want the system to handle a module from
> me. cpan:BGILLS github:b2gills and I intend to get b2gills on fez as well.
> (CPAN doesn't allow numbers, otherwise I would have it there to.)
>
> Do you want to write several meta files with different auth fields
> depending on the ecosystem you want to send it to? The only thing you can
> do without much work is sending a project e.g. to fez and another to cpan
> but I don't see the use of spreading your projects over several ecosystems.
>
> Also for a class you wrote, JSON::Class, what should I write (I took it to
> the extreme of course, 'use JSON::Class' would do)
>
> use JSON::Class:auth;
> use JSON::Class:auth;
> use JSON::Class:auth;
>
> All three are getting the same software, or not, when it is someone els-es
> auth.
>
> What if someone else took a user name on github that matched one on CPAN
> or fez?
>
> That is the point I want to make. Keeping the auth 

Re: author specification

[Marcel Timmerman]

Hi Vadim,
I'd put it this way: this API has not been stabilized yet. Though at 
the moment it's coming to some consensus.
Hopefully it would not be necessary to change the auth field which is 
the main issue of mine. Because fez is registering the user on its first 
run, the auth field is not needed to find the username later on.


Come to think of it, starting the auth field with 'fez' when it is 
stored on the fez ecosystem, cpan on the cpan system, etc. is 
information which is redundant. fez is checking the ecosystems one by 
one to find distributions just to find an auth starting with the same 
name as the ecosystem it is accessing.


Currently the only ecosystem with authentication is zef. In order to 
publish there fez would ask your password once in a while. This is 
also why all other ecosystems are considered deprecated.
I still have some trouble with fez just because of this auth field I 
think. There are others with the same issue.



Best regards,
Vadim Belman


Thanks for your information, I'll wait for its outcome,
Regards,
Marcel



On May 3, 2022, at 11:59 AM, Marcel Timmerman  wrote:

Hi Brad,

Auth is for more than just the author. It is for author, authority, 
and authentication.
There is no password or other cryptographic way, so authentication is 
not possible. Obviously, I might miss some insight here.


In the documentation I read; "|:auth| generally takes the form 
|hosting:ID|, as in |github:github-user| or |gitlab:gitlab-user|". 
For me, hosting is e.g. on GitHub or Gitlab to store the software, 
and ecosystems are for spreading the word, i.e. telling that there is 
a software available somewhere, and this somewhere is not important. 
That is the work for zef to find out.


And the word 'generally' means that it is just an example, it is in 
the end just a string.
Furthermore, there is no mention in the docs of any use other than 
naming it in a useful way. No remarks of needing it to login into 
some ecosystem and no word about that separator, being a column, or 
split it up in more than two fields using an other character.


Searching through some distributions I find 'zef:lizmat', 
'github:MARTIMM', 'tonyo', 'cpan:WARRINGD', 'github:ccworld1000, 
ccworld1...@gmail.com, 2291108...@qq.com', showing that there is 
absolutely no clear way to use that field. For me, it means again 
that the auth field must be completely free and the same, independent 
of the ecosystem in use.


CPAN can't authenticate github or fez modules, and vice versa. There 
is a reason the field is only the first four letters.

The word 'github' is longer.

That they are seen as different modules is an intended feature, not 
a bug.

I didn't want to say that it was a bug, sorry for the confusion.

I would like to know how you would want the system to handle a 
module from me. cpan:BGILLS github:b2gills and I intend to get 
b2gills on fez as well. (CPAN doesn't allow numbers, otherwise I 
would have it there to.)
Do you want to write several meta files with different auth fields 
depending on the ecosystem you want to send it to? The only thing you 
can do without much work is sending a project e.g. to fez and another 
to cpan but I don't see the use of spreading your projects over 
several ecosystems.


Also for a class you wrote, JSON::Class, what should I write (I took 
it to the extreme of course, 'use JSON::Class' would do)


use JSON::Class:auth;
use JSON::Class:auth;
use JSON::Class:auth;

All three are getting the same software, or not, when it is someone 
els-es auth.


What if someone else took a user name on github that matched one on 
CPAN or fez?
That is the point I want to make. Keeping the auth field the same 
everywhere, independent of ecosystem, will show that the software is 
the same everywhere. If that someone has the same account name as 
someone else on cpan or fez it will show a difference in the auth field.


So, I think there is a lot to ponder over
Regards,
Marcel



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
 

Re: author specification

[Vadim Belman]

I'd put it this way: this API has not been stabilized yet. Though at the moment 
it's coming to some consensus.

Currently the only ecosystem with authentication is zef. In order to publish 
there fez would ask your password once in a while. This is also why all other 
ecosystems are considered deprecated.

Best regards,
Vadim Belman

> On May 3, 2022, at 11:59 AM, Marcel Timmerman  wrote:
> 
> Hi Brad,
> 
>> Auth is for more than just the author. It is for author, authority, and 
>> authentication.
> There is no password or other cryptographic way, so authentication is not 
> possible. Obviously, I might miss some insight here.
> 
> In the documentation I read; ":auth generally takes the form hosting:ID, as 
> in github:github-user or gitlab:gitlab-user". For me, hosting is e.g. on 
> GitHub or Gitlab to store the software, and ecosystems are for spreading the 
> word, i.e. telling that there is a software available somewhere, and this 
> somewhere is not important. That is the work for zef to find out.
> 
> And the word 'generally' means that it is just an example, it is in the end 
> just a string. 
> Furthermore, there is no mention in the docs of any use other than naming it 
> in a useful way. No remarks of needing it to login into some ecosystem and no 
> word about that separator, being a column, or split it up in more than two 
> fields using an other character.
> 
> Searching through some distributions I find 'zef:lizmat', 'github:MARTIMM', 
> 'tonyo', 'cpan:WARRINGD', 'github:ccworld1000, ccworld1...@gmail.com 
> , 2291108...@qq.com 
> ', showing that there is absolutely no clear way to 
> use that field. For me, it means again that the auth field must be completely 
> free and the same, independent of the ecosystem in use.
> 
>> CPAN can't authenticate github or fez modules, and vice versa. There is a 
>> reason the field is only the first four letters.
> The word 'github' is longer.
> 
>> That they are seen as different modules is an intended feature, not a bug.
> I didn't want to say that it was a bug, sorry for the confusion.
> 
>> I would like to know how you would want the system to handle a module from 
>> me. cpan:BGILLS github:b2gills and I intend to get b2gills on fez as well. 
>> (CPAN doesn't allow numbers, otherwise I would have it there to.)
> Do you want to write several meta files with different auth fields depending 
> on the ecosystem you want to send it to? The only thing you can do without 
> much work is sending a project e.g. to fez and another to cpan but I don't 
> see the use of spreading your projects over several ecosystems.
> 
> Also for a class you wrote, JSON::Class, what should I write (I took it to 
> the extreme of course, 'use JSON::Class' would do)
> 
> use JSON::Class:auth;
> use JSON::Class:auth;
> use JSON::Class:auth;
> 
> All three are getting the same software, or not, when it is someone els-es 
> auth.
> 
>> What if someone else took a user name on github that matched one on CPAN or 
>> fez?
> That is the point I want to make. Keeping the auth field the same everywhere, 
> independent of ecosystem, will show that the software is the same everywhere. 
> If that someone has the same account name as someone else on cpan or fez it 
> will show a difference in the auth field.
> 
> So, I think there is a lot to ponder over
> Regards,
> Marcel
> 
>> 
>> 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
>> 
> 

Re: author specification

[Brad Gilbert]

There could be a way for one of them to only act as a middle man. Basically
have fez defer to CPAN and just host a copy of it.

On Tue, May 3, 2022, 10:59 AM Marcel Timmerman  wrote:

> Hi Brad,
>
> Auth is for more than just the author. It is for author, authority, and
> authentication.
>
> There is no password or other cryptographic way, so authentication is not
> possible. Obviously, I might miss some insight here.
>
> In the documentation I read; ":auth generally takes the form hosting:ID,
> as in github:github-user or gitlab:gitlab-user". For me, hosting is e.g.
> on GitHub or Gitlab to store the software, and ecosystems are for spreading
> the word, i.e. telling that there is a software available somewhere, and
> this somewhere is not important. That is the work for zef to find out.
>
> And the word 'generally' means that it is just an example, it is in the
> end just a string.
> Furthermore, there is no mention in the docs of any use other than naming
> it in a useful way. No remarks of needing it to login into some ecosystem
> and no word about that separator, being a column, or split it up in more
> than two fields using an other character.
>
> Searching through some distributions I find 'zef:lizmat', 'github:MARTIMM',
> 'tonyo', 'cpan:WARRINGD', 'github:ccworld1000, ccworld1...@gmail.com,
> 2291108...@qq.com', showing that there is absolutely no clear way to use
> that field. For me, it means again that the auth field must be completely
> free and the same, independent of the ecosystem in use.
>
> CPAN can't authenticate github or fez modules, and vice versa. There is a
> reason the field is only the first four letters.
>
> The word 'github' is longer.
>
> That they are seen as different modules is an intended feature, not a bug.
>
> I didn't want to say that it was a bug, sorry for the confusion.
>
> I would like to know how you would want the system to handle a module from
> me. cpan:BGILLS github:b2gills and I intend to get b2gills on fez as well.
> (CPAN doesn't allow numbers, otherwise I would have it there to.)
>
> Do you want to write several meta files with different auth fields
> depending on the ecosystem you want to send it to? The only thing you can
> do without much work is sending a project e.g. to fez and another to cpan
> but I don't see the use of spreading your projects over several ecosystems.
>
> Also for a class you wrote, JSON::Class, what should I write (I took it to
> the extreme of course, 'use JSON::Class' would do)
>
> use JSON::Class:auth;
> use JSON::Class:auth;
> use JSON::Class:auth;
>
> All three are getting the same software, or not, when it is someone els-es
> auth.
>
> What if someone else took a user name on github that matched one on CPAN
> or fez?
>
> That is the point I want to make. Keeping the auth field the same
> everywhere, independent of ecosystem, will show that the software is the
> same everywhere. If that someone has the same account name as someone else
> on cpan or fez it will show a difference in the auth field.
>
> So, I think there is a lot to ponder over
> Regards,
> Marcel
>
>
> 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
>>
>>
>

Re: author specification

[Marcel Timmerman]

Hi Brad,

Auth is for more than just the author. It is for author, authority, 
and authentication.
There is no password or other cryptographic way, so authentication is 
not possible. Obviously, I might miss some insight here.


In the documentation I read; "|:auth| generally takes the form 
|hosting:ID|, as in |github:github-user| or |gitlab:gitlab-user|". For 
me, hosting is e.g. on GitHub or Gitlab to store the software, and 
ecosystems are for spreading the word, i.e. telling that there is a 
software available somewhere, and this somewhere is not important. That 
is the work for zef to find out.


And the word 'generally' means that it is just an example, it is in the 
end just a string.
Furthermore, there is no mention in the docs of any use other than 
naming it in a useful way. No remarks of needing it to login into some 
ecosystem and no word about that separator, being a column, or split it 
up in more than two fields using an other character.


Searching through some distributions I find 'zef:lizmat', 
'github:MARTIMM', 'tonyo', 'cpan:WARRINGD', 'github:ccworld1000, 
ccworld1...@gmail.com, 2291108...@qq.com', showing that there is 
absolutely no clear way to use that field. For me, it means again that 
the auth field must be completely free and the same, independent of the 
ecosystem in use.


CPAN can't authenticate github or fez modules, and vice versa. There 
is a reason the field is only the first four letters.

The word 'github' is longer.


That they are seen as different modules is an intended feature, not a bug.

I didn't want to say that it was a bug, sorry for the confusion.

I would like to know how you would want the system to handle a module 
from me. cpan:BGILLS github:b2gills and I intend to get b2gills on fez 
as well. (CPAN doesn't allow numbers, otherwise I would have it there to.)
Do you want to write several meta files with different auth fields 
depending on the ecosystem you want to send it to? The only thing you 
can do without much work is sending a project e.g. to fez and another to 
cpan but I don't see the use of spreading your projects over several 
ecosystems.


Also for a class you wrote, JSON::Class, what should I write (I took it 
to the extreme of course, 'use JSON::Class' would do)


use JSON::Class:auth;
use JSON::Class:auth;
use JSON::Class:auth;

All three are getting the same software, or not, when it is someone 
els-es auth.


What if someone else took a user name on github that matched one on 
CPAN or fez?
That is the point I want to make. Keeping the auth field the same 
everywhere, independent of ecosystem, will show that the software is the 
same everywhere. If that someone has the same account name as someone 
else on cpan or fez it will show a difference in the auth field.


So, I think there is a lot to ponder over
Regards,
Marcel



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

Re: author specification

[Brad Gilbert]

Auth is for more than just the author. It is for author, authority, and
authentication. CPAN can't authenticate github or fez modules, and vice
versa. There is a reason the field is only the first four letters.

That they are seen as different modules is an intended feature, not a bug.

I would like to know how you would want the system to handle a module from
me. cpan:BGILLS github:b2gills and I intend to get b2gills on fez as well.
(CPAN doesn't allow numbers, otherwise I would have it there to.)

What if someone else took a user name on github that matched one on CPAN or
fez?

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
>
>

author specification

[Marcel Timmerman]

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