It’s notable how prevalent AGPLv3 licensing is all throughout the Fediverse. This, and the fact user accounts are decoupled from the federated frontends present a radically different incentive structure for providers compared to the traditional model of social media.
You can feel the impact this has when browsing PeerTube: eclectic videos — a good sign of a burgeoning ecosystem — but with video buffering rates seemingly decades behind YT.
I’m actually a huge fan of the fediverse. But if PeerTube in particular wants to hit it big, there are some serious scalability issues which need to be addressed, despite fediverse development being largely antithetical to profit.
Software that isn't executed on a user's machine is out of the user's control. The GNU AGPL redefines distribution to include serving over a network so that software served over a network must disclose source code as well (unminified JS, server-side code, etc). It's also copyleft, which is good: the purpose of permissive licenses is to enable proprietary derivatives, which is against the spirit of the Fediverse.
One interesting consequence of Mastodon's AGPL licensing is that Gab, the right-wing twitter clone that runs a Mastodon fork, also has to disclose its source. That was how people found a vulnerability in Gab that allowed the recent "hack".
Because what you're offering is a service, and not someone else's software. Your added value is not actually in the code or the cute pictures; it's being available, having a low latency, allowing people with no tech knowledge to take part in the discussion, building a relation based on mutual trust rathet than serfdom. It's fundamentally the difference between a user and a consumer.
As an operator you're always making a tradeoff between the "negatives" of a license and the "positives" enabled by the actual software.
So for one example, the recent (bait and) switch of Elasticsearch to SSPL effectively means that for many actual real-world users of Elasticsearch, the benefits of staying on the official Elastic branch has ceased to be worth the costs of the license when your alternative is running FOSS Elasticsearch/Opensearch.
So to answer your actual question - presumably as an operator you want to use the AGPL-licensed code more than you want to avoid those same negatives of AGPL.
I find that issue very confusing. How is a GPL-2 license not acceptable for being listed on a website of GNU projects?
I note they went along with the relicense but the site only currently lists "GNU FM" and "GNU Social". Is there an actual compelling argument for a project to choose a license just to be listed alongside those?
This is something I've never heard about, but are there any projects who license AGPL but offer paid relicensing to GPLv2? With customers paying for permission to keep private their modifications to a hosted service?
This is a nice list of federated networks. Sadly, many of them look like ghost towns. A lot of them have home pages with marketing content but that don't show any easy way to get to network content. Others have content and links to founders profiles that haven't been updated in years. It's really hard to get excited about many of these when even the people building it don't seem to use it.
> even the people building it don't seem to use it
This is a (unintentional, perhaps) statement of FUD based on your perception, and not based on reality.
I came across a pretty good quote the other day in relation to the ActivityPub space which struck a chord: "A resource arrangement that works in practice can work in theory" - https://en.wikipedia.org/wiki/Elinor_Ostrom#Ostrom's_law
I think maybe you're being too harsh in your comment, by calling an partial observation "FUD". It's true that there are many dead toy implementations, and many servers don't display content on the main pages, so it's actually quite easy for first-comers to think the network is dead. (and I did too years back.)
there's a certain amount of a "head in the sand" vibe here at HN. I guess if these VC types don't have raw stats like DAU/MAU or something's not monetizable, there's nothing it it for them.
The incredibly damaging and widespread exploitation of SMTP for cybercrime (via phishing, etc) implies that the correct model for Internet messaging is non-federated, i.e. more like HTTP than SMTP. That's not to say that federation isn't valuable in other applications, e.g. social media.
Federation in SMTP was necessary given the Internet's topology when email was invented. That network is long gone.
See TMTP, from the mnm open source project, which implements both the client & server:
I strongly disagree. If email was non-federated (like HTTP) then either it wouldn't be so ubiquitous, or a single company would control the digital communication of most of the world's citizens.
Either of those outcomes would result in a poorer world.
The fact that facebook, telegram, whatsapp, etc are all centralized doesn't seem to stop criminals using those platforms.
Zillions of websites have active discussion boards, despite the success of Reddit and FB Groups.
A handful of webmail providers have centralized a large fraction of all email users. They already have the control you're concerned about.
Non-federated email means you have accounts at several sites, and most sites have membership requirements (customers-only, employees-only, etc). A client app keeps track of all your accounts. A webmail intermediary is unnecessary. The mnm demo gives a sketch of this [1] and the FAQ gives more detail [2].
If email worked the way those sites do, I'd need a microsoft webmail account to talk to microsoft webmail people. And a gmail account to talk to gmail people. And an apple account to talk to people there. And so on. That would be a much worse experience of email than we have today.
Federation in email is used constantly and ubiquitously. Why would anyone want to turn it off?
Given that you could easily "unfederate" SMTP/pop3 and have the exact same model, I don't see how exactly the lack of federation will be a selling point.
I see any value in TMTP in the improvements as a protocol and I think it will be only be hurt by having no provision for federation in the protocol.
A TMTP server could act as a proxy between a client and service; there are a few use cases for that (mentioned in FAQ, but not in current protocol draft).
I'm not aware of any use cases for store-and-forward federation that aren't better served by a client-server network. And I've been thinking about this around the clock for four years :-)
It’s certainly a worry, but at least other options do exist. And if you own a domain name, you can move your email hosting (including all your addresses) to the provider you like the most.
And it’s certainly a much better situation than other chat systems, where your identity is fundamentally tied to your account on that particular service. You can’t move to signal without moving everyone else to signal at the same time. I only need one email provider and one email app. But for messaging, everyone ends up needing signal, and WhatsApp, and Facebook to talk to each other. Imagine if you needed half a dozen email apps and accounts for each one to use email. “Oh, you’re emailing a company who uses Microsoft? Better open the Microsoft email program and remember your Microsoft login”.
I don't think federation is the core issue with e-mail. I see the core problem as terrible MUAs don't use nearly enough signals to interpret identity of senders.
SMTP has means to identify servers and domain ownership, web browsers have infrastructure to identify and verify arbitrary websites, and S/MIME exists. Most MUAs ignore basically all of this and instead trust whatever address is in a message's From header.
DMARC is only as effective as the domain's suggested policy and the receiving server doing the right thing. It also doesn't have much if anything to do with the MUAs as they don't see any of the SPF/DKIM operations happening. DMARC doesn't do and isn't intended to do anything to verify the content or validity of an individual message.
That is why I think we are still in early days of the (fediverse-powered) web. All this fringe tech will blossom eventually and we can live the 'decentralists dream' we all seem to be pushing for. Give it time. Yes, effort is still needed, and we all need to do our part to make it work, but simply being patient too, waiting for all this tech to bloom will be worth it.
Pretty much the same applies: I'm quite happy with my Linux desktop, I don't need it to dominate the world to be useful. (for social stuff of course additional network effects apply, but if you are in the right communities that's easily hit)
Linux desktop/laptop is actually pretty usable nowadays - installing Ubuntu on a laptop is much less of an "adventure" than it used to be, with fewer incantations needed to get things working.
In fact I just installed Ubuntu on a laptop this evening, and it worked really well. (I did make sure others had met with success with this specific model of laptop before I tried it though.) Things have come a long way since "linux on the desktop" first emerged as a meme.
FWIW I've considered Linux better for my purposes since 15 or so years ago and easier than Windows since over a decade ago when I had to spend 4 hours to "configure" an OEM install.
(That included everything from I clicked the button until I had uninstalled McAfee and every other useless thing but still.)
If you haven't, try mastodon. There great conversations happening over there, depending on the instance.
If you're interested in FOSS check out fosstadon
I'd say just try any of the microblogging-capable federated apps, and weigh them on their pros and cons. Like Pleroma for instance.
Mastodon is by far the most popular app. A lot of that is by better productization and name recognition, leading to network effects. Downside to that for the Fediverse is that many newcomers think Mastodon === Fediverse, and don't discover all it has to offer.
For devs willing to contribute, or start their own federated projects, there's much to choose from and build upon. There is much untapped potential in the under-used Linked Data aspects of the specification. To build entirely different app types and protocols that interoperate (which need not necessarily be with entire fediverse). ForgeFed is an example of this.
This has not been my experience. On public timelines of instances with even moderately popular users, the public timelines get messages minutes or seconds apart. Plenty of users have hundreds (or in the case of some admins and fediverse devs, thousands) of followers. It's a thriving community.
A federated network is a group of systems that agree on a protocol to communicate and share resources.
Email is one of the classic examples where. Anyone can build and run their own mail server. As long as a server supports SMTP, users on it server can communicate with users on any other email server. No need for special cases which depend on which server you're sending mail to.
Good answer. Email is the classic example. I'd like to add another to more clearly show whatvis new here:
Mastodon is like Twitter, except anyone can host their own instance and you (and others) can follow each other across instances, just like mail in iamevn's example.
Pixelfed does the same for images, it is kind of an Instagram clone where you can follow others.
Writefreely enables the the same for blogging.
Also to the degree it is practically possible it is often possible to follow accounts across types, for example a Mastodon account can follow a Writefreely account.
Oh, and they are mostly (all?) open source, and since everyone can create their own instance it is harder to block out people (you can of course block people you find annoying etc, but Mastodon cannot receive a request from a government and suddenly you are thrown out from the network, they have to apply pressure to every instance around the world and then you could always create your own instance.)
If you think this sounds insanely cool then you are right.
You can feel the impact this has when browsing PeerTube: eclectic videos — a good sign of a burgeoning ecosystem — but with video buffering rates seemingly decades behind YT.
I’m actually a huge fan of the fediverse. But if PeerTube in particular wants to hit it big, there are some serious scalability issues which need to be addressed, despite fediverse development being largely antithetical to profit.