DanConwayDev on Nostr: LezKoma, your git blossom remote helper POC looks super interesting. I appreciate you ...
LezKoma (npub1elt…cume), 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!
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!