Subnostr

git over nostr scenario: a contributor wants a repository to use nostr instead of github but they are not a maintainer. what should they do? nostr:npub16r0tl8a39hhcrapa03559xahsjqj4s0y6t2n5gpdk64v06jtgekqdkz5pl nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk

for the nips repository nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl and nostr:npub1896p07z8xngpct5ma00mdrad4gqfnwfwdqcl706wrm25ajynahhs27x5ge's instincts were to create a repo event for it and nostr:npub1896p07z8xngpct5ma00mdrad4gqfnwfwdqcl706wrm25ajynahhs27x5ge did so.

nostr:naddr1qqzxu6tswvqs6amnwvaz7tmwdaejumr0dspzqwt5zluywdxsrshfh67lk686m2sqnxuju6p3lul5u8k4fmyf8m00qvzqqqrhny64slsj

weeks went by and then nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl sent a patch to it. none of the nips repo maintainers as defined by github were automatically tagged in it.

nostr:npub1896p07z8xngpct5ma00mdrad4gqfnwfwdqcl706wrm25ajynahhs27x5ge realised he was listed as the only maintainer and is asking what he can do about that.

how can we make this work better? #ngit #gitworkshop

DanConwayDev 1y ago

sending patches via nostr to maintainers who havn't created a repo event sounds reasonable.

creating a repo event for a repository that you do not claim to be a maintainer of is problematic.

publishing a repo event is an indication that you want to recieve patches and issues via nostr.

a repo event's reputation is built up when npubs with a good WoT score tag it in patches, issues and replies.

a scammer / spammer could create events for loads of repositories just to create confusion and make it difficult to know which reposistories are actually interested in receiving patches / issues via nostr.

Reply to this note

Please Login to reply.

Discussion

purple.co 1y ago

Maintainer is about ngit, contributors is for git, right ? In this case maintainer is about metadata, and ngit.

purple.co 1y ago

maybe maintainers must approve if they want to be part of this, and naddr can have a owner/creator.

DanConwayDev 1y ago

an naddr can only refer to a single npub:identifier.

nothing can stop someone from tagging any npub:identifier but the npub doesn't have to create an event at that address

DanConwayDev 1y ago

I understood the terms as follows:

* contributor: an individual who takes action to shape the the repository / project. in nostr-of-git-world this translates to sending patches, issues, or comments / replies to a repository.

* maintainer: an individual who has the rights to push commits to master branch of repository available via the git servers listed in the 'clone' field of the event.

clearly this isn't a shared ontology 🤣

Laeserin 1y ago

Trying to formally link maintainers to the settings in a remote gitserver instance works against the distributed patch pattern. That's the cathedral single-point-of-truth pattern.

A commit is just a commit. Any commit that is published can be pulled by anyone who can see/access it.

Maybe the maintainers don't like it, but other people do? They should be able to see it, discuss it, and pull it, regardless.

This.

sommerfeld 1y ago

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.

Laeserin 1y ago

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.

DanConwayDev 1y ago

ngit needs updating so that the user needs to choose

Laeserin 1y ago

Ah, right, using WoT to create a sorted list where they can select a clone.

Can they select multliple entries?

DanConwayDev 1y ago

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.

DanConwayDev 1y ago

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?

sommerfeld 1y ago

Yes, thats how I implemented it. I then add the other clone urls as alternative remotes names ngit0, ngit1, etc

sommerfeld 1y ago

*named

Laeserin 1y ago

As far as I know, maintainers are just the people automatically tagged in every ngit event.

Laeserin 1y ago

It's actually first-past-the-post because ngit commands sent to any repo event with the same initial commit would show up here.

DanConwayDev 1y ago

currently gitworkshop.dev uses the npub:identifer with the most number of events tagging it.

ngit users the most recent event where the 'earliest unique commit' matches the initial commit, filtered by npubs listed in 'maintainers.yaml' if that exists, or falls back to prompting the user for an naddr.

The intention is to improve gitworkshop.dev so it makes less automatic choices and factors in WoT to recommendations.

The intention for ngit is to use 'maintainers.yaml' and fallback to the same approach used by gitworkshop.dev.

Both are metrics that can be gamed easily

DanConwayDev 1y ago

inclusion in a maintainers.yaml file is hard to game. a would-be maintainer could change the clone url and send users to another git server with a different maintainers.yaml file but they won't be able to get other contributors to sign commits on top of history.

I'm not sure I agree that WoT can be easily gamed but there are certainly some valid critiques. can we really use the contact lists as a sign of trust? Conversations about use of validity of using WoT are happening elsewhere.

Ultimately, the user should be presented with a choice and the choice of npub:identifer should be respected until change their mind. I am currently refactoring gitworkshop.dev to use a specific npub:identifier repository reference rather than a dynamic one based solely on identifier.

Laeserin 1y ago

I can read that, but it's like

DanConwayDev 1y ago

my description definitely read like that pin-board

Laeserin 1y ago

😂

Laeserin 1y ago

Maybe this is a dumb question: but why are the relays in the maintainers.yaml file, rather than in a setup.yaml file or something?

DanConwayDev 1y ago

Because a list of maintainers is all that needs to br in there. A list of relays is helpful but repo events shpuld be blasted like nip65 events. Maybe git.nostr.yaml would have been better?

Laeserin 1y ago

I was just curious. That's okay.

Laeserin 1y ago

"publishing a repo event is an indication that you want to recieve patches and issues via nostr."

