The repo is still centrally hosted.
Make-believe decentralization.
Discussion
One step at a time
First steps, actual footage.
Why? I can just move the repo later to a new place? That doesn't affect issues and pull requests at all.
You can move it all you like, but it'll always be in one place only.
A repo + issues + PRs from a complex data structure the decentralizion of which hasn't really been solved yet.
Nostr's decentralization is easy because of a simple flat set of notes. Even then, a thread of notes already constitutes only a moderately more complex structure and you can immediately see it failing when some notes in the thread are missing.
IPFS is trying something there with the IPLD git adapter but the DHT is already weak so I'm not optimistic. Submitting issues/PRs via nostr suggest and existing or pending full git decentralization that we desperately need but doesn't exist and won't come anytime soon.
Sure, projects are centralized. There is no way around it. People can copy or fork the code as much as they want and work in several competing hierarchical structures like the Linux Kernel does, but in the end, each team it is working on a single/centralized version. Users choose which team they prefer to use.
And your point is? Just don't do anything?
Blockchain ledgers are centralized in so far as that "there is only one" ledger but stored decentralized on many redundant nodes. I don't need to explain that to you Mr. Bitcoin.
So a team having to have "the one fork" they work on together doesn't imply centralized single point of failure storage. Of course blockchain ledgers achieve this at absurdly high bandwidth costs and simplistic consensus algorithms.
Can you take it from there and reduce bandwidth, increase consensus sophistication so that the team's one fork can live on 2 dozen servers like nostr relays and yet be synced well enough to appear as one.
Not an easy task I know but it's the only way forward.
I have no idea what you want to say or where you want to get with this.
Each team member has a full fork of the project and the fork is generally in sync with the version everyone is working on. It's equivalent to your blockchain analogy.
Adding a blockchain will only make things more centralized because everybody must be bound to the chain. It doesn't make any sense.
Can't the latest version be recreated by a going through past Pr and issue bearing Notes ? Combine with a fork of the "centralized" github repo to other self hosted solutions .
This seems like a valid de-centralization and redundancy step for sure.
We can have the entire Git repo as Nostr Events. The hard part is to keep a single head for all files given that Nostr doesnt have a timechain. But we will figure it out.
Btc timestamp right ?
yep
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`.
Timestamp based Single use seals is what i was thinking. Linked to ones npub. Can be revoked, updated, passed on, as maintainers come and go.
Oops. Missed the "show more" and did not read the full note.
From the link: "Forks are replaced by permissioned branches."
Replaces the whole "key holder" issue. If i understand correctly. Neat.
So as a project moves through its life cycle, a baton of sorts is passed on to the next endorsed npub or the most popular branch. This eliminates a bunch of friction. Organic. Neat.
User expectations/behavior will have to change. Particularly around malicious fake accounts and noobs.
"Large patches and binaries would need to be transported separately and referenced in a stub patch event."
Which is where the convenience of Github comes in. Potential security issues too.
Forward looking though its also an oportunity for V4V storage.
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.
I agree. But using Nostr with Git is not supposed to be efficient. Just decentralized. Nostr itself is not efficient to begin with.
nostr:nprofile1qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszrnhwden5te0dehhxtnvdakz7qpqahaz04ya9tehace3uy39hdhdryfvdkve9qdndkqp3tvehs6h8s5sl8p9ks is innovating on and around this and I'm really looking forward to seeing what he comes up with gnostr.
I’ve already created a “timechain” of #nostr events…
https://x.com/randymcmillan/status/1764056522965831753?s=46
#gnostr
Getting ready to create “blob signatures” - this way even thru a rebase or whatever - the origin of the blob can be verified… 
also nostr:nprofile1qyv8wumn8ghj7un9d3shjtnrw4e8yetwwshxv7tf9uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qqs9njktmqadt322myw6eag6f8qxuzl0wv9vpe7zxkn0d73fhy3s7qsaq9shr and nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq3gamnwvaz7tmjv4kxz7tpvfkx2tn0wfnj7qpqu9e887ad8pl49cxgzqkuljxcxy89dtac7jkyuajnukxg6hu2hufqmxzy8a are innovating with an approach using mercke DAGs in GitNestr. I'm excited to see that as well.
It’s become so much more. 🤟 Merkle DAGs were just one piece of the puzzle. 🧩
Never say never :-)
I’ve already created a “timechain” of #gnostr git commits…
#nostr
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
I hope you guys get the bounty ! Perhaps after some more refinement to meet the terms ?
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.
The repo can be Radicle...so...
Radicle's gossip protocol doesn't scale well beyond a few dozen nodes. This way work for an individual repo and team like Amethyst.
The challenge with git and code hosting isn't an individual repo though. It's the whole ecosystem of interlinked repos, because code relies on libraries which in turn rely on other libraries etc.
You need a more large scale solution for that.