| 9 Jan 2020 |
 Matthew | but if you MSC it i suspect that would drop out quite quickly | 18:09:04 |
 Sorunome | https://github.com/matrix-org/matrix-doc/pull/2403 🎉 | 18:59:17 |
| Sorunome | Also........this is bridge development next level. The current complaints of mx-puppet-bridge concerning non-1:1-channels can easily mitigated with this implemented XD | 19:02:35 |
 mscbot | [MSC2403] "MSC2403: Add "knock" feature" has been created: https://github.com/matrix-org/matrix-doc/pull/2403 | 19:02:44 |
 tulir | Sorunome: I think it's federation/v1, since the endpoint didn't exist before so it's the first version of the endpoint | 19:06:58 |
| Sorunome | oki, thanks! | 19:07:17 |
 TravisR | it would be /v2 because it's federation API v2 | 19:07:45 |
| TravisR | the versioning scheme is confusing | 19:07:58 |
| Sorunome | oookay, /v2 it is, then updates MSC | 19:08:09 |
| tulir | In reply to @travis:t2l.io
it would be /v2 because it's federation API v2 wait what | 19:10:43 |
| TravisR | yea, the whole API ratchets when we change the version number, but to avoid problems with readability we don't duplicate unchanged endpoints. | 19:11:48 |
| TravisR | Though in some cases it's unavoidable: see the identity server spec | 19:12:22 |
| TravisR | wait, did we ratchet the server spec yet? | 19:14:11 |
| tulir | then why is it /v2 instead of /r1 | 19:14:25 |
| TravisR | yes we did, there's some stuff in there | 19:14:31 |
| Sorunome | invite has both a v1 and a v2 endpoint | 19:14:48 |
|  Philip White joined the room. | 19:15:05 |
| TravisR | In reply to @tulir:maunium.net
then why is it /v2 instead of /r1 the rX system has a problem of needing to bump the entire version of everything because it's directly tied to the spec version. | 19:16:07 |
| TravisR | Positions are a bit divided in the team, but about half of us think that the rX system was a mistake | 19:16:28 |
| TravisR | though now that I think about it I might be wrong anyways | 19:17:37 |
| * TravisR researches | 19:17:41 |
| tulir | In reply to @travis:t2l.io
the rX system has a problem of needing to bump the entire version of everything because it's directly tied to the spec version. don't you still need to basically bump the version of everything if any breaking endpoint change increments everything? | 19:18:38 |
| TravisR | yes, but with the vX system we can avoid having to duplicate every single endpoint. With rX we have to duplicate the entire spec. | 19:19:34 |
| TravisR | for the vX endpoints there's still a rX version number, but instead of specifying the version in the endpoint to use it defines the collection of endpoints | 19:20:17 |
| TravisR | Like how Matrix 1.0 is just references to specific spec versions, and 1.1 would be the same. | 19:20:37 |
| TravisR | it would definitely be a fun exercise to actually ratchet the version of the client-server API though. Would really put the client and server version checks to work :p | 19:22:54 |
| tulir | In reply to @travis:t2l.io
yes, but with the vX system we can avoid having to duplicate every single endpoint. With rX we have to duplicate the entire spec. what if you had r0.1 instead of r0? | 19:23:45 |
| TravisR | it would be a similar problem considering we're on r0.6 now | 19:24:07 |
| TravisR | I can't actually find any documentation on how the vX system is supposed to work, so it might be something for the MSC to work out. | 19:24:58 |
| TravisR | It could easily be an "endpoint version", or it could be the iteration in which it was introduced. | 19:25:19 |
