Realized after the fact there is a Clojars channel

Okay, my best idea to move forward with something of that sort would be that when someone pushes to Clojars and the groupId doesn't already exists, Clojars would: If groupId is a reverse domain like org.foo Check that the domain http://foo.org has TXT DNS header for http://_clojars.foo.org with value equal to org.foo. If check fails, refuse to create the group. Else if it has a groupId like github-foo Check that the github user foo has a public repo called _clojars with a readme file that contains the value github-foo. If check fails, refuse to create the group. Else proceed to create the group as current assuming other validation pass.

Similar things could be added for gitlab-foo and bitbucket-foo etc.

Now that way, going forward, I know that if I depend on a lib with a groupId that is a reverse domain or a github-foo like format, that the origin was verified and I can trust it comes from the real domain owner or the real repo owner on GitHub.

Just as a point of comparison, with maven central a human is involved in granting access to new groupids (but I have no idea what level of rigor is involved)

You can see an example of the maven central verification process here: https://issues.sonatype.org/browse/OSSRH-60335

It is similar to what is proposed above, but with human verification

Clojars came about in part as push back to the maven central verification requirements (though, at the time, I think central didn't support com.github.username groups). If we want to move towards verified groups, I think we should push folks to deploy to maven central instead of modifying Clojars to do the same thing

Releasing to central is a bit more painful, given that deploys go to a staging repo then have to be released manually. But there is mvn tooling to to that automatically, and it wouldn't be difficult to build a lein/`boot` /whatever plugin to do that (if they don't already exist)

Actually, it is fairly difficult due to gpg signing

Ah, good point

Since gpg signing isn't that useful, let's just generate a new gpg key automatically for every deploy :)

Hum, the manual process is also painful. If the above is automated, I can in 5min have a new groupId for my open source project pushed to Clojars. But with Maven Central it takes a few days of turnaround

That's definitely true.

I'm also considering the effort to build & maintain that system in Clojars

Ya that's a very fair consideration.

a) you should ideally only have 1 (or small number of) groupIDs

b) and if a, ~day turnaround is no big deal

but I do think the automated path via dns is a reasonable automated check and certainly in line with what others things do

It seems Maven established a different convention for github? And they do com.github.user where as right now in the Clojure community I think I saw recommendation for github-user. I think I like the latter better because of the possibility for github to want to own the com.github groupId for their own projects. But I can see an argument for both

I'm not familiar with the Maven convention if there is one

the latter recommendation was due to not wanting to stomp on github's own "space"

and to suggest ways to use other identities as a means of borrowing ownership: twitter-puredanger, gitlab-foo, etc

I'm just going off from that link, seems they approved the creation of groupId com.github.user once the person proved they owned the repo under that user in GitHub. But I like the identityprovider-user approach personally for the same reason that you can't think that's a github published repo

ah I see they do have an example at https://central.sonatype.org/pages/choosing-your-coordinates.html

I never saw that before

seems like there are a lot of those out there https://repo1.maven.org/maven2/io/github/

seems good to me :)