Probably a dumb question, but don't federated services eventually lead to centralization? for example SMTP is federated but most users are on gmail, IRC is decentralized but most users are on freenode server, etc. users tend to choose the services/instances with the most users, which is what makes github currently very valuable.
Gmail killfiled a domain I was running on a small but reputable ISP I had used since 2001 (there were no spam or reputation issues in 17 years).
They did let one-in-20 or so emails through, but everything else got to gmail recipients’ Spam folder. I wasn’t able to troubleshoot this with Google tools, and there’s no one to talk to at google.
(Worst thing, you get no feedback - except realizing a month later that someone didn’t get an email you sent)
I gave up and replaced small ISP with fastmail.
My bottom line is that, no you can’t really run your own SMTP server anymore unless google, Microsoft and fastmail let you, by virtue of hoisting 90% of your recipients.
Sure, something like that can happen... but it is not like they have an explicit "allow-list" of domains that mail can be received from. These might be the biggest providers but if me and my friend who do not use their services want to communicate, we will always be able to do so without them.
I have many domains that I use to send and receive mails, and I have personally never had these issues.
Now if I did have a gmail account, I suppose I would have to check the spam folder regularly. But I don't have that problem with my server, it affects their users more so than me.
in the current world, you host your code on github and you can only submit prs to github with a github account. anyone without a github account cannot submit a pr. github hosts all the code.
in a federated world, while github may still host all the code, you could potentially submit prs with and have metadata about a repository, such as issues, spread across multiple different providers. Instead of needing a github account to contribute, you just need an account that github could federate with.
This would mean that if Github did start doing something you didn't like, you would be able to change code host without losing the metadata.
Potentially, anyway.
Federation doesn't prevent centralisation if the service is good enough; it just makes it less painful to decentralise if better competition exists. It also diversifies ownership of data, which is in general a good thing for consumers - and a bad thing for big tech companies that wish to make money off of analytics, which is why we will never see current social media platforms allow federation with other social networks, even if would be better for the world and consumers.
IRC isn't federated in that sense, users on EFnet can't interact with users on freenode, so the network effect works in that case.
Gmail has an enormous market share (about 40%) but I don't think that's related to the nature of SMTP, more about their incredibly competitive free tier and the decidedly not federated groupware for their business offering.
ActivityPub is federated like git is distributed. You can add several remotes from different servers (or peers in case of single user instances hosted at home)
Even though other sites like GitLab exist that GitHub remains a near-monopoly default doesn't bode well for attempting to migrate to a completely decentralized system as default. There are decentralized extensions of git (like git-ssb).
Addenda: Git is also not well suited for a lot of decentralization due to how branches are modeled. Patch-theory based systems like darcs and pijul would need more adoption before code repositories could be decentralized.
I understand that but there is a difference between just git and the forge, which is GitHub in this case. If I fork a project on GitHub it has a fork relationship on the platform itself. This makes it very easy to interact with the original project. However, without an actual GitHub account I can't contribute back to the project at all.
If I have for example my own Gitlab server I have the ability to clone a project from GitHub and maintain my fork on my server. However, to contribute back, I will still need to bring my changes back to GitHub first.
What a federated implementation of such a "git hosting/collaboration platform" would allow me to do would be to fork a project from another instance to my self-hosted instance. It would benefit every open-source project that would be willing to host their own instance. I could then easily contribute back into the main project without needing an account on their instance.
It would also make it much harder to take down a project with a DMCA like this because forks of it would exist across instances, meaning claims would have to be sent to each maintainer of these instances. In this case, they were simply able to list all of the forks on GitHub and because GitHub is one website, all of them were taken down, seemingly without any further inspection wether the claim covers these forks as well.
I realise that this is difficult to implement but I think mastodon is a great example of how such federation can work in practice.
What if you could make a federated/decentralized git that doesn't care whether the git repo is made available by github or my-fancy-federated-git-host?
It is like wanting to keep Twitter in the loop when migrating to federated alternatives like the Fediverse. Twitter (or Github) wont federate in good faith and will actively attempt to capture as much users as possible.
> What if you could make a federated/decentralized git that doesn't care whether the git repo is made available by github or my-fancy-federated-git-host?
Git is distributed already; remotes work like that.
Yeah Twitter doesn't work because it's not simply hosting the posts that you interact with elsewhere.
Github is simply hosting the repos.
Git is decentralized already. That's the key difference between Twitter and Github and why I made GAnarchy the way I did. and also why I make a point of hosting a GAnarchy instance on github pages and encouraging others to do the same. (self-hosted is better of course, but.)
