It’s likely to increase performance by running the CPU cooler when idle and better mapping thermal behavior to performace, so it’s an improvement for things like the steam deck or gaming as well.

Once you add things to the AllowList, only things in the AllowList federate. You probably want to use empty AllowList + populate BlockList as needed.

I expect that should be fine, but there’s a URL signature scheme that is apparently involved, I’m worried that should I turn up a new instance, it won’t federate with e.g. mastodon.social

I haven’t used it yet, but I wrote a small service to combine webfinger from subdomains into a primary domain, and ended up abandoning it. You’d need to handle more than just the webfinger stuff, and be able to route activity pubs as well, and I’m still learning about the protocol enough to see if this is possible. I think the best case is that locally you might be name@someinstance.example.com, but would federate as name@example.com, and webfinger/mentions would work for that, and something at example.com would route activity pubs appropriately to the “real” hosts with name rewriting.

At the simplest I feel a chrome extension or similar would be straightforward. A more native flow doing some sort of faux login/modal that could subscribe on the primary host would be better.

The backend especially is not too demanding (thanks to using a compiled binary via Rust). The database demands probably scale, but postgres scaling is relatively well understood. I think right now the least scalable parts look like the frontend node and websocket stuff, but that can be improved. I’m not sure how I feel about Activity Pub protocol wise, it feels pretty chatty, so transit scalability might be something else to consider.