There’s a significant distinction between servers that are actively malicious as you’re describing and servers that aren’t fully compatible with certain features, or that are simply buggy.

Lemmy, for example modifies posts federated from other platforms to fit its format constraints. One of them is that a post from Mastodon with multiple images attached will only show one image on Lemmy. Mastodon does it too: inline images from a Lemmy post don’t show on vanilla Mastodon.

I’ll note that Lemmy’s version numbers all start with 0. So do Piixelfed’s. That implies the software is unfinished and unstable.

Federation doesn’t inherently require large amounts of memory. Fundamentally, it’s a matter of selecting a list of unique servers (likely tens, maybe hundreds) from a larger set of followers (likely hundreds, maybe thousands) and sending an HTTP request to each when there’s a new post. There’s a speed/size tradeoff for how many to send in parallel, but it’s not a resource-intensive operation.

Growth beyond a few tens of megabytes was a bug in Writefreely, which is a likely-suitable option several comments here recommended.

I’d put it farther removed from the technical side than that; dreadbeef is thinking like a manager. OP might be better off paying a third party $3/month to handle the details and host a heavyweight, full-featured blog for them, but that’s not what they asked for.

This is selfhosted, which I think implies a desire to self-host things even if it might seem a wiser use of resources to do something else.

I’m thinking like a programmer about what a basic blog has to do and the computing resources necessary to accomplish it. Software that needs more than a few tens of megabytes to accomplish that is not lightweight regardless of its merits.

This comment seems to be arguing that one should not demand blog software be lightweight because there’s inexpensive hosting for something heavyweight. That’s a fine position to take, I guess, but OP did ask for lightweight options.

It wants a gigabyte of RAM. Maybe that passes for lightweight in 2025, but given the fundamental things a blog has to do, I’d probably put the cutoff at less than a tenth that amount.

Some people have privacy expectations that are not realistic in an unencrypted, federated, heterogeneous environment run by hobbyist volunteers in their spare time.

It you have something private and sensitive to share with a small audience, make a group chat on Signal. Don’t invite any reporters.

Kind of defeats the purpose

That’s why the why matters. Some people might just not trust Windows to keep private data secure, but be comfortable running certain software on it in a VM, possibly a VM that isn’t usually allowed network access.

If you’re sufficiently motivated to get off Windows to invest time learning different workflows, there certainly are options. It sounds like you’ve tried some for image processing and found gaps. People might be able to help fill them if you go into detail about your current workflow, but there is no 1:1 replacement for Photoshop on any platform. If you’re a heavy Photoshop user, there may be no path to happiness for you.

There’s surely a 1:1 replacement for Visual Studio outside of Windows-specific development (which wouldn’t make much sense to attempt on Linux anyway).

I really want this to work out.

Why?

I don’t ask that to talk you out of it. I like desktop Linux. I’m typing this on desktop Linux. I’ve been using desktop Linux for most of my adult life. I ask because your reasons will inform the advice people can give you.

I do a lot of .NET programming and photo editing [with Windows-specific proprietary software]

There isn’t necessarily a good solution to this. Those are large, complicated programs with very deep workflows that are almost certainly going to be dissimilar in any substitute software, which is itself going to be large and complicated with its own ways of doing things. Using those specific programs may be more important to you than what OS you run them on.

It looks like Photoshop is probably usable with Wine, while Visual Studio isn’t. Using Wine means putting up with occasional instability and reduced performance. If you spend a lot of time in Photoshop, this may not be for you.

Another option is to run Windows in a VM for those apps. This will likely work smoothly with regard to the apps themselves, and generally performs near native, but does mean a less polished interaction with the rest of your desktop.

If you’re patient and want to gain a deeper understanding, try Arch itself rather than an Arch-based distribution that’s easy to install.

You’ll spend a long time on the initial installation and setup and you’ll read a lot of documentation in the process. When you have a usable system, you’ll understand what’s installed, how it’s configured, and why. Expect to spend a couple days just to get it usable though - this approach isn’t for everyone.

The Arch docs are top tier, but they’re not necessarily step by step guides because there’s more than one way you might choose to set things up. The docs tell you how the pieces can fit together, but it’s ultimately up to you to to do the assembly.

Total Webhosting Solutions

I’ve been with Porkbun since Gandi got acquired. No complaints.

It doesn’t exist, and some people get really mad whenever someone tries to make one.

https://cathode.church/fedi-scraper-counter.html

Seems to me the solution to this is registering protocol handlers for URLs, which Mastodon tried and gave up on because they weren’t happy with how web browsers handled it.

There’s a small, but extremely loud segment of the Mastodon userbase that seems to view presenting public posts in any manner that’s different from how a vanilla Mastodon server does as an invasion of their privacy. There have also been a few projects that raised reasonable concerns about privacy and moderation, but this page doesn’t seem to make a distinction.

It appears to contain misinformation about FediFirehose, which ran client side and just showed the output of a public relay.

From what I can tell, Bluesky is both decentralized and federated in terms of the protocol and software, but in a practical sense, trying to run the whole thing independently doesn’t seem quite there yet.

The things that are easy to do are use a domain name as an identifier and host your own personal data server. Owning your own data is nice in theory, but being able to take it with you isn’t that valuable when there’s nowhere to go.

Choosing an instance has gotta be culled.

The trouble with that is having many instances is the core trait that makes it a federated system.

There are certainly ways to de-emphasize that step during onboarding; an onboarding site that picks an instance from a curated set of general-purpose instances would be a good way. Bad ways include joinmastodon.org making mastodon.social the default, and join-lemmy.org asking a couple questions and presenting a list.

instances have no native ability to crawl other instances for communities or content

That’s not quite true. They don’t do it automatically or routinely, but a user can cause a server to read a post from another server by putting its URL into the search box. This can be useful for an end user to manually address a federation glitch.

Here’s a concrete example. I was trying to post a comment via lemmy.world, but lemmy.world sits behind Cloudflare, and Cloudflare flagged its content as potentially malicious. I then posted that comment via my own Mastodon server, but push federation to lemmy.world also failed, for the same reason. I could, however cause lemmy.world to pull the comment using the search.

Correct. Each server that shows the post to its users stores a copy of the post. It does not necessarily store attached media (IIRC Mastodon usually does and Lemmy usually hotlinks media).

They don’t duplicate the database in a technical sense, but when things go right, they each have a copy of the same post and comment text, and the same votes.

Zero. It seems like software is increasingly expecting to be deployed in a container though, so that probably won’t last forever.