Webview is more vulnerable for side-scripting attacks and such than other techniques for sure and I'm not against optimizing for security. I'm not really against having a native client either, quite the opposite. I just don't think there are that many native linux clients out there and this approach isn't too bad. It does give me well performing local client.

add logout / reconnect

just more complexity for no reason

the amount of times hash functions are called in these things is far less than requires serious optimization

just stick to one hash

and just stick to one network transport and encoding for as long as possible, and let someone else manage that shit

i think the thing is that whether the hash is segmented or not is irrelevant at the network layer

I've looked into the IPFS multi-hash docs before and it looks cool but I'm not sure what problem they solve. I don't know whats the use of using multiple hashing algorithms when all you want is a single universal ID for a file.

I still need to learn more though 😀

I think we would have problems when committing large files in nostr events. Probably there are relays that limit the size of events. And this is the kind of error that doesn't surface for weeks when a project is started.

blossom is mostly just a spec for serving files by their sha256 form a fixed endpoint, there isn't anything about how files could be shared between servers.

so in theory it could be compatible with those protocols. but the server would have to implement webtorrent itself

unfortunately webtorrent uses a different hash than blossom. so the identifier for the file wouldn't be the same across the protocols

Nice work. I really like the idea of song - lightweight git server without PRs and Issues to support nip34 repos. The matching aesthetic of a minimalist UI is great.

Using nostr events as authorisation for updates is really good. AUTH events aren't shared beyond the user and relay. This doesn't allow other contributors to confirm the new commits came from that npub. What if the repo event included a references to the latest branch tip and this was used as aruhoriastion instead?

That way git pull could also validate the commit was approved by the npub.

True, that settles it then.

I'm not using AUTH, it's a normal ephemeral event sent over HTTP that the git-server immediately discards, but I like your idea more. We need a spec for that.

I like the remote helper for naddr1 codes, but can you replace the :// with : for consistency? Or maybe just do the naked naddr1 directly.

The git-remote-helper that takes stuff from Blossom could work (I don't think it is worth doing, but that's another matter), but it is somewhat out of the scope of NIP-34: it's just a new way of hosting git repos. We could add it there too if it turns out to be good.

You are right in that ngit currently looks for the maintainers.yaml every time to identify the maintainers. What I mean is that it doesn't need to. Ideally when a user first uses ngit on a repository (either by cloning the repo using ngit, a feature not yet built, or throug `ngit list`) they should choose a pubkey:identifer to trust.

like this:

```

identifier:

gitworkshop

maintainers:

- nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr

relays:

- wss://relay.damus.io

- wss://nos.lol

- wss://relay.nostr.band

```

maintainers.yaml is not in the nip34 spec. If we sort out the clone UX, I think the file is only really useful for a minority of repositories.