| 22 May 2025 |
Zhaofeng Li | and we probably should have a list of them written down somewhere | 03:59:52 |
uep | well, fractal lets me post in it if i join by the id | 04:03:30 |
Zhaofeng Li | yeah, tombstones and room upgrades just feel like cheap magic tricks | 04:04:10 |
Zhaofeng Li | the rooms still exist, and people can still spam/post illegal content/etc | 04:04:52 |
uep | we can shut down rooms | 04:06:51 |
uep | but it only stops processing of events for them on the local homeserver | 04:07:06 |
uep | even more desync fun: presumably as part of migration, something has set the post permission to pl 50. But of course that's also out of sync and clearly some people are still posting | 04:08:17 |
Zhaofeng Li | "Posting messages" in the old #users room is set to the default power level for me | 04:13:26 |
Zhaofeng Li | but if it isn't on your end and your homeserver still accepted it, wow | 04:13:38 |
Zhaofeng Li | hopefully matrix isn't completely broken moderation-wise | 04:13:54 |
uep | oh even weirder | 04:14:02 |
uep | it shows as 0 in element and 50 in fractal. | 04:14:13 |
Zhaofeng Li | so how does retrieving current room state even work? | 04:16:48 |
uep | /shrug no idea | 04:17:15 |
Zhaofeng Li | I imagine the homeserver should keep track of the "current" state, but if it doesn't and the client needs to look through all events... ??? | 04:17:31 |
Zhaofeng Li | hopefully that's not the case, but nothing surprises me at this point | 04:17:48 |
uep | anyway, i set the permission again and hopefully this time it sticks for whoever's left? | 04:18:08 |
emily | it worked for me on matrix.org | 04:26:09 |
emily | cheers | 04:26:15 |
uep | I have no idea if it's possible to resend or republish the tombstone event, or even makes sense to try. This may have to do. | 04:27:00 |
emily | i think it's technologically possible | 04:27:15 |
emily | and worth trying because it fixes search | 04:27:22 |
emily | but maybe not UI-eaay | 04:27:29 |
emily | *easy | 04:27:32 |
Zhaofeng Li | you should be able to send tombstones with the dev tool I think | 04:33:59 |
| KFears (they/them) changed their display name from KFears (burning out) to KFears (burnt out). | 05:32:51 |
f0x | In reply to @zhaofeng:zhaofeng.li maybe it's just hidden client-side (I'm still in the old room, despite it not being on the room list in element desktop) yeah, it's purposely kept around so you can still go back to see it's history. The new room's create event should also have a predecessor field pointing back to the old room (though that's not a hard requirement) | 06:18:17 |
f0x | In reply to @zhaofeng:zhaofeng.li I imagine the homeserver should keep track of the "current" state, but if it doesn't and the client needs to look through all events... ??? those are aggregated server-side, but kinda depends which api routes the clients use | 06:19:30 |
f0x | and the old room being so broken means state changes might not even be accepted by other homeservers | 06:20:26 |
f0x | In reply to @uep:matrix.org I have no idea if it's possible to resend or republish the tombstone event, or even makes sense to try. This may have to do. yeah, you could send another tombstone event, manually through devtools/api so it still points to the same new room. no idea if it has a better chance of arriving, but also wouldn't hurt | 06:22:42 |