If I have some spare compute, are there ways I can use it to help an existing fediverse instance?
from queerlilhayseed@piefed.blahaj.zone to selfhosted@lemmy.world on 21 May 07:17
https://piefed.blahaj.zone/c/selfhosted/p/774567/if-i-have-some-spare-compute-are-there-ways-i-can-use-it-to-help-an-existing-fediv

I don’t know a ton about the internals of federated systems, it’s been on my todo list for a while but it keeps getting pushed down by other things. But I still like that the fediverse exists and I’d like to pitch in, even if it’s only a few bucks of processor time / month.

Are there compute tasks that could be offloaded to a network of volunteers? Monitoring tools that could be run from outside the system? Something else I’m not thinking of?

#selfhosted

threaded - newest

squirrel@cake.kobel.fyi on 21 May 08:16 next collapse

You could run a PeerTube instance to mirror other people’s videos. The more mirrors, the more decentralized it gets. But it takes some manual curation of videos or instances you want to mirror.

queerlilhayseed@piefed.blahaj.zone on 21 May 07:25 collapse

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.

otter@lemmy.ca on 21 May 10:23 next collapse

That might be interesting! If you build on this idea, it would be cool to see ping times with location data, so instance operators can see what the performance is like with real world data. That was something we were concerned about when trying out different alternatives when leaving CloudFlare.

queerlilhayseed@piefed.blahaj.zone on 21 May 13:52 collapse

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.

Ardyvee@europe.pub on 21 May 12:21 collapse

I’ve been slowly setting up my own services locally, and one of the issues I quickly ran into was simple: what’s the point of running the uptime monitor in the same machine? Granted, it still serves is purposes, but…

So, if you do find a way to get something going, I think it’d be really cool. My biggest concern would be, though, on how to ensure you don’t accidentally build a DDoS network instead. A though issue I have no idea how to solve, but which should be solvable!

queerlilhayseed@piefed.blahaj.zone on 21 May 14:09 collapse

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.