I've been thinking about this for a bit. I don't think it would be too difficult/onerous to move to a safer model. I hope to have time to write up a proposal for discussion this weekend.

The key part is the validation right?

I suppose some easy validations for Clojars without impeding users too much would be GH OAuth, etc.

The sonatype process is a little onerous, requiring the creation of jira tickets (and we know how much clojurists hate jira) so I think clojars could automate that.

Well, I didn't have a chance to write up my thoughts, but they are, roughly: This is indeed a validation problem - we want to validate group names. • org.clojars.<clojars-username> groups - we don't have to do anything here, since we are already validating these • com.github.<github-username> groups - validating these would be straightforward since we already have "Log in with GitHub". We would just need to add some logic there, then deny deploys to those groups until someone that is group owner (or the group creator, if a push will create the group) logs in via GitHub with that username • other reverse-hostname groups - We could validate these automatically with a TXT record. I think initially I would prefer doing so manually with folks filing GH issues, since that would let us see what validation methods work for folks, and wouldn't require as much upfront implementation (so could be released sooner - my availability to work on Clojars is essentially a small amount of time on the weekends ATM) • That leaves non-reverse-hostname groups - these are (generally) less likely to shadow internal artifacts, especially when the group and artifact name are the same (`cheshire/cheshire` , hiccup/hiccup, etc). These require a bit of thought on how to validate. We could: ◦ Allow deployment to continue to existing ones, but don't allow new ones to be created, pushing folks to use reverse-hostname groups ◦ Allow them to be created unvalidated. This isn't a great option, since it would still allow potential shadowing, and would push more folks to using these types of groups since reverse-hostname groups now require validation, and it would be good for us to go the other way as a community. An open question is do we disallow all deploys to an unvalidated group? Or just forbid creation of new artifacts until validation? Or just disallow new group creation until validation? Another easier (implementation-wise) but more painful (for the community) option is to make clojars read-only, and have folks switch to deploying to OSSRH. That would require lots more work from library maintainers, and would change the names of almost everything, so probably isn't a great option. But it would move us to a more vetted/trusted model, and would take some of the burden of maintaining our own package system off of me/the community. That's my $0.02 currently. I would love feedback on this from anyone interested. I can take the discussion here and move it to: https://github.com/clojars/clojars-web/discussions later cc: @U051KLSJF

personally, I'd like to add friction/resistance to adding new foo/foo names and do whatever we can to encourage either hostname (or copyright/trademark "ownership") or conferred identity via hosts like github

I agree

I do not think we need or want to push people to OSSRH, it really is significantly more onerous due to several rules

not just signing, but silly things for clojurians like source/javadocs

I agree there as well, but wanted to present it because it is an option

I appreciate your work on this...

My pleasure!