The Fediverse - especially the microblogging side of it - has deep issues when it comes to environmental sustainability.
And the high resource requirements, which result from an incredible level of redundancy, aren’t just bad environmentally: they make running a server more costly, and increase our reliance on Big Tech’s infrastructure.
I wrote about all this, along with some suggestions for how we can improve things somewhat.
I agree that we should reduce energy consumption wherever possible, but we also need to look at the big picture. The entire fediverse is just a tiny fraction of the energy consumption of the internet. Way more energy is needed for AI and other big tech bullshit.
I recommend watching this awesome video, as well as the updated version of it: https://www.youtube.com/watch?v=F-6la_I-xkQ
Here is an alternative Piped link(s):
https://www.piped.video/watch?v=F-6la_I-xkQ
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Not completely on topic, but, in the spirit of reducing and changing consumption, some of you may be interested in the Gemini protocol. It’s supports a version of the web that’s simpler by design and focused primarily on text-first posts. Folks on the network like to compare it to the early web. I recently learned about it from this tutorial.
There’s not a ton there right now, and it’s not going to replace the web as we know it, but it’s worth a look just for fun.
The protocol is compatible with ActivityPub, so you can also have federated Gemini apps. I haven’t tried out tootik because microblogging isn’t really my thing, but it’s interesting that it exists.
Nice. Yeah Gemini is pretty cool, and that actually reminds me, I have to publish this piece on my gemlog as well ;)
Haven’t tried tootik either but thanks for pointing me to it, will check it out!
Very cool! If you want to post a link or message me, I’d love to check out your gemlog. I thought this piece was really interesting.
I’m just getting into self hosting, and the “storage waste” of all this duplicated content has been on my mind a lot, but I hadn’t really considered the energy costs or the feasibility for folks with data caps, slow Internet connections, and so on.
I absolutely love the idea of federated applications. It would be great if they someday became the dominant way of running things. But, even if we could get every user interested, I haven’t really put in enough thought or research to know whether running these applications at huge scales would be feasible or desirable. It’s great to see folks talking about the problems we’ll run into and how we can be better than current big tech companies about considering the impact of our choices.
Anyway, thanks for the well-written and insightful piece.
Thanks! Yeah tbh the gemlog is really just a mirror of the blog, but for the record it’s gemini://gemini.patatas.ca
Good points, makes me think of how good lightweight RSS readers were at accomplishing the same kinds of content aggregation goals, and worked well even over 56k modems.
The practical suggestions sound good but the rest of the blog post makes this sound like a much bigger issue than it is, I feel.
There are simply not enough servers or activity on the Fediverse to have to worry about this at this point, if you ask me. It could for sure be better with regards to environmental concerns, but there’s a lot more pressing issues I think.
I think it is a pretty major issue. A single-user instance shouldn’t need more than 100 GB. The internet is too bloated, which is a democratic problem as well as an environmental one.
It’s of some importance for the Fediverse in particular, as we want to have a system of many independent instances with low running costs and minimal environmental footprints. A bloated piece of software running on one centralized server is different from it running on thousands of decentralized ones, and higher running costs means that instances are more likely to disappear rendering the network more fragile.
Of course it’s not the biggest problem out there, but I think it’s important enough that it should be a priority.
A single user instance doesn’t need nearly 100GB, so that’s fine. My own instance which is not even single user doesn’t even use 100GB yet.
I don’t think it’s as bad as the post makes it sound. But I mean yes, of course efficiency and costs are important to optimize for.
Honestly I think a single user instance should be lightweight enough to run on a Raspi. Even having multiple. A lot of them don’t need their own frontends either. Can just use an app
What I feel is missing from the practical suggestions section: why cache images at all? They should be stored on the server they were uploaded to, and nowhere else. The image URL would be attached to the post, and could then be used by clients to fetch the image from the original server.
I thought lemmy did this, but it seems not (any more?).
I hear you on this - Akkoma does this by default, but the issue there is, let’s say someone on a tiny server posts an image, even a relatively small one - if it gets boosted by an account with 10k followers, that small server will effectively get DDOSed, assuming enough of those clients are online.
Also the software needs to be efficient. Use less RAM and CPU cycles. And I don’t think the ActivityPub protocol in itself is very efficient. I’d like those aspects compared to an old federated technology like NNTP or email.
But I’d agree on the things in top. Content should get compressed and cached on demand. Neither transferred every time from the original instance, nor transferred without a user ever viewing it. Caching on demand or a DHT (P2P) storage backend could do that.
How much of the power consumption is from the servers and how much is from the clients?
That’s a good question. The best answer is, I don’t know!
But if I had to guess, based on the small amount I’ve learned:
larger servers most likely benefit from economies of scale. They’ll be using CDNs, and will often have several people on their server following any given remote account, rather than just one. So the per-client energy use is almost certainly lower than for small servers.
But it’s still tough to know whether it’s the client or server using more energy. IIRC with video streaming, the end user’s device was a big factor in overall consumption - but it’s not like the server is chugging away 24/7 fetching media for you like a Fediverse server is.
For single-user servers, or servers with only a few accounts, I expect the server (and all the network infrastructure in between two servers) is doing a lot more work than the client(s) - unless it’s like, the server is on a raspberry Pi and the client is running on a powerful desktop for a lot of the day, or something. Again, many factors at play.
Really though, the question I start to ask in all this is more about, which parts of the system are the most difficult to justify?
___
I appreciate the practical suggestions section, there’s some great ideas there.
You might be interested in the low bandwidth mode that https://piefed.social has. It can be enabled during login and removes most of the images and Javascript.
Really, developers need new tools to support these values. Our dev tools report on performance and reliability but not on sustainability / energy use / CO2. Our programming frameworks offer flexibility, power and expand-ability but never intentionally constrain our energy / waste / performance. The only exception to this that I’ve seen is Google App Engine which has some resource utilization limits and a pretty limited ORM that feels like fighting with one hand tied behind my back sometimes.
Low bandwidth mode - what a great idea, thanks for pointing it out!
Fair point and while I don’t want to sidetrack from it — how much is the Fediverse’s energy usage compared to those of AI services or cryptocurrency farms?
I’m all for scaling down our resource consumption and finding environmentally friendly alternatives, but it has to be across the board. It’s no use that a small segment minimise their expenditure if the biggest culprits continue and expand their exploitative behaviour.
How about we do it because it makes us feel good, morally? How about we do it because we want to set a good example?
This whole “I won’t change until those who are worse than I am change,” is so juvenile to me.
No, I agree. It’s not about waiting out the bigger players. It’s making sure that everybody does their part!
The fediverse has its footprint for sure and it’s great that we pull together to minimise that. I just want to put it in perspective at the same time and point out that federated services aren’t the only, or even biggest offenders here.
Many of the hotshot technologies — cryptocurrencies a few years back, this season it’s “AI” — get launched without a thought of their environmental impacts, at a time where basically every MWh counts. I want to help with my fedi usage, but I also want that to be reflected in idiots’ bitcoin mining or GPT generated “content”.
There has to be proportional balance.
Given all of that, I’d say it’s a good thing to get active and accuse these big environmental crooks, while at the same time being perfect examples of how to minimize our own footprint. Nobody will listen to accusations from someone who isn’t perfectly innocent themselves.
how much is the Fediverse’s energy usage compared to those of AI services or cryptocurrency farms?
Practically 0.
That’s my intuition too. Would like to see sources to back it up though.
Well this site says that the bitcoin network uses at least 91 TWh annually.
According to fediverse.observer, there’s roughly 21000 Fediverse servers online.
Let’s just assume that a server on the Fediverse uses 500W. That’s quite a high estimate btw, but we can overestimate, it’s fine.
That gives roughly 0.09 TWh annually, or about 0.1% of the bitcoin network. And remember that’s an overestimate and remember that that only considers bitcoin and no other cryptocurrencies.
👍 That confirms my own assumptions, thanks for the link and estimated comparison!
