| 18 Jul 2025 |
 emily | though I wouldn't have expected them to put out that softening statement on the urgency if any arbitrary attacker can do that, hmm | 17:39:35 |
 f0x | huh, but the predecessor event_id being the tombstone wasn't even that important right, just happens to be what Synapse does since it can create chicken and egg at the same time | 17:40:00 |
 Cat | its important but the exact event ID is not. | 17:41:02 |
| Cat | as in feel free to pick any event ID you want people to get jumped to | 17:41:20 |
| Cat | And even then that feature is maby getting removed for v12 because they are being dumb with thinking their chicken and egg dance is actually needed. | 17:41:46 |
| f0x | right yeah | 17:41:54 |
| Cat | my powershell script when i do upgrade with notice | 17:42:11 |
| Cat | i literally use the event ID that the API returns as the value | 17:42:32 |
| emily | In reply to @charles:computer.surgery
I personally am interested in other protocols at this point (ones that exist or not?) | 17:42:38 |
 [0x4A6F] | Best thing is to also disallow changes to the tombstone room, otherwise nick changes and avatar changes might be annoying. | 17:42:42 |
| Cat | as in my notice message is the event ID i use. | 17:42:43 |
| Cat | Those cant be blocked but yes do send a PL event to block everything else. | 17:43:04 |
| f0x | yeah that makes sense, in the past I just used the last message event id in the old room | 17:43:06 |
| Cat | And that spam is why the removal is so dumb | 17:43:15 |
| Cat | because now we have to scroll thru it | 17:43:21 |
| Cat | instead of jumping past it. | 17:43:26 |
 Charles | not sure yet, i want to do some shopping around; maybe something i would be comfortable using exists already. i'm looking for something with, uh, worse availability guarantees, i guess | 17:44:17 |
| emily | I hope searching the old iteration of a room seamlessly isn't going to break | 17:44:18 |
| emily | except that's also a threat model if the room owner can continue spamming in the old one now huh | 17:44:36 |
| Cat | That was always a threat model | 17:44:51 |
| Cat | you cant block your own ability to send messages after the first PL event. | 17:45:04 |
| emily | In reply to @charles:computer.surgery
not sure yet, i want to do some shopping around; maybe something i would be comfortable using exists already. i'm looking for something with, uh, worse availability guarantees, i guess I love to sacrifice availability. it's my favourite thing to do | 17:45:13 |
| Cat | Thats the only time you can block your own ability to send an event in v11 and before. | 17:45:16 |
| Charles | yeah it's sad but i believe it is necessary | 17:45:42 |
| Charles | at least, for the particular use cases i am interested in, such as the use case nixos has with all of its rooms | 17:46:09 |
| emily | In reply to @cat:feline.support
Thats the only time you can block your own ability to send an event in v11 and before. so we can't even really have people tombstone their rooms to be adopted into the space | 17:46:37 |
| emily | because they can bypass moderation in search indefinitely far in the future? | 17:46:56 |
| emily | I guess search could ignore everything after the tombstone if it doesn't already? | 17:47:04 |
| Cat | Yes in theory that is a risk | 17:47:18 |
| Cat | but like its all tbh dependent on your threat model. | 17:47:32 |
