nostr:npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cume, your git blossom remote helper POC looks super interesting. I appreciate you building it.

In the context of nip34 its welcome alternative to using a git server with a different trade-off balance:

1. blossom - nostr native, quick to get started, easy to grok and understand decentralisation benefits

2. git server - robust, efficient, battle tested and highly scalable

I'm excited to see how the blossom landscape evolves. I wonder whether free-to-host blossom providers will block this use-case either proactively or inadvertently through rate limiting.

I like the idea of paying for a reliable blossom service but it add getting started friction.

The design.rst was really helpful. I wonder how relying on transporting loose objects impacts real-world performance. I suspect for many repositories it won't be too much of an issue. using a DVM to package objects is a great idea.

I wasn't able to take it for a spin as it failed to execute (see github issue).

I wonder whether renaming it as git-remote-blossom might be more accurate? I foresee a git-remote-nostr proxying requests to remotes listed in the repo announcement `clone` tag which could include blossom://npub/identifer. This would provide the flexibility for maintainers to switch from using a git server to blossom and vice versa. from a UX point of view the user will still run `git clone nostr://npub/identifier`

I look forward to seeing where this goes!