also nostr:nprofile1qyv8wumn8ghj7un9d3shjtnrw4e8yetwwshxv7tf9uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qqs9njktmqadt322myw6eag6f8qxuzl0wv9vpe7zxkn0d73fhy3s7qsaq9shr and nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq3gamnwvaz7tmjv4kxz7tpvfkx2tn0wfnj7qpqu9e887ad8pl49cxgzqkuljxcxy89dtac7jkyuajnukxg6hu2hufqmxzy8a are innovating with an approach using mercke DAGs in GitNestr. I'm excited to see that as well.

nostr:nprofile1qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszrnhwden5te0dehhxtnvdakz7qpqahaz04ya9tehace3uy39hdhdryfvdkve9qdndkqp3tvehs6h8s5sl8p9ks is innovating on and around this and I'm really looking forward to seeing what he comes up with gnostr.

git in itself is a state chain. every commit id is a hash of all previous changes. that way you can be certain you aren't missing any data.

I thought the hard part was identifying who the authoriative maintainers are fpr a repository if they change overtime, such as bitcoin-core. I proposed https://github.com/DanConwayDev/ngit-cli/tree/v0.0.2 which uses OpenTimestamps.

Someone then pointed out that you can embed this information right into the commit history and contributors will 'build on top of' whichever history they don't object to. Overtime the longest chain (of quality commits, by contributors we trust), will determine the authorative maintainers.

This is what ngit optionally does when you run `ngit init`.

I created a POC for an entire git repo as nostr events in May 2023. you can try it out:

https://github.com/DanConwayDev/ngit-cli/tree/v0.0.2

My conclusion was that it isn't the right approach. git is very efficient at storing and accessing the data, working out the differences between repositories and bandwidth efficiently sending the right data.

The architecture I propose for achieving this is treating git servers like relays. The nostr repository event includes a list of git servers and the commit-ids for the tips of each branch. a git remote-helper enables maintainers to push to all git server mirrors and update the repo event with the new branch tip with a simple 'git push' command. I wrote a bit more about the proposed repo event format for this here: https://github.com/nostr-protocol/nips/pull/997#discussion_r1464484832

Yes, the one tap zaps is much better UX

the centralised hosting of a git server is much less of a big deal than it first seems. It is trivial to switch from one git server to another. If a contributor is blocked from accessing a git server, they can access an mirror with identical functionality. Only a small number of repo maintainers need write access.

Decentralising the code collaboration surrounding the repository on the other hand is much more important. If a contributor is blocked from a centralized service here really stunts there ability to contribute. If a repository gets banned, it be very disruptive for the project. They have to scramble to choose an (often centralised) alternative, they may have many PRs in flight and the conversation around these may be lost.

I love how details of my lightning node never gets exposed and, whilst the mint can rug everyone, they can't selectively rug me.

I'm using minbits, which I love, but I get a delay of between 20s and 3m before the authorisation screen appears in minibits. About 40% of the time it doesn't show up at all and I've moved onto other things so the recipient never gets that zap.

What's your zapping set up?

Thanks for your words of encouragement. It means a lot.

I'm guessing we can still use the existing obtainium set up with github to get updates until further notice.

There isn't a spec for releases over nostr but imagine having the release you are installing signed by the developers via nostr? That would be an upgrade from the current obtainium trust model, wouldn't it?

Are you asking about having gitworkshop as an android app or downloading amethyst releases via obtainium?

OTS is perfect companion for bitcoib memes. Post your meme and get an infallible timestamp embedded into the very subject of your meme.

I think an ecash wallet such as minibits is a good first wallet. Then Mutiny. If you are encouraging people to DCA with small amounts and rarely spend, its pretty difficult to reccomend a lightning wallet where they will have to open a channel for each DCA.

I absolutely love this outlook at the same time as being excited about the OTS Amethest feature to which you refer.

I supose cognitive disanence is part of what makes us human.

This is awesome! What does it look like after pending?

Totally agree with this. Innovation happens at the edges. Don't be discouraged when you see other people ship things.

it's been more than a few months since I looked at this aspect but I think I found a way of lazy loading the required data without having to clone. even a depth 1 clone can be bandwidth and storage heavy for many repositories. I'll let you know how I get on.

I certainly wouldn't wasn't to discourage anyone from adding similar features to other clients. code collaboration over nostr succeeds when clients compete to provide the best UX for their target audience. different clients and different experiences will suit different user groups who may have different needs