| 22 May 2025 |
 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 (burnt out) 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 |
| uep | well, not in the room that's been tombstoned, because there's no input box :facepal; | 06:40:21 |
| emily | can you have secret conversations nobody using normal clients can see or do homeservers filter them out? | 06:40:24 |
| uep | * | 06:40:28 |
| uep | In reply to @f0x:pixie.town
might also have to be enabled in labs/settings somewhere else, not entirely sure yeah that's what i can't find. | 06:40:52 |
| emily | /devtools itself has a switch | 06:41:08 |
| emily | I don't know where the tools show up in the UI if you toggle it on | 06:41:17 |
| f0x | In reply to @uep:matrix.org
well, not in the room that's been tombstoned, because there's no input box :facepal; oh right lol, then you'd need to send it directly through the API, I can help with that later | 06:41:21 |
| emily | oh, bottom-left cog | 06:41:22 |
| emily | so /devtools → switch it on → go to room → bottom-left cog | 06:41:30 |
| emily | so easy! | 06:41:41 |
| uep | yeah, looks like they moved the "developer mode" toggle into this panel | 06:42:15 |
| f0x | In reply to @emilazy:matrix.org
can you have secret conversations nobody using normal clients can see or do homeservers filter them out? yes, sending new/custom event types is an explicit goal for Matrix. Element can be configure to always show (unknown) events in the timeline stil though | 06:42:17 |
| emily | right. I think I used to have that turned on | 06:42:29 |
| emily | but it seems like an abuse vector. you can smuggle illegal content into rooms that the mods probably won't see? | 06:42:42 |
| f0x | In reply to @emilazy:matrix.org
but it seems like an abuse vector. you can smuggle illegal content into rooms that the mods probably won't see? not sure how much you'd gain by doing that instead of just creating a new room | 06:43:48 |
