| 17 Mar 2020 |
 @neilalexander:matrix.org | It should be the latter | 14:32:00 |
| @neilalexander:matrix.org | So if we're only getting the auth chain for the join event and not for the rest of room state then that is a bug | 14:32:15 |
 Kegan | fab, thanks | 14:32:42 |
| @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 |
