@DanConwayDev my "nak git push" command (that I just made) was able to successfully push to relay.ngit.dev and gitnostr.com yesterday, but now when calling "git push" directly (nak calls it underneath) it fails with "fatal: unable to access 'https://relay.ngit.dev/npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6/nostrlib.git/': The requested URL returned error: 500".
ngit is still unable to push.
Did you abandon this issue entirely or are you cooking something? How can I help you more?
Thread
Login to reply
Replies (18)
It looks like the 500 error relates to a permissions issue on some directories within the bare repository which in have fixed for now. I'm cooking a better grasp implementation.
DanConwayDev
There seems to be a range of issues going on here. I identified a permissions issue resulting from a data migration which may have fixed the nostrlib repo on gitnostr.com and relay.ngit.dev it for now(?). I'm building a better grasp implementation contained within a single binary which should be easier to debug.
View quoted note →
I don't know why it was effecting this repository and not others
I made a grasp server at wss://pyramid.fiatjaf.com. It works with my own nak git, but since my ngit doesn't work with anything anymore it also doesn't work with that either, so I don't know my server is missing something.
Can you take a look? I've added you so you should be able to push git kinds and repos.
Wait, now (I've updated ngit) it does work to push with ngit to pyramid!
was it still failing after I fixed the nostrlib repo on relay.ngit.dev and gitnostr.com (8+hrs ago) before you updated ngit? If not, I wonder whether the 500 error on one git server was causing ngit to fail on all the others?
Nice. Where is the source code? I cant find it here: 
GitWorkshop.dev
Decentralized github alternative over Nostr
It's here:
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?
GitWorkshop.dev
Decentralized github alternative over Nostr
PR events sit completely parallel with patches. I considered whether grasp servers should accept patch git data as refs/nostr/<patch-event-id> or even generate the ref when patch events are received.
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.
iām humbled, thank you
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 not reflective of the github version?
NIP34 - NIP-34 - git stuff
Read more about the NIP34 on {{appUrl}} - NIP-34 - git stuff
Good question, I was misled there I think. @npub1txuk...phrl do you know?
Weird, I removed the cache for nips 34. It's now fixed.
btw, i was able to push to
but i'm not able to clone on a different device. pls help. @DanConwayDev
git clone nostr://npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/gitnostr.com/stats
Cloning into 'stats'...
nostr: fetching...
ā wss://relay.nostr.band no new events
ā wss://nos.lol no new events
ā wss://relay.ngit.dev connection timeout
ā wss://relay.damus.io no new events
ā wss://gitnostr.com connection timeout nostr: no updates
fetching relay.ngit.dev/npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/stats.git ref list over https (unauthenticated)...
list: failed over https (unauthenticated): failed to connect to relay.ngit.dev: Operation timed out; class=Net (12)
list: relay.ngit.dev/npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/stats.git failed over https (unauthenticated)
fetching gitnostr.com/npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/stats.git ref list over https (unauthenticated)...
list: failed over https (unauthenticated): failed to connect to gitnostr.com: Operation timed out; class=Net (12)
list: gitnostr.com/npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/stats.git failed over https (unauthenticated)
fetching relay.ngit.dev/npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/stats.git over https (unauthenticated)...
fetch: failed over https (unauthenticated): failed to connect to relay.ngit.dev: Operation timed out; class=Net (12)
fetch: relay.ngit.dev/npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/stats.git failed over https (unauthenticated)
fetching gitnostr.com/npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/stats.git over https (unauthenticated)...
fetch: failed over https (unauthenticated): failed to connect to gitnostr.com: Operation timed out; class=Net (12)
fetch: gitnostr.com/npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/stats.git failed overhttps (unauthenticated)
Error: fetch: failed to fetch objects in nostr state event from:
- relay.ngit.dev/npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/stats.git failed over https (unauthenticated)
- gitnostr.com/npub16a6kfxprxgazyhc9ym6pe3dqmw4ran4uk50gu23nt0ttdecsavxs3cflrw/stats.git failed over https (unauthenticated)
GitWorkshop.dev
Decentralized github alternative over Nostr
ngit-relay Instance
A pure HTML example, without dependencies.
ngit-relay Instance
A pure HTML example, without dependencies.
ngit-relay Instance
A pure HTML example, without dependencies.
ngit-relay Instance
A pure HTML example, without dependencies.
You experienced a timeout issue. I could clone the repository without any problems. Can you try cloning again. Your repository clones fin both gitnostr.com and realy.ngit.dev timed out. I control both of these and really need to sort out some better performing infrastructure for them.
It worked after I used the https urls. This:
ngit-relay Instance
A pure HTML example, without dependencies.
Did you try the https URLs directly after the nostr one or did you come back to it a bit later?
I'm wondering whether it was a coincidence or whether the git plugin is less resilient when it comes to connectivity issues.