pull down to refresh

Decentralized github - requirements
5166 sats \ 25 comments \ @phaedrus 4 Mar 2023 bitcoin
Agree with fiatjaf's comment to Jack's bounty: we don't need just github running on nostr, this opportunity is bigger...
If there was a protocol for development (maybe on top of nostr, or maybe nostr is already enough), connecting focused independent apps (rather than monolit platfoms and IDEs), i think it could enable competition and faster innovation.
What do we need in order to develop software?
Here are some ideas just to get started. 1k sats for each unique answer with reasonable idea.
  • browsing and understanding the code: navigate through code, ask questions about the code, maybe run, review the architecture, APIs (ie to audit the code, or to implement new feature)
  • make changes: propose changes, discuss and get feedback, code reviews, run tests, lint
  • integrate and release: merge branches, test, release, etc
  • report issues, ask questions, propose features
What else?
write
preview
related posts
3341 sats \ 0 replies \ @k00b 4 Mar 2023
  • discovery, ie finding the best something given a set of requirements
  • reputation, ie are they good?
  • availability, ie can i rely on this being here when I need it
maybe:
  • consistency, ie is this the current version
reply
1494 sats \ 0 replies \ @kdnolan 4 Mar 2023
A GitHub pages equivalent on via NOSTR/node based would be sick..
reply
1664 sats \ 0 replies \ @mo 4 Mar 2023 freebie
also consider:
  • Wiki: documenting the know-how deserve a place too
  • Deployment: ie. GitPages or Vercel will be a great thing to have
