The intention is to enable multiple git servers which all act as mirrors behind an authorative state issued through nostr events. IPFS could act as a got server in this scenario if the git-remote-helper works. That project looks a little stale.

By the way, I had some face-to-face conversations with quite a few bitcoin core contributors last week about git over nostr.

They seemed overwhelmingly positive and very aware of the need.

They were very clear that merge commits and maintaining commit ids are an important part of their workflow so the effort I made to enable that through nip34 doesn't seem wasted.

Ideas they came up with to move things forward were:

1) using git over nostr on a sub project such as c-make (probably not this project but maybe something similar). Work is done within a forked repository and changes are periodically pushed to a open PR. The fork could use git over nostr without effecting the rest of bitcoin core.

2) a 2 way bridge to enable contributors to opt-in to using the tools whilst still participating with those on github.

Its probably a much better UX to enable browsing of directories, files and commits / branches and states at different commit histories. In which case you would need to do some sort of a clone anyway.

its definitely worth supporting for git servers designed to work with nostr. Its just widespread support is probably unlikely. Its a little but uncertain the extent to which repositories that use nostr will use free-to-host git servers (ie remain on github) vs using bespoke solutions like song or ghole.

I did some tests with native git options if `git archive`. Its probably then worth having a stateful proxy service that serves from a cache of repositories.

```

git clone --no-checkout --filter=tree:0 https://github.com/bitcoin/bitcoin

cd bitcoin

git restore --staged README.md

git checkout README.md

```

3 calls - 28.44mb + 88kb + 1.57kb

```

git clone --no-checkout --filter=blob:none https://github.com/bitcoin/bitcoin

cd bitcoin

git restore --staged README.md

git checkout README.md

```

2 calls - 55.46mb + 1.57kb

```

git clone --no-checkout

cd bitcoin

git restore --staged README.md

git checkout README.md

```

1 calls - 247.66mb

I'm not sure `git archive` is a workable solution because daemon.uploadarch needs to be set to true and it is false by default.

that means its turned off on the git server end

Yeah it leave a bad taste in my mouth too. I'm not sure its a good idea to have a better experience for people who are using github as the git server. Its contrary to the philosophy of the project. Maybe I should just pull the feature until it can be supported no matter the git server.

why is git clone inefficent? to display a readme we need to download potentially thousands of commits and (I think) all the files present in the tip of the master branch. with `git archive --remote ` we just download a tar compressed readme.

I think I need to be slapped in the face. I added support for displaying the readme but only for github right now. I planned to use `git archive` but wasm-git and isomorphicgit don't support it. any form of `git clone` is too bandwidth inefficient. I'm not sure its worth prioritising adding another backend proxy (other than though sveltekit) to use the standard git client to achieve this at this point. The other option is identifying the git server software used and targeting the readme's 'raw' url like I'm doing with github.

Yes. I guess it still is the bad sort of bureaucracy as every change doesn't need to be peer reviewed in this sort of project.

This is a great example of what the nip34 spec was not really designed for. The patch not intended to be read and reviewed by a human but it represents a build / dev environment state. Nostr events are not well suited to large diffs like this. Perhaps pulling this from a git server would be a better.

I have proposed some changes to resync.

https://gitworkshop.dev/repo/nostr-profile-manager/proposal/85dcea65ab18772dab342532015edfa91a3a3586c462f641f5758ecf4f0df845

nostr:nevent1qvzqqqqx2ypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyzzae6n94vv8wtdtxsjnyq27m7535w34smzx9ajp746can60phuy2flrnph

You had access but branch protection was on, forcing everything to go through a PR. I turned that off now. There seems to be a few linting issues and test failures on your master branch.

We should probably start from your tip, as that's whats in production.

In 1851, the NY yacht club challenged the British to a race around the Isle of Wight. They sent 1 boat and we had 11. When the American boat won Queen Victoria, who was in attendance, asked the commodore of the Royal Yacht Squadron "did we come second?". He responded "there is no second marm"

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 I'm not convinced the changes on the master branch are being deployed to metadata.nostr.com. In your capacity of CEO of nostr can you check please?

This happened because it was trying to send the event to the old set of relays (the pubkey) plus some fallback relays that are no longer active. I have made a 2 changes to address this:

1) It backs up the new event first (with the relays you want to restore) and send updates these relays instead of the ones you wanted to replace

2) I have replaced the fallback relays with relay.nostr.band, nos.lol and relay.damus.io which I think are accepting events from any pubkeys. events also get sent to blaster.mutinywallet.com as they are profile related.

Why don't you restore a backup?

I replicated your profile but couldn't recreate your issue. I could still manage relays without a problem. There wasn't a raw hex pubkey in the profile, but from the screenshot, it looks like you had already deleted it before reporting a problem.

I'll recreate your relay list tomorrow and try and make the tool resilant to that particular flavour of brokenness

Were you using metdata.nostr.com to update your relays, or other clients too?

Yes. I can take a look tomorrow. What appears to be the problem? Have you been adding hexpubkeys to your relay list? Which client did that?