| 17 Mar 2020 |
 @neilalexander:matrix.org | I'm going to nolint:gocyclo that SQLite StoreEvent for now and worry about breaking out the new room vs existing room path later | 14:36:32 |
 Kegan | sgtm | 14:38:55 |
| @neilalexander:matrix.org | Is the assumption that using /_matrix/federation/v1/invite instead of /_matrix/federation/v2/invite would always be for a v1 room, since there is no other field that suggests otherwise? | 16:24:29 |
| @neilalexander:matrix.org | The spec states that it should assume v1 or v2 but not sure how you are supposed to know that until receiving the m.room.create state event | 16:25:14 |
 TravisR | I have a feeling the spec is missing docs on the parameter for a /v2 invite | 16:28:01 |
| TravisR | for a room_version parameter* | 16:28:18 |
| @neilalexander:matrix.org | The v2 endpoint shows the room_version field, which is fine | 16:29:05 |
| @neilalexander:matrix.org | But it feels a bit messy to assume that v1's lack of room_version could be one or other of room version 1 or 2 | 16:29:55 |
| TravisR | ah, that's because of a legacy thing: we had v1 and v2 already then needed to do something for v3 rooms because of the event ID format change. | 16:32:00 |
| TravisR | Authorization should still work the same for v1 and v2 | 16:32:15 |
| TravisR | Also one day we'll deprecate /v1 and tell peopel to use /v2 | 16:32:40 |
| TravisR | * Also one day we'll deprecate /v1 and tell people to use /v2 | 16:33:32 |
| @neilalexander:matrix.org | I'll maybe just suggest that Dendrite removes the implementation of /v1 then in favour of /v2 | 16:34:25 |
| TravisR | oh: the other thing is that invites to a server that's already in a room shows up over /send not /invite | 16:35:27 |
| TravisR | * oh: the other thing is that invites to a server that's already in a room show up over /send not /invite | 16:35:34 |
| TravisR | I think? | 16:35:52 |
| TravisR | no, that doesn't make sense because both servers need to sign it | 16:36:08 |
| TravisR | nevermind. | 16:36:12 |
| TravisR | (but they would know the room version) | 16:36:21 |
| 18 Mar 2020 |
|  Bruno joined the room. | 11:52:53 |
|  neilalexander (NV) joined the room. | 15:17:36 |
| 19 Mar 2020 |
| @neilalexander:matrix.org | For /send_join | 10:19:34 |
| @neilalexander:matrix.org | The spec is unclear, should state be resolved state (as in, no duplicate state-key tuples) or can it contain duplicates? | 10:19:52 |
| @neilalexander:matrix.org | My feeling is it should be the former | 10:20:00 |
| @neilalexander:matrix.org | * The spec is unclear, should state in the response be resolved state (as in, no duplicate state-key tuples) or can it contain duplicates? | 10:21:12 |
 richvdh | yeah it should be the resolved state of the room at the join event | 10:28:20 |
| richvdh | the joining server lacks enough info to resolve the state | 10:28:31 |
| @neilalexander:matrix.org | Alright, dendrite can currently leak duplicate state-keys which looks bad, so I will fix that | 10:29:00 |
| @neilalexander:matrix.org | Which brings me onto another question of why federated room joins aren't a three-way handshake | 10:29:09 |
| @neilalexander:matrix.org | As right now it's possible to make_join fine, then send_join, then the joined server is happy and shows the user as now in the room but the joining server is unhappy about something in the state response and doesn't show as joined | 10:29:50 |
