| 15 May 2025 |
K900 | Also if you're going to switch to a public Matrix server instance maybe have it not be m.org | 13:59:18 |
K900 | In reply to @dgrig:erethon.com (This is a bit pedantic, but it's good that people are informed. Leaving rooms in matrix isn't enough from a moderation perspective. Because if they ever rejoin they'll have the power level they had when they left unless they were demoted. And if the domain ever expires, anyone can take over the domain and recreate any users.) I'll demote them via mjolnir after | 13:59:47 |
qbit | any recommended other instances? it all feels like a crapshoot to me | 14:00:16 |
@emma:rory.gay | matrix.org, good luck... | 14:00:22 |
qbit | i see gut wrenching awful coming from every public instance I know of | 14:01:22 |
K900 | I can't personally vouch for any so I will refrain | 14:01:56 |
@emma:rory.gay | theres tooling for that out there that doesnt work on matrix.org :) | 14:01:59 |
qbit | my thing is i don't want to have to deal with cleanup from attacked rooms every few months (i know there is tooling to do it - but i don't want to spend my time dealing with it) | 14:04:22 |
@emma:rory.gay | configure synapse auto automatically remove remote media after 4h, and to auto delete rooms with no users | 14:07:52 |
qbit | easier to just not run it :P | 14:08:18 |
@emma:rory.gay | and for automatically rejecting invites practically instantly, if youre the only user: https://cgit.rory.gay/matrix/tools/MatrixAntiDmSpam.git/about/ | 14:08:40 |
qbit | [easier to just not run it intensifies] | 14:09:13 |
@emma:rory.gay | matrix.org is a bad time and has practically no protections (yet) | 14:09:32 |
@emma:rory.gay | MADS does work with matrix.org, but that's about all you can do there | 14:10:11 |
@emma:rory.gay | or should, it's untested | 14:10:17 |
qbit | ok, i left the go+nix room | 14:11:29 |
@emma:rory.gay | even if you just go with matrix.org, if you just dont want to deal with it, youre going to have to deal with running a bot on your account anyways 24/7 | 14:12:28 |
qbit | wut? | 14:13:52 |
qbit | why? | 14:13:57 |
@emma:rory.gay | youre still going to receive those invites, and youre still going to have to clean up those stuff from your clients' caches | 14:14:39 |
qbit | my solution for that is to use a crippled client | 14:15:04 |
qbit | that doesn't show any images | 14:15:10 |
@emma:rory.gay | that works too i guess | 14:15:25 |
f0x | In reply to @dgrig:erethon.com (This is a bit pedantic, but it's good that people are informed. Leaving rooms in matrix isn't enough from a moderation perspective. Because if they ever rejoin they'll have the power level they had when they left unless they were demoted. And if the domain ever expires, anyone can take over the domain and recreate any users.) no? federation relies on request signatures, and someone taking over the domain won't have access to your homeserver's key | 17:59:08 |
@saiko:knifepoint.net | In reply to @f0x:pixie.town no? federation relies on request signatures, and someone taking over the domain won't have access to your homeserver's key what happens if the key for a homeserver changes, for example in this case? | 18:03:22 |
@emma:rory.gay | over time homeservers will accept the new key | 18:04:33 |
@emma:rory.gay | at most in 90 days | 18:04:43 |
dgrig | When my homeserver died I was back and federating within 12 hours or so. It would have been the same case if the domain was taken over.
The spec mentions this https://spec.matrix.org/v1.14/server-server-api/#security-considerations
| 18:05:46 |
@saiko:knifepoint.net | ah cool, good to know! | 18:05:53 |
@saiko:knifepoint.net | so the domain isn’t “bricked” if you lose the key, that would suck | 18:06:22 |