I agree but one thing is what is possible, another what is the best practice.
IMO, if you don't have push permissions for the original repo, you should publish a repo event where the clone url points to your fork, not the original repo.
Discussion
I did that orginally, posting two repo events (origin and fork), but ngit actually goes by earliest unique commit, not clone. Clones are just metadata and you can have n number of clones.
ngit needs updating so that the user needs to choose
Ah, right, using WoT to create a sorted list where they can select a clone.
Can they select multliple entries?
when I wrote the logic for repo event selection I was thinking of how people would find the event of a repo they had already cloned via the git server.
I assumed that repositories would add a maintainers.yaml so it didnt go much further than that.
I think it is best if a selected set of npub:identier's are stored in the git config. Then if a change to the maintaienrs.yaml file or any of the npub:identifer's events is detected the user should be asked how they want it handled.
the intention for allow multiple clone urls was so that the data related to the same master branch tip could be accessed from multiple locations for censorship resistance reasons.
It didn't occur to me that it would be used to point to repositories with different tips.
nostr:npub16r0tl8a39hhcrapa03559xahsjqj4s0y6t2n5gpdk64v06jtgekqdkz5pl has been working on a `ngit clone` proposal, which would be effected by this.
would the first item in `clone` be the default remote?