Nice. Where is the source code? I cant find it here: https://gitworkshop.dev/relay/pyramid.fiatjaf.com
It's here: https://gitworkshop.dev/fiatjaf.com/nostrlib/tree/master/khatru/grasp/server.go
But I'm still confused about the PR events and refs/nostr/ stuff and how are these related to patches.
I was thinking that would be nice to expose received patches as refs so they could be fetched by git directly, is that what that means?
PR events sit completely parallel with patches. I considered whether grasp servers should accept patch git data as refs/nostr/
For:
1. clients that choose just to implement only PRs could easily extend to add basic support for patches by treating them as PRs (root patch map to the PR event and additional patches map to PR updates but follow nip10 rather than nip22).
Against:
1. it encourages clients not to implement applying patches
2. patches not sent to a grasp server wouldn't show up in these clients. Showing some but not all is bad UX.
3. patches not accepted by the repository grasp servers wouldn't show up (there are no grasp server hints like in PR events).
4. its another thing for grasp servers to implement
It took me much longer than I anticipated to Implement PRs in ngit because its hard to get a good UX. If you cant write to the repositories grasp servers (or they don't list any) you have to write to another grasp server. This involves selecting a grasp server (which is hard to do without hardcoded defaults, although WoT based 'user grasp list' is possible but filtering based on whether they are likely to accept your data might a challenge). Then it needs to send a repo annonucement with a 'personal-fork' tag (to prevent it from appearing like you own the project) and push the entrire repo there. If its a big repo that could be 1gb push.
Once there are more (and reliable) grasp servers available and most nostr git repositories are primarily using them I think it will work much better.
Now I see what you mean when you say the blossom big patch was better (but I still think the PR flow is nicer and the blossom big patch flow would have other problems not immediately obvious).
Maybe having a personal list of grasp servers, like we have for blossom servers, would help. Then you would know what are the default grasp servers for each user to use in these situations, then you just assume they will accept your stuff.
I wonder if we could have a different kind of announcement, with an expiration tag or something like that, that would allow grasp servers to delete the associated repositories after a while and also prevent these temporary forks from being associated too much with a specific user.
We have that as a `10317` user grasp list, modelled on the blossom version was merged into NIP-34 as part of the PR event nip PR in commit 2aaba90839443dded18afb10adea5806904ea04f.
Also we have the 'personal-fork' tag in an announcement (see same commit) to differenciate these sort of announcements.
Why is https://nips.nostr.com/34 not reflective of the github version?
Good question, I was misled there I think. nostr:npub1txukm7xckhnxkwu450sm59vh2znwm45mewaps4awkef2tvsgh4vsf7phrl do you know?
Weird, I removed the cache for nips 34. It's now fixed.
i’m humbled, thank you
