| 4 Aug 2021 |
 neilalexander | In reply to @timokoesters:fachschaften.org
I want to get rid of /state_ids completely by always letting server fetch the full state chain, which is only really possible if the state events build a DAG on their own We already see how heavy just pulling a full auth chain can be, it's not great to have to rely on possibly needing to know all state that ever changed in a room | 17:01:19 |
| neilalexander | Especially in rooms where state changes happen a lot (like bridged rooms!) | 17:01:44 |
 Timo ⚡️ | Hmm... one reason I want to change it is that you can't really trust /state_ids. Fetching the full chain is the safest route. | 17:02:39 |
| Timo ⚡️ | In reply to @neilalexander:matrix.org
Especially in rooms where state changes happen a lot (like bridged rooms!) You need to fetch their auth chain anyway for stateres | 17:03:04 |
| Timo ⚡️ | (Well or you trust the auth chain response too, conduit currently does not) | 17:03:20 |
| neilalexander | right, but you're talking about compounding the problem | 17:03:22 |
| Timo ⚡️ | * (Well or you trust the auth chain response too, conduit currently does not) | 17:03:36 |
| neilalexander | It's a core premise in a Matrix room that you can survive having gaps, and the gaps between events in the auth chain might be huge and that's OK | 17:04:22 |
| Timo ⚡️ | Hmm I wonder how much bigger the full chain would be than the recursive auth chain | 17:04:45 |
| neilalexander | What happens when you have lots of state changes in a room that aren't related to auth? | 17:04:46 |
| neilalexander | e.g. someone comes along and wants to build a decentralised application on top of Matrix state | 17:05:13 |
| Timo ⚡️ | How can a state event even end up in the DAG but not in the full auth chain of the current state | 17:06:53 |
| neilalexander | The auth chain is only state events which are needed to auth another event | 17:07:09 |
| neilalexander | Custom state types don't get included in auth chains | 17:07:16 |
| neilalexander | But they are part of the state sets | 17:07:27 |
| Timo ⚡️ | Hmm I see | 17:07:38 |
| neilalexander | Well, even some specced state events like room name, avatar, topic, those aren't required for auth and won't appear in auth chains either, but you are proposing that the server needs to know every time any state event changed ever | 17:08:32 |
| Timo ⚡️ | In reply to @timokoesters:fachschaften.org
Can someone tell me again how synapse/dendrite figure out the state at an event? IIRC they don't just call /state_ids on the event, instead they call /state_ids on all unknown prev_events and then do stateres to get the state? And they somehow make sure that one of those prev events is from a state we confirmed? Alright, then let's come back to my original question:^ | 17:08:36 |
| neilalexander | The only time it's really a problem to rely on /state_ids entirely is if an event comes in when you know none of the prev events. Otherwise if you know at least one of the prev events then you have a trusted state set anyway | 17:09:36 |
| neilalexander | But I guess relying on /state_ids isn't entirely avoidable and probably it's best just to be sure you aren't asking the same server each time if you can avoid it | 17:10:04 |
| Timo ⚡️ | Well it's easy for an evil server to make up a bunch of invalid prev events | 17:10:11 |
| neilalexander | So I guess the worst case there is that you might get an evil event added to your forward extremities, alongside a bunch of events that have good state, and they would still have to "win" state resolution in order to have an impact | 17:10:59 |
| Timo ⚡️ | So why is synapse even asking for /state_ids on the prev events instead of the main event | 17:11:12 |
| neilalexander | Because if you ask for /state_ids on the main event, you are trusting the state calculation of a single server, whereas if you ask for /state_ids from different servers for the prev events you can a) capture gaps between the prev events and b) have more opportunity to ask multiple servers and c) trust your own state calculation if you do have trustworthy state sets locally already | 17:12:25 |
| Timo ⚡️ | Trust is not really an argument as an evil server can just choose their own prev events | 17:13:14 |
| neilalexander | In reply to @neilalexander:matrix.org
So I guess the worst case there is that you might get an evil event added to your forward extremities, alongside a bunch of events that have good state, and they would still have to "win" state resolution in order to have an impact ^ | 17:13:25 |
| neilalexander | Something that has obviously fake auth events isn't likely to win state res because it'll probably get weeded out quite early by following the power level mainline | 17:14:21 |
| neilalexander | If it does then it still has to win in other ways and satisfy a tie break if not | 17:14:45 |
| neilalexander | So yeah, maybe you get some untrustworthy state in your "state before" the event, but the chance of it corrupting your current room state is quite low if you already have good state sets from existing extremities | 17:15:32 |
|  @diakrisis:matrix.org left the room. | 17:38:14 |
