 | Homeserver Developers | 377 Members |
| If you are building a homeserver, or you want to talk to other people that build homeservers, then this is the place for you! 🥳 | 143 Servers |
| Homeserver Developers | 377 Members |
| If you are building a homeserver, or you want to talk to other people that build homeservers, then this is the place for you! 🥳 | 143 Servers |
| Sender | Message | Time |
|---|---|---|
| 19 Sep 2024 | ||
 neilalexander | In reply to @tulir:maunium.netThat's not the point, the problem is before we get to event auth | 09:10:19 |
| neilalexander | The problem is deciding whether or not we can understand and interpret the event enough to do anything with it, before event auth happens | 09:11:02 |
 NotHSDevNico | Arguably the create event is validated during the join, so it wouldn't cause a room split if you add extra validation, so it doesn't have harmful sideeffects to validate it there, apart from that you can't join rooms, that violate the spec. Which sounds sensible to me, most Matrix rooms are way too sloppy | 09:12:41 |
| neilalexander | And my point is that the redaction algorithm is not a magical fix, because all that does is tell us to keep certain keys and throw away others. It doesn't guarantee those keys we kept will be any more valid than before, or what to do with them if they aren't | 09:12:43 |
| neilalexander | In reply to @deepbluev7:neko.devIndeed, broken rooms are broken rooms, they should just be really broken so that people stop expecting broken rooms to work | 09:13:32 |
 Kegan | In reply to @neilalexander:dendrite.matrix.orgI agree with this. The event was malformed. Plz send correct events. | 09:14:54 |
 Gnuxie 💜🐝 | In reply to @travis:t2l.ioIs there anywhere in the spec makes the recommendation to redact authorization events when they fall to validate? Because that also has other implications for protected fields. | 09:16:16 |
| Gnuxie 💜🐝 | * Is there anywhere in the spec makes the recommendation to redact authorization events when they fall to validate? Because taken literally that also has other implications for protected fields. | 09:17:16 |
| Gnuxie 💜🐝 | * Is there anywhere the spec makes the recommendation to redact authorization events when they fall to validate? Because taken literally that also has other implications for protected fields. | 09:17:43 |
 richvdh | In reply to @kegan:matrix.orgIsn't this https://github.com/matrix-org/matrix-spec-proposals/pull/2801 writ large? | 09:19:18 |
| NotHSDevNico | In reply to @richvdh:sw1v.orgNo, this is about some servers accepting events that don't follow the spec, which in turn makes them unusable by clients. It doesn't matter if those events are trusted or not, they shouldn't end up in rooms unless they are sent by servers trying to do bad stuff | 09:21:54 |
| NotHSDevNico | The predecessor field in that room is broken, it can't be used by clients to paginate to the previous room unless they implement off-spec behaviour to fix that | 09:23:28 |
 Cat | Its not broken. its literally invalid. | 09:23:40 |
| Gnuxie 💜🐝 | Servers doing bad stuff like break the room. I think the argument to redact the event is valid, but you have to double down and make that explicit in the spec. | 09:23:53 |
| NotHSDevNico | In reply to @cat:feline.supportThat's needlessly pedantic, it is broken because it doesn't do what it should do. | 09:24:11 |
| Cat | Being broken would be missing the event ID field. But that is literally invalid as its not remotely looking like the correct data. | 09:24:12 |
| neilalexander | In reply to @gnu_ponut:matrix.orgIt wouldn't have helped in this case: the redaction algorithm is a no-op for create events. And it still doesn't prescribe anything about the types of fields, it just says "keep these keys and throw away everything else" | 09:24:26 |
| neilalexander | You can keep fields that the redaction algorithm says you should keep and they could still be the wrong type | 09:24:52 |
| Gnuxie 💜🐝 | In reply to @neilalexander:dendrite.matrix.orgAhh, that makes sense | 09:25:25 |
| NotHSDevNico | Seems like the create event also broke showing the room version properly in Nheko... :D | 09:26:01 |
 xiretza | is there any place in the spec that tells you to redact things in an attempt to fix invalid data? where is this idea coming from? | 09:26:33 |
| Gnuxie 💜🐝 | In reply to @neilalexander:dendrite.matrix.orgI guess for other events you could revert to wherever behaviour is specified for when the event is missing, but that's sketchy. | 09:27:05 |
| NotHSDevNico | In reply to @xiretza:xiretza.xyzEvents are redacted before authing them, afaik | 09:27:06 |
| Gnuxie 💜🐝 | In reply to @xiretza:xiretza.xyzSomeone said earlier that this is where servers should do | 09:27:45 |
| NotHSDevNico | Or at least it has to yield the same result | 09:27:53 |
| Gnuxie 💜🐝 | * Someone said earlier that this is what servers should do. | 09:28:22 |
| neilalexander | In reply to @xiretza:xiretza.xyzThe spec doesn't say to do this, no, because it's not safe to do. The hash and signature checks are on the redacted event, but any key that we are supposed to keep could still be invalid but have been hashed/signed anyway | 09:28:28 |
| xiretza | In reply to @gnu_ponut:matrix.orgyes, that's why I'm asking where in the spec this is coming from | 09:29:42 |
| Kegan | In reply to @richvdh:sw1v.org This MSC doesn't seem to touch on the main thing here. We currently use key names to namespace everything, that's why we have unstable prefixes. It is entirely reasonable to enforce the types of values for known keys. In this case the type was invalid, so it is correctly rejected. This preserves extensibility by ignoring unknown keys | 09:31:25 |
| Kegan | Your point on "server that doesn't know of key X can't validate it so clients need to check anyway" is valid, but for servers this should not be an issue, the validation requirements are different imo | 09:32:34 |