| 11 Jun 2019 |
 Maximus | the question is: "how is it non-compliant specificially?" given that the status code seems acceptable to you | 18:30:40 |
| Maximus | *any status code | 18:30:51 |
 TravisR | it was done back in January, looking at the landscape at the time. | 18:31:00 |
| TravisR | Literally the note I have is "mxisd is non-compliant for returning an error code incompatible with the spec". | 18:31:28 |
| TravisR | Unfortunately I don't have have a time machine to tell you what that means | 18:31:43 |
| Maximus | Ok, then please double-check your facts before going around labeling mxisd as non-compliant for an item which was not in the spec until now, especially if you can't give specifics, and for coming back on an agreement made. | 18:33:08 |
| TravisR | sorry, will do. Please also consider not blaming us for the user experience you are forcing users into. | 18:35:25 |
 @olmari:hacklab.fi | Please lets not fight? Sure anger and frustration is, can and even be valid to feel, but bashing to either direction doesn't make things any better :/ | 18:42:00 |
| @olmari:hacklab.fi | I don't know correct answer.. I do get what both of you are saying, and for the most part I feel maximus points valid... I aldo do get what travisr is saying, but I do also feel he is in the middleman there, saying what he know from the issue in past and not having specific details... Sure I'd like to know answer to what maximus asked too just from curiosity point of view | 18:45:08 |
| Maximus | Sami Olmari: We value respect. Coming in a project room and claiming bad things about it without any ground or technical detail is never welcome and only show disrespect, especially from an entity that has slandered the project in the past several times and got reported for it. There is no fight here, just a technical discussion. | 18:45:23 |
| Maximus | The next version of mxisd will contain better support for the 3PID session unbind now that there is a stable spec for it. Unbind via HS signature will be supported but still denied, essentially not changing the behaviour | 18:48:15 |
| TravisR | while we're on the technical discussion: I've just reviewed my notes again, and I think they meant "proposed spec" which was different at the time. I made the mistake of assuming it meant the upcoming release (which is different from the proposal around January) and looked at the repo to see if there was any activity. Because I didn't see anything, I continued with the assumption.
It'd be great if mxisd supported the new homeserver authentication approach defined in the spec, but ultimately it does not have to. | 18:48:53 |
 Jason | In reply to @olmari:hacklab.fi
I don't know correct answer.. I do get what both of you are saying, and for the most part I feel maximus points valid... I aldo do get what travisr is saying, but I do also feel he is in the middleman there, saying what he know from the issue in past and not having specific details... Sure I'd like to know answer to what maximus asked too just from curiosity point of view Why must thou speaketh? | 18:52:32 |
| TravisR | Sorry for the confusion there. Slander was definitely not intentional. | 18:49:49 |
| Maximus | Jason: remember: everyone is welcome to speak | 18:52:56 |
| Jason | Well then while I have TravisR's attention, is it a spec bug to allow the DEL control character in mxid's? | 18:53:51 |
| Jason | I guess that's an issue relevant to identity/servers so... 😅 | 18:54:35 |
| TravisR | It's not related to identity servers, and as far as I know it's not permitted under the specification. It is permitted as a historical character, however those shouldn't be used anymore. | 18:56:14 |
| Maximus | TravisR: https://github.com/matrix-org/synapse/blob/master/synapse/handlers/identity.py#L231 | 18:57:30 |
| TravisR | that's an implementation bug - will raise it with the team | 18:58:01 |
| Maximus | HTTP Status code 403 (or any for that matter it seems) will be returned to the client | 18:58:00 |
| TravisR | it should proxy the 403 straight through to the client | 18:58:24 |
| Maximus | So synapse is not compliant, rigtht? | 18:58:31 |
| TravisR | but it looks like it coverts it to a 502, which is wrong | 18:58:38 |
| Maximus | TravisR: so, is synapse compliant in v1.0.0 with the spec given the code you see? | 19:00:24 |
| Jason | In reply to @travis:t2l.io
It's not related to identity servers, and as far as I know it's not permitted under the specification. It is permitted as a historical character, however those shouldn't be used anymore. All of the control characters are not permitted as historical characters according to the spec, except that one, right? I'm talking about the letter of the written spec. What synapse does, idr. I think it does not accept DEL as a user mxid character. | 19:00:40 |
| TravisR | Maximus: technically, it is compliant if you are going by the precise wording of the spec.
that error should be passed through to the client requesting an unbind through a homeserver, if the homeserver is acting on behalf of a client.
should means it does not have to. The endpoints in the CS API also make no mention of the error.
| 19:01:37 |
| Jason | Whether or not they shouldn't be used anymore is orthogonal because the spec uses the keyword MUST,.. | 19:02:33 |
| TravisR | In reply to @jason:zemos.net
All of the control characters are not permitted as historical characters according to the spec, except that one, right? I'm talking about the letter of the written spec. What synapse does, idr. I think it does not accept DEL as a user mxid character. it sounds like Synapse is being correct and not accepting historical characters for new identifiers, which is correct. | 19:02:18 |
| Maximus | I meant that 403 is acceptable, but is turned into a 502 even tho it seems 403 is a valid status code for the endpoint from what you said? | 19:02:41 |
