3 ms·

Github is a forge. Sourceforge is a forge. Every independent codeberg, gitlab and gitea server (and there are more) that is running is a forge. Right now, you

Github is a forge. Sourceforge is a forge. Every independent codeberg, gitlab and gitea server (and there are more) that is running is a forge. Right now, you have to have an account on one to open issues, make pull requests, contribute in any way to code hosted on it and only it, and you need an account on each and every server you want to contribute to, even provide a bug report. This is no good, because people who like to host their own code can only frictionlessly contribute to their own code, or code hosted on their forge, or the forge they put their code on. How many people are going to create an account on gitea.bobsserver.biz just to put a bug report in for an annoyance in some app they use? This is why github has a near monopoly in this space, everyone can contribute with a github account. To decentralize this, I need to be able to put a PR in your project hosted on your forge using the account I have on my forge. This is what ForgeFed does, it is an extension of ActivityPub to enable federation of forges.

smarx007 5y ago
Thank you! Please put this explanation on one of the webpages explaining the aims this project.
- Kye 5y ago
  Documentation continues to be the most undervalued and underappreciated part of open source while being absolutely essential for any project that cares about adoption.
toastal 5y ago
Sourcehut's and a more traditional approach is decentralized by using decentralized technology like git send mail, mailing lists, and IRC. However I'm still happy to see this decentralized identity and ActivityPub integration. I hope it catches on more.
geokon 5y ago
Isn't the problem of having universal accounts across servers independent of git and hosting code? I don't see how the two are related. It's a good goal, b/c at the moment you only have "Login with Google" or "Login with Github (ie. M$)". But I hope the ultimate solution isn't compartmentalized to source code management Maybe I'm not seeing some aspect which ties the two together?
- danielheath 5y ago
  At present, you can move a repo between forges by cloning it locally and pushing it back up. However, you lose the issues/milestones/PR comments etc. Federation is useful since it defines a portable standard for those things. If you have an account on federated forge site A, you can use it to file bugs (via the forge A UI) against a project on federated forge site B. Both websites UI will show the bug and any comments on it - data will be replicated. In practice, there'll likely be complexities around EG moderation (particularly for larger projects making controversial decisions), replication occasionally losing data due to intermittent faults, etc. IMO those technical reasons are less likely to sink the project than inertia is; people are already using github.
  - betwixthewires 5y ago
    I don't think inertia is really a problem. People are already using these self hosted options, and particularly in FOSS, people value the option to be independent. Maybe it won't sink github, but it will probably end the practice of people mirroring there and running their own canonical repo elsewhere.

smarx007 5y ago

Thank you! Please put this explanation on one of the webpages explaining the aims this project.

Kye 5y ago
Documentation continues to be the most undervalued and underappreciated part of open source while being absolutely essential for any project that cares about adoption.

toastal 5y ago

Sourcehut's and a more traditional approach is decentralized by using decentralized technology like git send mail, mailing lists, and IRC. However I'm still happy to see this decentralized identity and ActivityPub integration. I hope it catches on more.

geokon 5y ago

Isn't the problem of having universal accounts across servers independent of git and hosting code? I don't see how the two are related. It's a good goal, b/c at the moment you only have "Login with Google" or "Login with Github (ie. M$)". But I hope the ultimate solution isn't compartmentalized to source code management Maybe I'm not seeing some aspect which ties the two together?

danielheath 5y ago
At present, you can move a repo between forges by cloning it locally and pushing it back up. However, you lose the issues/milestones/PR comments etc. Federation is useful since it defines a portable standard for those things. If you have an account on federated forge site A, you can use it to file bugs (via the forge A UI) against a project on federated forge site B. Both websites UI will show the bug and any comments on it - data will be replicated. In practice, there'll likely be complexities around EG moderation (particularly for larger projects making controversial decisions), replication occasionally losing data due to intermittent faults, etc. IMO those technical reasons are less likely to sink the project than inertia is; people are already using github.
- betwixthewires 5y ago
  I don't think inertia is really a problem. People are already using these self hosted options, and particularly in FOSS, people value the option to be independent. Maybe it won't sink github, but it will probably end the practice of people mirroring there and running their own canonical repo elsewhere.