Lez (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!
DanConwayDev
npub15q…cyejr
2024-06-11 10:35:53
Author Public Key
npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejrPublished at
2024-06-11 10:35:53Event JSON
{
"id": "e0f9f35843407a236eaf9816d395024688eeb1e0ca948cbcecb08dd5b2e7a3a9",
"pubkey": "a008def15796fba9a0d6fab04e8fd57089285d9fd505da5a83fe8aad57a3564d",
"created_at": 1718102153,
"kind": 1,
"tags": [
[
"p",
"cfd7df62799a22e384a4ab5da8c4026c875b119d0f47c2716b20cdac9cc1f1a6",
"",
"mention"
]
],
"content": "nostr:npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cume, your git blossom remote helper POC looks super interesting. I appreciate you building it.\n\nIn the context of nip34 its welcome alternative to using a git server with a different trade-off balance:\n1. blossom - nostr native, quick to get started, easy to grok and understand decentralisation benefits\n2. git server - robust, efficient, battle tested and highly scalable\n\nI'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.\n\nI like the idea of paying for a reliable blossom service but it add getting started friction.\n\nThe 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.\n\nI wasn't able to take it for a spin as it failed to execute (see github issue).\n\nI 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` \n\nI look forward to seeing where this goes!",
"sig": "77b3b2cb1d48bfd9907149e6f7c898323f14775c960cd87ca8d938719abf30caa66e5132fe57c5f43129d90f712a8b0ddc93a32b6430b89fb06fb10ab4e1956a"
}