| 22 May 2025 |
 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 |
| uep | examples welcome, I don't really have time to look into it right now | 06:24:19 |
| f0x | https://spec.matrix.org/v1.14/client-server-api/#mroomtombstone
devtools, room state, and either edit the existing one (will resend too) or create a new m.room.tombstone event, empty state_key, and content something like
{
"body": "This room has been replaced",
"replacement_room": "!newroom:example.org"
}
| 06:28:55 |
| uep | for some damn reason i can't even find the devtools setting. It used to be here, I'm sure | 06:38:48 |
| emily | I think you can /devtools | 06:39:32 |
| f0x | might also have to be enabled in labs/settings somewhere else, not entirely sure | 06:40:02 |
| emily | hmm I just sent a custom event here and nothing showed up | 06:40:14 |
