| 16 Jul 2025 |
 c-x-berger |
- you're welcome
- i highly recommend the rest of James Mickens' writings for USENIX if you liked that one https://mickens.seas.harvard.edu/wisdom-james-mickens (scroll to "USENIX articles")
| 23:25:27 |
 f0x | In reply to @c-x-berger:boiler.social
http://scholar.harvard.edu/files/mickens/files/thesaddestmoment.pdf really nice :D | 23:33:25 |
| 17 Jul 2025 |
|  mannp joined the room. | 11:31:31 |
| 18 Jul 2025 |
|  Nyxvectar Yan changed their display name from Nyxvectar to Nyxvectar Yan. | 09:55:17 |
|  Mirage joined the room. | 14:22:39 |
 Cat | So considering the whole v12 situation i assume that the nix procedure for adding rooms to the space has to be rewritten and restructured.
Procedure im talking about is found at https://github.com/NixOS/moderation/blob/main/matrix/adding-rooms.md | 17:00:38 |
| Cat | essentially v12 room creators have infinite power. | 17:00:59 |
 emily | is there no way for them to demote themselves ever? | 17:01:14 |
| Cat | so that breaks this handover process meaning your adoption process likely needs to change to using a manual room upgrade to adopt existing rooms. | 17:01:24 |
| Cat | Yes that power is permanent. | 17:01:38 |
| Cat | and cant be modified post creation. | 17:01:45 |
| emily | wtf | 17:01:48 |
| emily | that seems like a terrible flaw | 17:01:57 |
| emily | I guess if upgrades can override it that's not the end of the world | 17:02:10 |
| Cat | The community theory is that its a fix for that State Res fixes in v12 are not perfect. | 17:02:26 |
| emily | could room creators "undo a tombstone" in that case? | 17:02:29 |
| Cat | as in the state res fixes in v12 likely can fail and reset anyways so they made the room creators have infinite power so they can fix the state back to proper. | 17:03:17 |
| emily | ...so this means that after all that talk about whether Matrix's sacrifices to have rooms not controlled by one homeserver are worth it, now rooms are going to be controlled by one nameserver | 17:03:22 |
| Cat | They are still going to have decentralised control its just a set of master servers can overrule it. | 17:03:53 |
| Cat | as you can define additional creators. | 17:03:59 |
| Cat | we dont know all the details as its still under security embargo. | 17:04:20 |
| Cat | We dont actually know. | 17:04:36 |
| Cat | Manual ones can definetively still do that. | 17:04:57 |
| Cat | Even tho they are being silly attempting to fuck with room upgrades even more due to that the new room ID format will break the Synapse chicken and Egg dance of creating the room ID for the next itteration of the room before the create event it self so that the create event can refer to the tombstone that points to the new room. | 17:05:45 |
| Cat | That stupidly complex dance i just described is just bullshit that Synapse does that is not needed. | 17:06:20 |
| emily | it seems worrying if a room creator can go inactive and then go nuts or get compromised years later and potentially stop even the room getting replaced | 17:07:47 |
| emily | I guess you just really want a designated admin account for every room at this point | 17:08:01 |
| f0x | In reply to @emilazy:matrix.org
could room creators "undo a tombstone" in that case? couldn't you always just redact/sorta ignore a tombstone event? | 17:12:06 |
| emily | yeah that's what I fear | 17:13:02 |
| emily | so you really need to tombstone a room in advance of your BDFL going rogue | 17:13:21 |
