kosmo

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

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

pineapple's comment has the right location line

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.

For me closely monitoring the reverse proxy logs and the HTTP status therein solved it. Fixing the /inbox routing also fixed the "Susbscription pending" problem for me.

I'm not a frontend dev, and I feel like CORS stuff comes into play here, but it should be possible to do something like the "Sign In With Facebook" or "Pay with Paypal" type of redirect after asking the user for their host. At very worst it should be possible to have Instance B's backend send a call to Instance A after the user provides it with the name of the other instance, but you need to be careful about validating the legitimacy of the request in that case. There's a lot of room for better cryptography/signatures in activitypub I'd imagine that could help.

If Twitter were a store, people would have no problem boycotting it. I think the mentality change that is necessary for the 2020s is that you have a choice where to "spend" your generated content, just like you have a choice where to spend your money (ostensibly at least: ISPs, privatized utilities need not apply).

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.