Can you maybe integrade this as well? nostr:nevent1qqsgqftwc9fd2mmvahwyxdqju5ye004mr0jnldd655hd06l0w0a2teqpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczypzj80jc6w2mrvvk4xuvs2cr3d5ftjczk6papsjn492sdrd6r7kdqqcyqqqqqqghne2q9
Discussion
Interesting idea but I want to know more about how it works to decide if it's actually realistic/efficient? ngit (NIP-34) is purpose-designed and already deeply integrated into Shakespeare. Using Blossom servers is a novel idea that repurposes existing infra (very good) but I can't envision how it could work beyond being a neat idea/toy experiment.
Can you try it out?
nostr:note1wae4dhs2dmvqgz8rzh4umk5rk0t39ucghlvd35rua22vcnv293cq5xfesu
I just installed ngit, trying it out. Git's native sync is faster than requesting every object by its blossom content hash. On the other hand, git-remote-htree doesnt require git servers, just blossom or webrtc peers.
nostr:nprofile1qqsy2ga7trfetvd3j65m3jptqw9k39wtq2mg85xz2w542p5dhg06e5qppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z75uptz7 I considered using blossom, in fact I even wrote some code. nostr:nevent1qqsg9w72dve9myu29swk7w9wapqncndnhe98dmfrrd8cjd26fy3lsgsprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7q3q5qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exsxpqqqqr9zufx4r0 I thought the most efficent approach would be to store git packs as blossom blobs. I havent studied your code but from the documentation you are somehow using 2mb chunks? I can see how its naturaly evolved from your 'files' usecase.
Ultimately I prefer the trade-off of using a git server as its fundimantally compatible with all git usages (shallow sync, no-blob, etc) and git tooling. Grasp enable using the battle-tested, flexible and widely used git client-server model but frees it from a single server and moves the trust and authentication onto nostr. My guiding principle has been: let git be git and let nostr be nostr.
Whilst smaller project often don't require advanced git features such as shallow clones and no-blob, they are essential for my larger open source projects. My goal is to make git nostr so attractive for open source projects that they all want to use it, no matter their size or complex.
Initial clone from a git pack would be faster than fetching each object separately. But packs change hash whenever anything is added, so you'd lose the deduplication that the hashtree filesystem provides: same object in two repos would be stored twice.
In my proposal there are multiple packs relating to groups of commits in the history so the hashes don't change. Uding ^2 exponential.
Back in my day, we didn’t need fancy “packs” to clone repositories. You just fetched the objects, and that was it. These kids today think they’re so smart with their “deduplication” and “hash trees,” but they’re just complicating things. Sure, a pack might speed up the initial clone, but if adding to a pack changes the hash, then *of course* you lose deduplication. That’s not a flaw—it’s a design choice. If the pack’s contents change, the hash has to change. It’s like saying a book’s ISBN should stay the same if you add a new chapter.
Kids these days think they’re clever by layering abstractions, but they’re just creating fragility. Git’s strength was always in simplicity. If two repos have the same object, they’ll still share it at the filesystem level—*if* the filesystem supports dedupe. But if you’re using a “hashtree” system, you’re probably already paying for that with slower performance. Why not just stick to plain old objects?
This whole “pack” idea feels like a hack to me. Back in the day, we didn’t need to worry about hashes changing because we didn’t modify existing data. Now everything’s a moving target. If you want dedupe, use a real filesystem. Don’t blame Git for your poor architecture.
Join the discussion: https://townstr.com/post/6e3bb52df7ce53def0f9814c709555239985cb121a343e61f81e7291753540bd