Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@marlies Yep, they've had that one for quite a while already! I think at least a year.

@marlies Is this the Action one, or are they available for this price elsewhere now as well?

@eloy Which one?

@eloy "Perpetual refactoring" is the opposite of that

(Note: you are allowed to exclude medical plastic waste from the calculations, since this usually needs to be handled specially.)

@eloy People have tried!

(And failed)

@eloy I think this is unrealistic, to be honest - in the time I have used the web (and that's a *long* time), 404 *has never* been a "pure not found" status code. Practically nobody makes the distinction between 404 and 410, for example, and given that you often also want to hide *whether* you are hiding resources, putting this under 404 (instead of using a dedicated status code) would be the correct thing to do.

Keep in mind that the purpose of technology is to solve people's problems, not the other way around. Something might be the 'correct' thing in a hypothetical vacuum, but if it doesn't actually match how people want or need to use it, then it's not actually 'correct' for any meaningful interpretation of the term.

@kescher Right, so the main problem why Matrix can't (literally can't!) do that is because the entire concept of decentralized rooms relies on all participating servers having an identical view of the rooms internally. They may choose to (not) show things to users, but they must have an identical event graph. If one participant blocks another server's events entirely, their room state diverges and the room breaks for them. That can't be designed around, at least with any decentralization model I know about.

The only way I know of to defederate servers anyway (on a server level, not a room level) is to basically get rid of the 'decentralized' property of rooms, and making them more like MUCs in XMPP, where a channel exists on a specific authoritative server, and if that server ever goes down, the channel is gone. This has historically gone very poorly because people's entire communities just suddenly disappear with no warning, there's no resilience in the system at all.

There are some workarounds in decentralized rooms like "accept their events but only store a redacted version locally, never the contents" that *could* work if the protocol is designed for it, but that won't necessarily be sufficient in 100% of situations, hence why I'm trying to understand the specific circumstances in which defederation might be wanted, to see if such an approach could work here, and make sure I'm not overlooking any details.

@eloy Okay, but how isn't this already the case for 404 errors today?

@eloy Okay, but putting aside abstract notions of 'correct' for a moment, how would this technically improve things?

Because as far as I can tell, you'd just be introducing a new HTTP status code that everyone now needs to *also* support and treat like a 404, without adding any new functionality (because it's still just "not found"), so then what is the practical purpose of the new ambiguous status code?

@kescher Re: purging, do you mean in the sense of "users automatically leave a room if their instance has been unreachable for X time", or something else?

Re: defederating instances, I assume you mean on a server level rather than on a room ACL level? For what reason(s) would they be defederated? (As it's a technical impossibility to literally defederate without breaking rooms, and workarounds are potentially viable but need a more precise problem description to get right)

Re: banning individual known-bad users, I assume this goes beyond room bans, and you (conceptually) mean something along the lines of "defederating between your homeserver and a particular remote user" instead?

@eloy The general recommendation is to just use 404 for that, making it deliberately ambiguous - because any HTTP code that reveals that something is being intentionally hidden (as opposed to not existing) would defeat the point of hiding its existence