| 14 Jan 2020 |
 anoa | In reply to @sorunome:sorunome.de
(.python3) sorunome@sorunome-desktop famedly/synapse $ git pull origin matrix-org-hostfixes
fatal: couldn't find remote ref matrix-org-hostfixes
whaaaaa
you typo'd hotfixes here | 15:06:31 |
| anoa | the branch is matrix-org-hotfixes | 15:06:41 |
 Sorunome | just noticed, thanks | 15:06:41 |
| Sorunome | okay, also works on that branch | 15:07:31 |
| Sorunome | so it is something with the other setup stuffs, then | 15:07:42 |
| anoa | yeah, only thing I can think here is the session is getting mangled somehow. The request parameters are coming in fine, and google is giving us back a 200 for the recaptcha. | 15:07:48 |
| * anoa tries to put in some logging | 15:08:03 |
| anoa | So it turns out the issue is due to this failing with workers. The session dict contains your sessions on one worker, while this auth stuff exists on a separate worker, and thus one editing it doesn't affect the other. | 15:32:49 |
| anoa | Thankfully it looks like the fix is fairly easy, but I need to write some stuff up and fix the worker docs, and then fix it on matrix.org | 15:33:13 |
| anoa | And the latter will probably not happen today | 15:33:19 |
| anoa | (as it's getting late for an architecture rejig) | 15:33:33 |
| Sorunome | a few thoughts on https://github.com/matrix-org/matrix-doc/issues/2408 would be cool ^.^ | 15:59:32 |
| anoa | Issue concerning the web fallback above for reference: https://github.com/matrix-org/synapse/issues/6705 | 16:45:17 |
 mscbot | [MSC2409] "MSC2409: Proposal to send EDUs to appservices " has been created: https://github.com/matrix-org/matrix-doc/pull/2409 | 18:54:13 |
|  kaie joined the room. | 20:01:08 |
| kaie left the room. | 20:52:13 |
|  Yan Minari joined the room. | 23:41:54 |
| 15 Jan 2020 |
|  nephele joined the room. | 17:40:34 |
| nephele | Hey, benpa linked me here for a idea i had:
I would like to split off the client-server spec into one client-server and one instant messaging spec, the idea beeing here that normal "chat" clients can follow both, but other clients that for instance could act like a bugtracker don't have to concern themselves with this.
The "easy" endpoints that is, ones that could be done just aswell by callling state or event endpoints directly with specific content would then where they concern the im stuff also be defined in the im spec
i.e client-server:
m.room.create
instant messaging:
m.room.topic
m.room.name
m.room.message
| 17:44:06 |
| nephele | I would also like this im spec to have seperate versioning, that then is included in the messages so clients can have an easier time verifying content that is /not/ valid based on a given spec version | 17:45:13 |
 TravisR | in theory that's what the feature modules section deals with. The spec isn't very clear: but the schemas for topics and such are only there for if/when you use them, not to imply they're required for a room. | 17:45:14 |
| nephele | I understand that they aren't required, i would like some more seperation between those parts though, also so that the client-server spec doesn't have to concern itself much with the im stuff and can explain stuff more generally | 17:46:14 |
| nephele | This should also make it easier for a third party vendor to build a specification for a third-party use case and then base it explicitly on the "cs spec version blah" instead of having to specify which parts apply | 17:46:59 |
| nephele | The seperate versioning is moreso important i think, it is kind of annoying trying to validate events when new cs versions keep making more stuff legal, but without any indication that a message follows a new spec version :) | 17:48:23 |
| 17 Jan 2020 |
| Sorunome | how come synapse expects m.login.token to be a macron? Don't see anything specific to that in the spec | 10:37:19 |
| Sorunome | also, how come synapse implements m.login.jwt? Don't see anything of that in the specs, either | 10:37:32 |
 richvdh | In reply to @sorunome:sorunome.de
how come synapse expects m.login.token to be a macron? Don't see anything specific to that in the spec well, the only thing that is valid to pass into m.login.token is something that synapse has generated | 10:55:44 |
| Sorunome | In reply to @richvdh:sw1v.org
well, the only thing that is valid to pass into m.login.token is something that synapse has generated synapse doc allows custom auth providers for that endpoint which never get called | 10:56:03 |
| richvdh | which doc | 10:56:28 |
| Sorunome | In reply to @sorunome:sorunome.de
also, how come synapse implements m.login.jwt? Don't see anything of that in the specs, either ironically soru wrote an auth provider to do just this on m.login.token only to find out that it was already built-in in synapse | 10:56:35 |
