Show HN: Gitopia: Decentralized GitHub Alternative for Open Source Collaboration
gitopia.comHey HN! We're Parth and Faza and we'd like to introduce you to Gitopia - https://gitopia.com/. Our vision with Gitopia is to create a decentralized platform for open-source code collaboration that is both resilient against censorship and promotes free exchange of ideas. To make this vision a reality, we've developed tools that foster community-led governance and incentivize active participation.
Our journey into the open-source world started with Google Summer of Code, where we contributed to syslog-ng and GDAL, respectively. It was a transformative experience that truly highlighted the value of open-source development to us.
During the pandemic, we participated in an Arweave hackathon hosted on Gitcoin. It was here that our initial project, Dgit - https://web.archive.org/web/20201029162838/https://dgit.sh/#..., took form. This sparked the idea of a decentralized code collaboration platform and set us on the path towards what we now call Gitopia - a 'utopia' for open-source collaboration.
One of our guiding principles while developing Gitopia has been to maintain familiarity for users. To achieve this, we designed Gitopia to work directly with the git CLI and incorporated Gitopia's git remote helper - https://docs.gitopia.com/git-remote-gitopia, that allows git to understand our custom transport protocol. This integration ensures that you can continue using the git commands you use daily, thereby offering a decentralized experience that doesn't disrupt your existing workflow.
Making the transition easier, we have also released a GitHub action, gitopia-mirror-action: https://github.com/marketplace/actions/gitopia-mirror-action, that mirrors your repositories from GitHub to Gitopia. Each commit is backed up on IPFS, Filecoin, and Arweave, safeguarding your code against censorship and eliminating single points of failure. A basic search feature is also enabled on Gitopia using the graph protocol.
We recognize the challenges in the open-source community around lack of incentivization. Developers often find themselves contributing their time and skills for free, leading to potential burnout. To combat this, we have implemented bounties, allowing contributors to earn rewards when their PRs get merged. We encourage you to contribute and get involved with the bounties open in various Gitopia repositories.
- gitopia-web: https://gitopia.com/Gitopia/gitopia-web/issues
- gitopia chain: https://gitopia.com/Gitopia/gitopia/issues
- git-remote-gitopia: https://gitopia.com/Gitopia/git-remote-gitopia/issues
Gitopia introduces a utility token, $LORE, which plays a crucial role in our platform. $LORE not only incentivizes open-source maintainers and contributors but also empowers the community to participate in platform governance via proposals. You can find more details about our token model here - https://blog.gitopia.com/post/2023/03/lore-token-model/
The journey towards building Gitopia is ongoing, and there are exciting features in our pipeline:
- Activity feed
- Improve search ranking
- CI/CD workflows
- DAO workflows
We're also actively working on tackling challenges in platform moderation, reducing maintainer fatigue, improving platform governance, and enhancing discovery on the platform. We invite you to try out Gitopia - https://gitopia.com and share your feedback, ideas or suggestions. Please comment here or reach out to us at hi [at] gitopia.org. We look forward to hearing from you!
Helpful links:
Documentation: https://docs.gitopia.com/ First off, I think decentralizing off of GitHub is a worthy endeavor, so kudos for working on it! That said, I do have some questions: First, why blockchain? I know it's a bit of a meme around here to be instantly critical of any blockchain project, but I genuinely am not sure what a blockchain provides here over git itself, which is already a distributed version control system. Second, why a new token? Transaction fees and maintainer donations can easily be handled with existing payment providers and (if desired) ETH/BTC. What is a new token contributing towards the goal of a decentralized GitHub? > First, why blockchain? I know it's a bit of a meme around here to be instantly critical of any blockchain project, but I genuinely am not sure what a blockchain provides here over git itself, which is already a distributed version control system. git is distributed, we use git as well and it is irreplaceable.
The hosting platform till now has been centralized and prone to censorships due to the jurisdiction it was based in for eg US sanctions.
A decentralized platform that uses a blockchain provides censorship resistance out of the box. > Second, why a new token? Transaction fees and maintainer donations can easily be handled with existing payment providers and (if desired) ETH/BTC. What is a new token contributing towards the goal of a decentralized GitHub? The payment providers need KYC or valid jurisdictions to operate under. ETH/BTC could work here(can also work on gitopia in the future). But building just on top of another network restricts us to their limitations. On the other hand having your own network enables us to change along with the requirements of the platform.
The new token contributes to the security of the platform as it is used by validators to secure the network via PoS consensus.
The token also acts as a governance mechanism in voting for governance proposals that shape the future of the platform. This won't be possible by relying on existing tokens. > git is distributed, we use git as well and it is irreplaceable. The hosting platform till now has been centralized and prone to censorships due to the jurisdiction it was based in for eg US sanctions. A decentralized platform that uses a blockchain provides censorship resistance out of the box. This is an argument in favor of decentralizing, and I'm 100% in agreement. However, you haven't really explained what the blockchain layer is providing here that couldn't be accomplished with git's native ability to be a distributed VCS. There's a lot of overhead introduced by adding a blockchain—extra development time, extra code to maintain, extra CPU work (even with PoS). In order to persuade a technical audience to use your tool, you have to explain what value all that complexity is bringing! Put another way: I can have a distributed, censorship-resistant VCS by self-hosting Forgejo and mirroring repos that I like and want to help keep online. If a tool like Foregjo could encode the issue tracker and other meta information inside the .git folder, it could even make those aspects distributed, without all the complexity inherent in a blockchain. Given that, what does blockchain bring to the table? > There's a lot of overhead introduced by adding a blockchain—extra development time, extra code to maintain, extra CPU work (even with PoS). In order to persuade a technical audience to use your tool, you have to explain what value all that complexity is bringing! Agreed that there is a lot of overhead introduced, but that is for the development of the platform and network of Gitopia. For the end user the workflows remain almost the same for collaboration. > Put another way: I can have a distributed, censorship-resistant VCS by self-hosting Forgejo and mirroring repos that I like and want to help keep online. If a tool like Foregjo could encode the issue tracker and other meta information inside the .git folder, it could even make those aspects distributed, without all the complexity inherent in a blockchain. Given that, what does blockchain bring to the table? I understand that this would work for technically inclined users but not for everyone who want to contribute to open source. Along with this the blockchain layer layer offers immutable, transparent and tamper proof versioning of code along with the collaboration meta and augments the current collaboration flow. Along with this it enables us to provide a novel means to incentivize open-source contributions along with fostering a more decentralized approach for governance (even for projects), every token holder could have a say in the decision making, reducing the risk of undue influence by a single party, hence eliminating centralized control. I will also add that we have tried to keep the flow of collaboration on Gitopia as intuitive as possible for the developer hence adding no additional complexity for the end user if they don't want it. But for some projects this might be useful or necessary to use the web3 workflows along with the collaboration features on Gitopia. > but that is for the development of the platform and network of Gitopia. For the end user the workflows remain almost the same for collaboration. I have to disagree here. Accidental complexity in a system can have severe downstream impacts on end users, whether that be in the form of poor performance, unreliability, or just slow update cycles. It's not something you can paper over and completely hide from the user. > Along with this the blockchain layer layer offers immutable, transparent and tamper proof versioning of code Tamper-proof can be accomplished natively by signing [0]. receive.denyNonFastForwards and receive.denyDeletes[1] can be used to make a git repository immutable. Git commits are also already content-addressable. And transparency is achieved by just having the repo available for people to clone. > along with the collaboration meta and augments the current collaboration flow Could this augmentation not be accomplished by storing the collaboration information in the repo under a set of special-purpose branches? Like git-bug[2] or git-issue[3]? Coupled with GPG signatures and you've got your immutability and tamper-protection, too! And to be clear, I'm not suggesting we should just tell people to use these tools instead of giving them a good UI for it, I'm suggesting we should use these tools as the underlying mechanism for a decentralized GitHub. Build a great UX on top of git instead of embedding git in a blockchain. > Along with this it enables us to provide a novel means to incentivize open-source contributions along with fostering a more decentralized approach for governance (even for projects), every token holder could have a say in the decision making, reducing the risk of undue influence by a single party, hence eliminating centralized control. This one I'll grant you, but it's by far the least compelling aspect of the project to me. I don't think we're going to solve the centralization of GitHub by centralizing on a new plutocracy, I'd much rather see efforts towards full decentralization. There's nothing inherent to Git that requires that we all use the same set of servers. [0] https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work [1] https://git-scm.com/book/en/v2/Customizing-Git-Git-Configura... Thank you for your feedback and addressing your concerns. It's through conversations like these that we can continue to refine our platform. > I have to disagree here. Accidental complexity in a system can have severe downstream impacts on end users, whether that be in the form of poor performance, unreliability, or just slow update cycles. It's not something you can paper over and completely hide from the user. I completely agree that an overly complex system could negatively impact end users. However, our goal with the use of blockchain is to introduce new features and possibilities while striving to maintain the interface and workflow as familiar as possible for developers. That being said, we are continuously working to minimize potential drawbacks such as performance issues or slow updates. > Tamper-proof can be accomplished natively by signing [0]. receive.denyNonFastForwards and receive.denyDeletes[1] can be used to make a git repository immutable. Git commits are also already content-addressable. And transparency is achieved by just having the repo available for people to clone. Just to clarify, we are not embedding the entire git repository on the blockchain, that will be an overkill. We only store the refs[0], access rights on the chain, which is the most critical information about the repo state. So, the chain's here is not to serve the repository but to keep a tamperproof record of the repository state (refs), who all have access to modify it and anyone can verify the history of these updates on the chain along with the collaboration history. > Could this augmentation not be accomplished by storing the collaboration information in the repo under a set of special-purpose branches? Like git-bug[2] or git-issue[3]? Coupled with GPG signatures and you've got your immutability and tamper-protection, too!
And to be clear, I'm not suggesting we should just tell people to use these tools instead of giving them a good UI for it, I'm suggesting we should use these tools as the underlying mechanism for a decentralized GitHub. Build a great UX on top of git instead of embedding git in a blockchain. Clarifying again here that we are not embedding the entire git repository on the blockchain, that will be an overkill. We only store the refs, access rights on the chain, which is the most critical information about the repo state. And since git already has data integrity checks for the objects, we can just serve the repository objects/packfiles from a separate data store.
We did explore git-bug and git-issue for issue tracking, but decided to implement the issue tracking on the chain itself for supporting additional features (bounties, for example) and better user experience. > This one I'll grant you, but it's by far the least compelling aspect of the project to me. I don't think we're going to solve the centralization of GitHub by centralizing on a new plutocracy, I'd much rather see efforts towards full decentralization. There's nothing inherent to Git that requires that we all use the same set of servers. Your final point on full decentralization versus a new plutocracy is well taken. The token-based governance isn't designed to create a plutocracy but rather to encourage involvement from the community. The ideal is that each stakeholder would be more motivated to contribute and partake in decision making. We can't deny the fact that GitHub has been one major factor in bring the open source development to the mainstream. And we strongly believe the importance of a common place for open-source code collaboration. Projects using their own self hosted git server and their custom tooling will miss out on new contributors and visibility, unless they are well established like Linux, bitcoin, etc. That said, we're aware this model isn't perfect. We're open to suggestions and continuous iteration is part of our process. [0] https://bigdipper.live/gitopia/transactions/B4CEB69B08DE82D9... I'm failing to understand which problem this solves. Git is already distributed and the blockchain / token part is usually not something that most projects have issues with. See big projects like Linux and Bitcoin which have distributes workflows, proposals, distributed stewardship. I completely understand your points. Git is indeed an exceptional distributed version control system and has served projects like Linus and Bitcoin really well. However our platform isn't trying to solve a deficiency in git. Rather, it aims to introduce new features and capabilities that might not be essential to every project but could be beneficial to some.
The introduction of a blockchain layer offers immutable, transparent and tamper proof versioning of code. It is augmenting the current collaboration flow. This could be crucial for certain projects where provenance and auditability are paramount. Regarding tokenization, it could provide a novel means to incentivize open-source contributions. It might help projects attract and reward contributors, something that has been a long-standing challenge in open source development.
In contract to traditional project governance models, Gitopia could foster a more decentralized approach for governance (even for projects), every token holder could have a say in the decision making, reducing the risk of undue influence by a single party, hence eliminating centralized control. The need for these features varies greatly depending on the nature of requirements of each project . We believe in providing tools and options for those who find them useful or necessary. We are not suggesting a replacement of git or traditional practices, but rather an additional option for certain contexts. > In addition, you may not use any of the Marks as a syllable in a new word or as part of a portmanteau (e.g., "Gitalicious", "Gitpedia") used as a mark for a third-party product or service without Conservancy's written permission. https://git-scm.com/about/trademark Disclaimer: I work for GitLab, but I think that name predates this policy. Just sharing in case you weren't aware. More information in this email thread: https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw... > The USPTO initially rejected our application as confusingly similar to the existing trademark on GitHub, which was filed in 2008. While one might imagine where the "Git" in GitHub comes from, by the time we applied to the USPTO, both marks had been widely used in parallel for years. So we worked out an agreement with GitHub which basically says "we are mutually OK with the other trademark existing". > ... > So GitHub is essentially outside the scope of the trademark policy, due to the history. We also decided to explicitly grandfather some major projects that were using similar portmanteaus, but which had generally been good citizens of the Git ecosystem (building on Git in a useful way, not breaking compatibility). Those include GitLab, JGit, libgit2, and some others. The reasoning was generally that it would be a big pain for those projects, which have established their own brands, to have to switch names. It's hard to hold them responsible for picking a name that violated a policy that didn't yet exist. Thanks for bringing this to our notice. Will need to check this with our legal team. Meanwhile we have a registered trademark for Gitopia in multiple jurisdictions as well as classes. Seems like a gimmick. Forgejo if you want something like this without the "Blockchain". Thanks! Have been using Codeberg and this seems like a self hostable version with the same ideals in mind! Not just the same ideals, it's the same software: it's Codeberg's fork of Gitea, and it's what they use to run Codeberg. Very nice 1st off - like the design touches on the website. And kudos for getting something off the ground: 0->1 is hard! Is this just another Gogz/Gitea derivative (the Hub repo looked Golang so I am guessing one of these projects)? Is there something decentralized about the Hub part? From my quick 2m glance I couldn't see anything. > 1st off - like the design touches on the website. And kudos for getting something off the ground: 0->1 is hard! Thanks for your positive feedback. > Is this just another Gogz/Gitea derivative (the Hub repo looked Golang so I am guessing one of these projects)?
Is there something decentralized about the Hub part? From my quick 2m glance I couldn't see anything. To clarify your queries, our project is not a derivative of Gogs or Gitea. The repository refs, access control info and other critical data are stored on the blockchain. This adds an extra layer of security, as it makes it very difficult for any malicious users to tamper with this critical data. And all these updates can be verified by anyone on the public blockchain. The golang repository that you refer to here (gitopia/gitopia) is the chain repository that uses cosmos-sdk/tendermint(comet-bft) Regarding the storage of repository objects/packfiles, these are stored separately and backed up using IPFS and Filecoin. Currently there's a custom server logic that sits between the user and the data store, which uses the git protocol for optimization. However, we're actively working on removing this dependency. We'd love to have you try out Gitopia and get your feedback. I apologise in advance if this seems inflammatory, I'm not trying to start an internet argument here, I'm just being honest about my first impressions of this app. Of all things, the spaceman in a car was what put me off this, as I straight away felt like anyone who would use that as art must be some kind of Elon Musk superfan. And then the buzzwords web3, blockchain and *coin made me turn away completely. I'll say one nice thing - I like the live preview of the app on the front page that is interactive and actually works. More web apps should do this Thanks for the feedback, we are currently working on a new landing page. The images that you mentioned were put there to represent the wide usage of Open Source code in all walks of life. Also I agree with the buzzwords, even though they are true and not just buzzwords for Gitopia, I understand how it might put devs off (given the wide scam/spam associated with them). We will fix it soon. > I'll say one nice thing - I like the live preview of the app on the front page that is interactive and actually works. More web apps should do this Thanks, it was put up there to show that Gitopia is open source and is being developed on Gitopia. Also that we are not just an idea or whitepaper, the app is live and working. Isn't a platform closed and centralized by definition ? ("Protocols, not platforms!") Traditionally, "platforms" are centralized, controlled by one entity, while "protocols" are decentralized sets of rules for communication. However, today's "decentralized platforms" or dApps blend both. They provide services like platforms but operate like protocols, with open-source code [0] [1], decentralized governance [2] and transparency. But, i do agree with centralization with respect with hosted webapp at gitopia.com. However, since webapp is open-source, anyone is free to host their version. And, also we have plans to release a desktop app which removes the reliance on a website altogether. [0] https://gitopia.com/gitopia/gitopia