There are good reasons for hiding a paper trail. Specifically in a self-hosting community, I understand operators wanting to hide their particular technical details from those who would wish to target them. This can be government agencies who like to arrest or kill dissidents, or freelance assholes who just like to attack queer infra where they can. I don’t think deleting posts is particularly effective, and the privacy concerns would be better addressed with a safe alt or a burner account, but I get why some people do it. Privacy is hard and when the stakes are high, people tend to over-secure rather than risk under-securing.

I have mixed feelings on post deletion. On the one hand, historical technical forum conversations are an incredibly valuable resource, and /c/selfhosted is a technical community. The value comes from having a history in context, and deleting part of the context damages the whole and makes the whole corpus less useful overall. It also allows incorrect or outdated information to fester when there isn’t a strong historical context that can be referenced.

On the other hand, people are right to be concerned about leaving large tracts of text available on the open internet, where it can be scraped, profiled, and possibly de-anonymized. I am very sympathetic to those who delete out of concerns for their own privacy, and I don’t know what a good solution is.

Maybe a compromise would be (on user “delete”) to leave the contents of a post intact, but simply delete the username from the post, and the post from the user’s history? Deletion on the fediverse is a bit of a sham anyway, and it would leave valuable discussions intact for other users.

That looks rad, gonna dig into that more. thanks!

controlling the total throughput to make sure smaller servers don’t get hammered is tricky. I think it’s one of those things that I will need to prototype and see in action before I really get a feel for it, but my basic idea is that users would pick a “home” server for their service, and that server will tell all its client services how frequently to poll and report. the home server tries to maintain a baseline across all its clients, so if it wants 1 ping every 15 seconds, and it currently has 100 live clients, it’s instructions to each client would be “ping once every 25 minutes”, and the clients would have some some randomizer that chooses a time within the 25 minute interval to ping, giving the server a roughly even distribution of pings over the interval.

server-to-server coordination would involve sharing their current number of live clients with other federated hosts, and setting frequency based on the total number of clients across all federated servers.

For example, suppose A and B are federated servers, where A can handle a lot of traffic and B is just a tiny instance. A might have 10x more clients than B, but all of A’s clients will ping A and B, and send reports to both. But if B wants to turn down the traffic, they can request fewer checks from A, who will push that request out to all its clients.

Yea, ping times is a great idea. I’ve been debating what kind of location data to include. I think it should default to “nothing” but if users feel comfortable sharing rough location (Country, Province/Region/State, City, nothing more granular than that) that should be configurable and would be nice data to see. I suspect a lot of fediverse users pipe all their traffic through a VPN, and if users feel comfortable reporting which VPN they use, the data could show performance across those networks too.

If non-VPN’d users felt comfortable sharing their ISP, that would be useful as well to see if services are degraded on a particular provider. It would also be a warning bell against ISPs censoring federated services. I don’t think that’s happening now, but it would be nice to have some independent verification.

An idea I’ve been kicking around is a sort of distributed down detector. Community members could download spin up a service that registers with a host’s statuspage service, which gives it a schedule for pinging monitored servers, and instructions for where to send the UP/DOWN results. Hosts can choose where to display the data (e.g. statuspage.blahaj.zone would display statuses for services on its own server as well as servers it federates with. If one service or server goes down, the outage would show up on federated services almost immediately. Intermittent outages would be easier to verify too.

Monitor runners should be able to manually choose which pages they monitor and where they send reports, but it wouldn’t be too hard to provide fediverse hosts custom images with their preferred pages and report destinations all configured, so users could just spin it up and let it run.

It’s from their website, but the main index page, not the /features page. It’s only the first half of the list on the index, but most of the items that I consider reaches (like listing “debian-based” and “debian package management” as separate top-line items) were in the first half.

They’re super common in corporate deployments, some larger companies will just give old (3-5 ish years) boxes away to employees when they do upgrades. I don’t have any running right now but I’ve gotten a few over the years that way. IMO their main virtue is that they’re easy to come by for cheap, but I don’t think I would seek one out specifically.

How do you like OMV? I’m about to redo my media storage to consolidate some services into a single host and it looks promising, but the amount of padding they felt they needed for their “Features” list gave me… pause.