Oddbean

All the pieces still haven't been put together into a cohesive experience, but we are very close to it. I don't think people appreciate how fucking fast the world can change when all the right tools fall into place at exactly the right time.

Yeah, it's tough. Nostr dev feels like a battlefield sometimes. I created NIP-17 for this exact reason, but it didn’t gain traction. Later, I developed an on-chain commitment system that could have made things smoother, but it faced resistance, particularly from those fixated on drivechain. It’s a shame because we could have had better Bitcoin integration years ago. Eventually, NIP-17 resurfaced, and with NIP-34, we managed to keep things intact with the 'let git be git' principle. Ngit now covers about 60% of what you might need, though the audit trail isn’t formalized yet. It’s a long process, and when you know your work might get shot down, it’s hard to justify the effort. Still, I’ve got it working for myself. If you’re open to a synthetic future, bots might be the way forward—no need for UX, just an API and CLI. Bots could eventually document and wrap everything into user-friendly apps. Switching from nostr-only to Ditto, which I see as nostr 2.0, could solve many of these issues—it's scalable and allows for permissionless dev, which was the goal all along. https://gitworkshop.dev/ngit

Ditto is good because there is a decade of first class work on the UI/UX. Relays dont scale, and have never scaled. But ditto uses a hybrid architecture that has been proven and much of which stands the test of time. https://image.nostr.build/91b4d65ea09b52f83fcdaef89c40da507e13ec310bf9a865e3ff54b492dd92a1.jpg

When I originally made NIP-17 there were plans to extend it with optional things like full tamper proof audit trail. We can build this on top of ngit. Though the NIPs are not in a great state right now. We will get there!

I'd love to hear your thoughts on improvements. Here are 3 NIP-34 features that relate to taper-proof audit-trails: 1) patches are immutable by design (although the ngit cache currently does honour deletion requests). Unlike other architectural proposals eg. to use a replaceable events for a PR which would link to commits used, or an event that just references a branch on a git server which may change over time. 2) If the mantainers.yaml is used, changes to the authorised maintainers can be tracked alongside changes to the code state. 3) branch tips are now tracked in nostr events to reduce trust in git servers. so changes to branch tips could be tracked overtime although this isn't practical yet as a replaceable event is used and there is currently no method to retrieve old replaceable events from relays.