Yes, and this isn't going to be something only the original repo owners want to do. A group of developers can agree to work together right past the original repo, as if they had a fork in GitHub. Totally legit.

DanConwayDev 1y ago

I agree. there are 2 totally legit and important use case here:

1. they want to maintain an alternative authoritative codebase commit tip (traditional fork)

2. they want to discuss and share patches without repo owners involvement or without the desire to share an agreed upon code fork

how do we enable this without enabling a npub to create a repository masquerading as a popular other repository? we haven't had anything like that yet but it is somewhat enviable.

maybe encouraging making it clear in the name / description and a reporting mechanism like nip56?

Laeserin 1y ago

Yeah, I think reporting and WoT is enough.

sommerfeld 1y ago

Isn't the fake repo event issue similar to spoofing NIP05 for domains you don't own?

Sure, anyone can pretend to have elon@x.com nip05, but there is an easy way to verify it.

Sure WoT all things, but clients should also be able to easily verify that the repo holds the maintainers.yml ?

purple.co 1y ago

good idea !

purple.co 1y ago

if ngit is liked to remote git repo, it can verify maintainers.yaml ( yml ? ), but depends on how "client " is implemented. how about local repo ?

Laeserin 1y ago

Ngit is just local. Has no effect on the remotes listed as clones. Someone has to git push to those.

sommerfeld 1y ago

But if you push a maintainers file with your npub in it, nip34 clients can verify that the repo event author has write permissions.

So in a way, you can "signal" linkage

Laeserin 1y ago

What about the npub profile in GitWorkshop? Does that go by maintainer file or by who signed the ngit init event?

What if five people are maintainers and only one signed the init?

Laeserin 1y ago

How can you "verify" a repo init?

DanConwayDev 1y ago

what would you like to verify about the repo init?

Laeserin 1y ago

See my last reply.

DanConwayDev 1y ago

it would be nice if ngit and gitworkshop displayed npubs listed as maintainers differently when they dont have a matching repo event. is that what you are getting at?

Laeserin 1y ago

That would be a start, yes. Then you could least have one verified.

DanConwayDev 1y ago

gitworkshop.dev goes by who signed the repo event (I think or maybe if someone is tagged as a maintainer it also shows - if this is the case it should be clearly marked and currently isn't)

Laeserin 1y ago

Maybe npubs should be able to "verify" a maintainer tag and have it added to their profile. Then you'd have an event that could be queried.

Laeserin 1y ago

Like, I'm about to add nostr:nprofile1qyg8wumn8ghj7mn0wd68ytnddakj7qgkwaehxw309anhyet9deek7atv9eehqctrv5hszxnhwden5te0dehhxarj9e6xsetnv9kk2cmpwshxjme0qqs8qy3p9qnnhhq847d7wujl5hztcr7pg6rxhmpc63pkphztcmxp3wgkaukss and nostr:nprofile1qy28wumn8ghj7un9d3shjctzd3jjummjvuhszythwden5te0dehhxarj9emkjmn99uq3xamnwvaz7tmsw4e8qmr9wpskwtn9wvhszxrhwden5te0ve5kcar9wghxummnw3ezuamfdejj7qgmwaehxw309a6xsetxdaex2um59ehx7um5wgcjucm0d5hsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsqgxwr0u6myskfhez0072k2qnry7xp66qy8f4ha9mh3h6ynzkp58nay7de7kn as maintainers to GitCitadel. Can they then somehow sign/verify that and have the repo event show up in their profile under Repositories?

And could they later revoke that, if they want to leave a project?

Like, can we establish a nostr-link between an npub and a maintainer tag?

DanConwayDev 1y ago

they should sign a repo event with the same information in. if they do `ngit init` it should prompt they for each parameter but default to whats listed in maintainers.yaml and your existing repo event.

if you are all listed in maintainers.yaml, ngit will use whichever event has the largest created_at date and tag all of your repo events in any patches.

Laeserin 1y ago

Ah, okay. I didn't realize we could have parallel events. We'll have to try that out.

DanConwayDev 1y ago

gitworkshop doesn't query the maintainers file. Its actually a little problematic for a web client to access specific files within a git repository from a git server.

sommerfeld 1y ago

Most git servers expose the file tree through their webserver. Can't we hack around and use this as a best effort to verify?

DanConwayDev 1y ago

*yes. although I'm not sure how valuable the information is. it would only tell you that the maintainers.yaml file includes the npub that signed the event. how would the user know whether to trust the git repo hosted at that url?

*many git server implementations expose the raw files at specific commits / branches over https. the exact url differs between implementations. gitworkshop.dev uses it it to get the readme. FYI, if `git archive` was turned on by default by git servers we could use that. otherwise,to use the git protocol you need to shallow clone the repo. I considered doing this, but this is quite expensive for a stateless proxy.

sommerfeld 1y ago

Why not show both as different things (in case they are different)? A git commit can also have an author and a committer

Laeserin 1y ago

Yeah ngit repos have an event author and maintainers. Authors don't even have to be maintainers, do they?

DanConwayDev 1y ago

Currently they do.

nostr:nevent1qqsvxa4kmzjrpkyfrks4eqxcy4w8y8dl72xprme039rnwqtl5rh72ugppemhxue69uhkummn9ekx7mp0qgs2qzx779ted7af5rt04vzw3l2hpzfgtk0a2pw6t2plaz4d2734vngrqsqqqqqp9s5xeh

Laeserin 1y ago

Oh, that sucks.