!DeRvyHqkqkIBbBtwsO:matrix.org

Homeserver Developers

180 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! 🥳87 Servers

Load older messages


SenderMessageTime
4 Aug 2021
@neilalexander:matrix.orgneilalexander
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:matrix.orgneilalexanderEspecially in rooms where state changes happen a lot (like bridged rooms!)17:01:44
@timokoesters:fachschaften.orgTimo ⚡️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
@timokoesters:fachschaften.orgTimo ⚡️
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
@timokoesters:fachschaften.orgTimo ⚡️(Well or you trust the auth chain response too, conduit currently does not)17:03:20
@neilalexander:matrix.orgneilalexanderright, but you're talking about compounding the problem17:03:22
@timokoesters:fachschaften.orgTimo ⚡️ * (Well or you trust the auth chain response too, conduit currently does not)17:03:36
@neilalexander:matrix.orgneilalexanderIt'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 OK17:04:22
@timokoesters:fachschaften.orgTimo ⚡️Hmm I wonder how much bigger the full chain would be than the recursive auth chain17:04:45
@neilalexander:matrix.orgneilalexanderWhat happens when you have lots of state changes in a room that aren't related to auth?17:04:46
@neilalexander:matrix.orgneilalexandere.g. someone comes along and wants to build a decentralised application on top of Matrix state 17:05:13
@timokoesters:fachschaften.orgTimo ⚡️How can a state event even end up in the DAG but not in the full auth chain of the current state17:06:53
@neilalexander:matrix.orgneilalexanderThe auth chain is only state events which are needed to auth another event17:07:09
@neilalexander:matrix.orgneilalexanderCustom state types don't get included in auth chains17:07:16
@neilalexander:matrix.orgneilalexanderBut they are part of the state sets17:07:27
@timokoesters:fachschaften.orgTimo ⚡️Hmm I see17:07:38
@neilalexander:matrix.orgneilalexanderWell, 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 ever17:08:32
@timokoesters:fachschaften.orgTimo ⚡️
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:matrix.orgneilalexander 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:matrix.orgneilalexander 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
@timokoesters:fachschaften.orgTimo ⚡️Well it's easy for an evil server to make up a bunch of invalid prev events17:10:11
@neilalexander:matrix.orgneilalexanderSo 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 impact17:10:59
@timokoesters:fachschaften.orgTimo ⚡️So why is synapse even asking for /state_ids on the prev events instead of the main event17:11:12
@neilalexander:matrix.orgneilalexander 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
@timokoesters:fachschaften.orgTimo ⚡️Trust is not really an argument as an evil server can just choose their own prev events17:13:14
@neilalexander:matrix.orgneilalexander
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:matrix.orgneilalexanderSomething 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:matrix.orgneilalexander If it does then it still has to win in other ways and satisfy a tie break if not 17:14:45
@neilalexander:matrix.orgneilalexanderSo 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 extremities17:15:32
@diakrisis:matrix.org@diakrisis:matrix.org left the room.17:38:14

There are no newer messages yet.


Back to Room List