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

doingmypart.jpg I can have my own 502s as a treat

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.

You’ll only get new comments after federation started working, it’s never retroactive.

Another problem with “everyone just joins lemmy.ml” is that eventually it becomes the weakest link, and other instances will either accept the hordes for the volume/content, or be forced to isolate. It’s much better if we hide the cost of decentralization from users but also keep the decentralization as much as possible. It’s not an easy problem, but it’s worth solving.

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.