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.
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.
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.
> 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.
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.
- We are now working on the governance and collaboration workflows that will enable transparency in open source development and provide the stakeholders to have a say in the direction of the project.
I'm not sure I see the point of building a complex platform with governance and whatnot. What I want is an easy way to publish my projects and for other people to contribute, I need something more like email (independent, self-hosted servers with a well defined protocol to communicate between them) than Facebook.
I don't care about the governance of my git remote, or getting money out of it. I care about it being reliable, fast and simple. If I'm unhappy with it I want to be easily able to switch to a different host, or create my own.
Frankly I would be perfectly fine with the current situation where you have a bunch of effectively centralized code hosting solutions (github, gitlab, bitbucket etc...) if you could trivially move your project from one to an other. For the code it's easy, git is built that way. For issues, PRs and the like it's trickier.
For me that's the problem that needs solving, I don't need an ultra complicated blockchain-powered solution where people can vote for the font of the UI with cryptotokens.
At a glance, and if I understand it correctly, Radicle seems more pragmatic in that way. Cryptocurrency is used for donation and securing entries in the global namespace in a decentralized way, the rest is just a bunch of standalone servers. Then you can decide to host your code on an existing instance or spawn your own. A bit like how Mastodon works for instance.
You might be interested in https://github.com/MichaelMure/git-bug. It stores issues directly in the git repository so the whole issue tracker is as distributed as the rest of your code. I can't speak to the UX though.
The best solution from my perspective for the community would be to have a standard that handles issues/prs and the like that could be taken from one code hosting solution to another. Just like how you can take your code with ease from one solution to the next by cloning.
It’s the same idea that we already use for our code but applied to all the other bits that are necessary for maintaining projects.
There are some pretty obvious problems with actually implementing this, however. One of which comes down to getting all the existing code hosting solutions to agree on a standard. As they could simply create ancillary standards to differentiate thenselves. Not to mention all the work involved in implementing this when most people are accepting of what we have now (until it bites them somehow).
We've been building a platform called Skynet which makes this possible. It has a user-oriented data model: all of the application code is run client-side, and all of the data is stored under the user's control.
That means that someone can create a new application at any time which has access to all of the data - because all of the data is accessed client-side and owned by clients in the first place.
This doesn't solve the standards problem, but on the other hand I think what would likely happen is the first project to become successful would also become more or less the standard, with other people building extensions to that data standard over time.
I feel that there is a real need for permanent Storage with respect to Open Source.
Code breaks when old packages are unpublished or repositories deleted. Push once and fetch forever solves this.
Also Centralized solutions are providing open source collaboration tools for free, storage for free, because of their revenue from enterprise customers.
What happens when they decide to shut down? or change their policies? or just comply with wrongful takedown notices?
Would IPFS or DAT not suffice there? How is 'another permanent storage, that is a piece of a larger project, better than one that has the sole purpose and focus?
The challenge with IPFS and DAT is that you have no guarantees around the data reliability. The DHT style of p2p sharing pretty much only works for popular content. Incentivized storage networks can onboard any type of data and guarantee high uptime.
It's also been my experience that IPFS has significant performance issues. If you use a professional gateway like ipfs.io or cloudflare it runs at good speeds but as soon as you switch to being fully peer-to-peer it's almost unusable.
I don't have much experience with DAT, it may not have the same performance issues.
disclaimer: I work on an incentivized storage network called Skynet
Those are but some of the problems that IPFS, Dat (or Storj and probably Skynet too) do, or will face.
That doesn't make "rolling your own" any more reliable, performant, etc. So the question becomes even more apt: why will "building your own decentralised storage as requirement of a much larger project" work. If even the focused, dedicated "decentralised storage projects" cannot solve some problems?
With git it's rare for a project that's actually in use to go completely memory-holed, every contributor effectively having a local copy of the resource.
Using git (generally github) repositories for dependency management is, IMO, a hack and so it's not surprising that it often breaks. I like the way buildroot handles it (I'm sure they're not the only ones, but that's the one project I'm most familiar with):
- The buildroot buildbot fetches third party packages dependencies and archive them.
- When you build your buildroot image locally, it attempts to fetch from the third party directly. If the file doesn't exist anymore, it falls back onto the buildroot cache instead.
You could also easily add your own caching layer in there if you wanted too. I think that's distributed computing at its best: simple and robust, with a clear and easily understandable architecture. No blockchain-based proof-of-stake distributed storage, just a series of wget. And of course since everything is authenticated with a strong hash it's always perfectly safe.
Buy hard drives, do frequent backups, store redundant backups remotely, use RAID. At the end of the day someone must pay for the hard drives and they could just stop paying for it one day. There is no such thing as permanent and free.
> I need something more like email (independent, self-hosted servers with a well defined protocol to communicate between them)
The problem with email servers is you need a special type of sys admin to maintain them properly, they are not for the light at heart when used anywhere beyond the most trivial case. Any server that grows to some well-used size has a myriad of problems (getting outright blacklisted, etc).
Well, that's e-mail. Modern federated systems don't have a different server for sending and one for receiving. ActivyPub implementations are usually a single application with a database (like Pleroma) or a single app plus db/reddis/elasticsearch(optional) like Mastodon. Mastodon has official Docker containers, and it's not difficult to build one for Pleroma.
So you can make something "like e-mail" that isn't as bad as SMTP/IMAP/SPF/DKIM/etc... I've been considering hosting my own Gogs or Gitlab or one of the other locally hosted git platforms. I'd like to see something that allows pull/merge requests between them (you'd need some spam prevention of course; maybe require a message and a follow before people are allowed to push an request to your server).
This project ... doesn't seem like it does that at all. It's a desktop application .. with no real web view into your projects. I feel like it's missing a component, a service run in a docker container that you can program with your Device ID and push your public repos to for others to see.
I think that works - but what GP mentioned is where it fails:
> Frankly I would be perfectly fine with the current situation where you have a bunch of effectively centralized code hosting solutions (github, gitlab, bitbucket etc...) if you could trivially move your project from one to an other. For the code it's easy, git is built that way. For issues, PRs and the like it's trickier.
Maybe there's a nice way to Gitea distribute this information among Gitea instances, though it doesn't seem advertised as such - as this would basically make Gitea some neat Federated tool i think.
Ultimately i'd like Git[ea|whatever] to be just a frontend for a database that behaves like Git. In the way same way that Github's Source Viewing is just a frontend for Git. You don't worry about moving your Source data between Github and Gitlab, so why are we worrying about universal data like Bug tickets, Feature tracking, etc.
I'm a massive fan of systems that behave like Git and Scuttlebutt. Which is to say, they're dumb - simple. Git can be pushed and pulled from basically everything. There's no complex suite of nodes around the world that are expected or assumed to operate for any Git functionality. In the same way Scuttlebutt - which offers P2P layers, is similarly dumb (though less so, unfortunately) when compared to more complex P2P offerings like IPFS.
In my ideal world we'd have a database to pair with Git that would have some very basic schemas to complement Git. Possibly even baked into Git. Such that when you move from Github to Gitlab to Gitea - everything truly essential comes with. Some things might change, like your CI if it was bound to Github - but still. Losing some things vs losing everything.
I personally am less concerned about using Github/etc. Ie i'm not dying for someone to give me a new Github. I'm seeking a way to reduce lockin.
NOTE: I'm working on a distributed database that fits my needs on my above design goals. Really it's just Git + some additional data structures which allow for more data types being stored, such as binary and structured data to build foundations for SQL layers and etc. It's not intended for general use, but i'd love to see someone pick up the idea and run with it. "Git for Data" has been done a couple times, NomsDB and DoltDB namely, but they still felt like they weren't Git-like in that they wanted to centralize - probably for SaaS reasons.
Thank you for sharing your work and great to see more attempts on the same problem. I am one of the maintainers of the Radicle project.
The main problem we encountered with similar systems that rely on blockchains / dht for storage is the problem of 'blockchain poisoning'.
This is when someone deliberately adds illegal content to an append-only source in hopes to make the sole act of replicating the project legally problematic, as correctly pointed out by Konstantin Ryabitsev of the Linux foundation with regards to a previous version of Radicle that was relying on IPFS. see https://radicle.community/t/the-radicle-social-model/317
I think you could add moderation to a project like this much the same way you can add moderation to a centralized project. You don't need to be as heavy handed as "community voting", you could just have each client nominate a moderator who is able to append instructions to ignore content that the client would follow.
Under this model, every user (or project) can choose their own moderators, which means you don't have to worry about other parts of the community having different ideas for ideal moderation - each project/user can subscribe to the moderation feeds that they like, and ensure that they get a clean experience.
This type of moderation is actually an upgrade from centralized systems, because it is much easier to nominate new moderators if you don't like what the old moderators are doing.
Considering the illegal content is added by someone who has access to the repository. The right way to address that would be via community voting, which then can decide to hide it from the platform since the data is permanent on Arweave.
This governance workflow will enable the community to make such content policies.
This kind of thing always makes me sweat. Are deletes at all possible? What if someone accidentally pushes keys to the repo? On regular github, at least you can nuke the whole repo and start over if need be.
I don't know. You can always clean the Git history & force-push it, but the developers would have to explain if there's any backups or archive kept anywhere...
Since data is stored permanently on Arweave, there's no way to remove it from the blockchain. However, you could force push your repo which would remove your concerned commit from Gitopia repository view.
Saw this coming. We are working on https://dgit.sh for the last couple of months. Dgit is a decentralized code collaboration platform where we harness the power of git for versioning and arweave blockchain for permanent data storage. We also have a Dgit community on https://community.xyz where the stakeholders take all decisions transparently via a vote.
Dgit will be available for use after its launch on 2nd November. If you are interested in what we are doing feel free to join our discord and chat with us https://bit.ly/dgitchat
> 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.