Avatar
DanConwayDev 1y ago

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

Reply to this note

Please Login to reply.

Discussion

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

39
purple.co 1y ago

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

39
purple.co 1y ago

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

Avatar
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

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

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

Avatar
frphank 1y ago

This.

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

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

Avatar
DanConwayDev 1y ago

ngit needs updating so that the user needs to choose

Avatar
Laeserin 1y ago

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

Can they select multliple entries?

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

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

Avatar
sommerfeld 1y ago

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

Avatar
sommerfeld 1y ago

*named

Avatar
Laeserin 1y ago

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

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

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

Avatar
frphank 1y ago

Both are metrics that can be gamed easily

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

Avatar
Laeserin 1y ago

I can read that, but it's like

Avatar
DanConwayDev 1y ago

my description definitely read like that pin-board

Avatar
Laeserin 1y ago

😂

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

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

Avatar
Laeserin 1y ago

I was just curious. That's okay.

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

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

Avatar
Laeserin 1y ago

Yeah, I think reporting and WoT is enough.

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

39
purple.co 1y ago

good idea !

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

Avatar
Laeserin 1y ago

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

Avatar
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

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

Avatar
Laeserin 1y ago

How can you "verify" a repo init?

Avatar
DanConwayDev 1y ago

what would you like to verify about the repo init?

Avatar
Laeserin 1y ago

See my last reply.

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

Avatar
Laeserin 1y ago

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

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

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

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

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

Avatar
Laeserin 1y ago

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

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

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

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

Avatar
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

Avatar
Laeserin 1y ago

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

Avatar
sommerfeld 1y ago

If the original maintainers are not interested in receiving patches/issues through nostr, the solution is for that someone to create their own fork and use the fork in the "ngit init" event.

Then they can receive patches on their fork and submit Github PRs from their fork to the original repo.

I see this the same way as if the maintiner does not want to package their software for platform X, so a motivated person Y maintains their downstream fork that supports platform X. Downstream forks are very common.

Avatar
DanConwayDev 1y ago

I'm not sure how effective that would be. The costs of maintaining a fork are quite high.

Here is an idea which is lower cost and potentially friendlier to the maintainers:

what if they could create a repo event which highlights that they are not the maintainer (empowered to merge code on the repository / a repository that other people are using as an authoritative codebase)?

If those they see as maintainers are on nostr then they could add them, even if that maintainer hasn't created a repo event yet.

people who also want to see the repository use nostr could use this and accept that the number of other contributors / maintainers who see it might be lower.

to achieve this the nip34 spec would need to be tweaked so that it is not assumed that the author is a maintainer if the maintainers parameter is present.

Avatar
sommerfeld 1y ago

>The costs of maintaining a fork are quite high.

They don't have to maintain a fork, that is only 1 of the options. They can use their fork as a proxy to open PRs in github/gitlab/etc using the nostr submitted patches.

> what if they could create a repo event which highlights that they are not the maintainer

Why not just submit the repo event with an empty maintainers list? It's essentially the same thing, or not? 🤔

Avatar
DanConwayDev 1y ago

no. nip34 wording:

> `["maintainers", "", ...]`

perhaps it should be:

> `["maintainers", "", ...]` // optional: if omitted, author is sole maintainer

I think this might break a number of existing repo events.

39
purple.co 1y ago

Fun fact! This was a simple ngit init test and, after I realize that can work, I sent a FYI message to fiatjaf ( npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 / 3/15/24, 10:41 AM ). I don't know if was delivered (nip44?), but if it works why not ..... I didn't expect PRs or issues and it is clear that anything done here can't be easy integrated in github like this. We will see :) .

Avatar
Laeserin 1y ago

Having the NIP stuff controlled over GitHub PRs is an antipattern. Can't have an open protocol and then manage changes over corporate junk that doesn't even let everyone have an account and doesn't let you post without an e-mail adress.

Ngit or just go full Wiki, IMO.

nostr:nprofile1qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qyfhwumn8ghj7un9d3shjtnxxaazu6t09uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyrafsj7hmweg9ur7zmn6apajdg48hxuskujx53rhrux0ttjcqx84yz992ux

39
purple.co 1y ago

or can be radicle ( .xyz ).

Avatar
Laeserin 1y ago

What do you mean? Is that a relay?

39
purple.co 1y ago

https://radicle.xyz/

Avatar
Laeserin 1y ago

Ah, okay.

I'm waiting for GitRepublic. 😉

Avatar
sommerfeld 1y ago

radicle has a shitcoin

Avatar
Cyber Seagull 1y ago

A shitcoin was used to fund it and as a Dao governance token which is a legitimate functioning use case services like Bisq use.

The protocol does not depend on it.

39
purple.co 1y ago

try first, then we talk.

Avatar
DanConwayDev 1y ago

I'd love to see a repository which tells me which clients have implemented which version of each nip.

That way the bar for accepting a nip and or updating it nip would be a lot lower as they could be filtered by usage.

Avatar
Laeserin 1y ago

💯

Avatar
Laeserin 1y ago

I decided it doesn't matter. You're legit and you have a repo covering the initial commit I need, so I went for it. 😂

39
purple.co 1y ago

some thread we got here.

Avatar
Laeserin 1y ago

🤙