reply
1802 sats \ 1 reply \ @037447d9ca 5 Mar 2023
Git is already decentralized, and has commit signatures built-in. Some work has been done to decentralize storage and access control (namely Pando and GitGuild) ActivityPub is also integrating forges into the protocol so users on any instance can comment, open issues or send PRs to any other. I don't see how Nostr can add much to the mix, but in any case there's lessons to be learned from those past experiments.
reply
0 sats \ 0 replies \ @phaedrus OP 5 Mar 2023
I think nostr could connect all the pieces, like broadcast new PRs etc, because ideally each of the functionality can be separate project with competitors and fast/independent innovation... People paying over Lightning to pick which one should get more funding and development
reply
1357 sats \ 7 replies \ @sea_monster 5 Mar 2023
It's worth noting that Git is already a distributed version control system, so when you use it, you can have your own copy of the repository. For example, the development of the Linux Kernel has been happening for decades in a similar way, even before the introduction of Git itself.
However, if you're looking for additional features such as tickets and a wiki, you might want to explore Fossil SCM, which was developed by the author of SQLite. This system combines source code management with these additional functionalities.
However, implementing this would require some form of distributed storage, or some incentive for people to act as hosts or relayers. Check out the Fossil SCM website here for more information:
https://www.fossil-scm.org/home/doc/trunk/www/index.wiki.
reply
697 sats \ 3 replies \ @zuspotirko 5 Mar 2023
People mention this every single time. Git can be used p2p decentralized. And downloading could be done decentralized via torrent.
This is all true. We can do all this decentralized. But the fact is that the people out there download from centralized Github and even often update automatically . So the question how we solve this weak link still remains.
reply
0 sats \ 2 replies \ @phaedrus OP 5 Mar 2023
Can elaborate? You saying that releasing and more importantly finding/verifying/downloading the new releases is tricky, in decentralized manner, right?
reply
1107 sats \ 1 reply \ @zuspotirko 5 Mar 2023
I'm saying that it is right now possible with existing software to develop code decentrally with git and distribute it decentrally with torrent. It's all possible right now. But very few people do it. And things like what you suggested came up multiple times in the last years in the community. And every time people are dismissive because it's already possible. But that does not change the fact that few people do so.
reply
321 sats \ 0 replies \ @phaedrus OP 6 Mar 2023
Got it. Very good point. Its already possible, but people don't care (don't use it).
Any thoughts on why? Is it bad idea? Or is it too complicated right now?
I believe the reason for this could be either a/ censorship resistance (very rarely needed), or b/ faster innovation (like what's happening in nostr client apps right now because the cost of switching is so low), or both.
reply
10 sats \ 1 reply \ @phaedrus OP 5 Mar 2023
Thanks for fossil link!
reply
350 sats \ 0 replies \ @sea_monster 6 Mar 2023
You're welcome. SQLite and Fossil are pretty nice softwares. I will use it more for my own personal projects from now on.
reply
0 sats \ 0 replies \ @phaedrus OP 5 Mar 2023
Yep. Got doesn't need to be reimplemented.
reply
2792 sats \ 0 replies \ @om 4 Mar 2023
  • access control: that guy can only edit the Spanish translation and can't release
  • identity bridge: here's that guy's GitHub ID
  • name service or some other way to tell whether alice/project-name or bob/project-name is more legitimate (stars are not that way as they can trivially obtained in any quantities)
reply
1957 sats \ 0 replies \ @Chep 5 Mar 2023
Enabling developers to work together on the same codebase, communicate in real-time, and share their progress and feedback with each other. The ability to track changes to the codebase over time, and easily revert to previous versions if needed. Clear and concise documentation that explains how the code works, how to use it, and how to contribute to it.
reply
1504 sats \ 1 reply \ @deleted231216 5 Mar 2023
I wonder if it would be possible to build on the existing Gitea code (so there is no need to start from scratch).
Nostr provides the benefits of aggregation (easily fetch data from many relays, more extensible than RSS) and single sign-on (use one account for unlimited Git instances).
Gitea saves the code, commits, accounts, wikis, etc. onto the server (=instance). A Nostr version would do the same (as it's federated, not P2P), but instead of accounts, it would use pubkeys. For censorship resistance, users should mirror their code to multiple relays, instead of relying on one relay (=instance). Maybe a sync plugin could be added. There is already a Github <-> Gitea sync feature, and a relay <-> relay sync feature would be simple.
The main difference would be an API, which is accessed via custom events and calls the corresponding Git functions. E.g. a "commit" event which takes the repo ID, file upload, pubkey and signature. When the relay receives the event, it calls the postCommit(repo, files, pubkey, signature) function.
It looks like Gitea devs are already discussing federation: https://github.com/go-gitea/gitea/issues/1612 https://github.com/go-gitea/gitea/issues/14186 https://github.com/go-gitea/gitea/issues/22529
reply
0 sats \ 0 replies \ @phaedrus OP 5 Mar 2023
Very interesting!
reply
1298 sats \ 0 replies \ @Coinosphere 5 Mar 2023
Anything to make the install process for each repo go smoothly for users. (Not devs, but the users browsing the repos) Could dependencies be forcably checked at submission and -dare I say it- the latest approved repo be automatically compiled for major OSs?
reply
568 sats \ 0 replies \ @zuspotirko 4 Mar 2023
Github on Nostr would be a huge bootstrapping moment.
Bootstrapping in compilers is the moment a programming language compiles a compiler for itself.
Bootstrapping in robotics is the moment when a robot will for the first time be able to build and repair another robot from scratch.
Bootstrapping in Nostr will be when Nostr gets developed with a Gihub running on Nostr.
reply
460 sats \ 3 replies \ @random_ 4 Mar 2023
A project owner could commit the hash of the current version of their project to a taproot utxo.
Proposed changes can be endorsed by the project owner by updating the utxo.
Broadcasting the utxo could be seen as an official 'release'. Then use nostr to get the project from someone with a copy.
reply
0 sats \ 2 replies \ @phaedrus OP 4 Mar 2023
Interesting. What problem would this solve? For instance, how is this better than just the owner broadcasting new version signed with his key (just like any nostr message)
reply
200 sats \ 1 reply \ @random_ 4 Mar 2023
Off the top of my head, projects with multiple code owners.
Are there multisig nostr keys?
reply
10 sats \ 0 replies \ @phaedrus OP 5 Mar 2023
I'm not sure, but I think it should be possibly to do a multisig, just like with btc transaction. Anyone can verify that k out of n keys signed.
reply
100 sats \ 0 replies \ @Busybe3z 5 Mar 2023
Thanks for the post
reply
0 sats \ 0 replies \ @satyagraha 6 Mar 2023
Not sure I saw anything "just" about Jack's bounty
I wonder how long your list of features is to grow before it looks just like Github, akin to the way NOSTR is looking more and more like Twitter.
The opportunity for NOSTR is much larger than Github, and Twitter.
It is after all, at core, a signed packet. And packets can do anything.
All kinds of things https://t.me/lnurl/34994
reply