-
Notifications
You must be signed in to change notification settings - Fork 369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for discovering API endpoints via .well-known URIs (SPEC-121) #433
Comments
Jira watchers: @ara4n |
Links exported from Jira: relates to https://github.com/matrix-org/matrix-doc/issues/434 |
Some potential considerations regarding SSL SNI (server name indicators): eternaleye (IRC) ... [02:32] [01:42:58] Arathorn: IIRC, the issue with CloudFlare was that SNI + SRV sends SNI for the name the SRV record is on, while the cert was for the name it points to -- @ara4n |
I was asked in element-hq/riot-android#727 to chime in here. This is a high-priority feature we should add ASAP, as I think it greatly impacts user experience, and currently in negative ways: When I try to log in to Riot-Android (F-Droid version here), I am asked for my "email address or username". There's an option to specify custom server options, but it's labelled advanced and I should not need to touch it. However, when I try to log in as
I also tried If I enter XMPP clients do use SRV records to determine which server to login to ( It shouldn't matter anyway. The important thing IMHO is to make sure that users can log in with least effort and least surprises. |
This has just come up again on #matrix-dev: https://matrix.to/#/!XqBunHwQIXUiqCaoxq:matrix.org/$1492701491891267IJVIs:matrix.org I've put what I think are the options into a spec proposal google doc: https://docs.google.com/document/d/1RHQ5DEA6_2IZ5m2UIysPf8CuYaup-NrincEbV4Ef3jE/edit#heading=h.ouq2tlo7ae5z |
Let's try to avoid this getting lost for another 2 years. A major reason for Mastodon's success seems to be not having to piss around with DNS, for instance. Does anyone actually object to just adding .well-known URIs as the preferred discovery mechanism, keeping SRV as backup for weird people (e.g. Leo, Amdocs) who would find it easier to do DNS rather than edit their web root? |
Strongly supporting the "let's not get this lost". As for "what to implement": use all methods you know, define a order in which the clients have to try them. Every method will have drawbacks for one or another, but having several and knowing which one trumps the others will help to use "the right one". Just a few known autodiscover-Methods from other software:
Sorry for my english, I'm not a native speaker ... |
For Matrix IDs this sounds great. The content might be the homeserver address to use, with an optional IS address (which would auto-fill) the “advanced” fields of the client. |
What would be needed to get this done? There seems to be a general consensus that
Is there anything else that needs to be done? (re. 1. and 2.: let the bikeshedding begin!) Edit: reorder steps as per @IT-Sumpfling 's suggestion |
An Identity Server URL might also come in handy. I know there are plans to federated those, too, but until then if I trust is.example.org but not the evil vector.im one, it would be nice to let clients know. Also, if my HS is not federated, maybe my IS isnʼt either. Also, I vote for JSON, as clients already have to speak JSON anyway. Or was that question only about “JSON file having the |
For
"5." should be decided upon before "3." - because the SRV-entry should be part of the spec (and yes, _matrix-client._tcp sounds good)
"8." Grofit ;) |
@IT-Sumpfling you're absolutely right about doing 5 before 3. That was a brainfart on my part. I've updated the list to reflect this. I've also added a step regarding Identity Servers. As far as using a For the same reason, I would also suggest against puting identity server information in @gergelypolonkai the question was a broad question that included both what format to use (XML or JSON), and about whether to use a |
Hmm, I can see where you are heading, still I would vote for a sub-dir for the following reasons:
To the other points:
|
Oh, and just read the FIRST entry again - we should probably include two entries in the .well-known-File: |
personally I would never go with duplication of information, it's the best way to introduce human errors and duplication of work. Federation already has the most adapted way: a SRV record. there is no need to work further on this. As for the content of the
|
@IT-Sumpfling You should check out mxisd then. matrix.org and sydent are NOT the only pieces of the puzzle here. |
Hmm, I still do not see how identity server would make sense in .well-known AFAIK the identity-server is used to resolve from an ID in the form user @ maildomain to a "fully qualified" matrix id in the form @ user : matrixdomain - and THEN you could query .well-known on matrixdomain for the homeserver . And then I didn't even start to take into account the resolution from mobile numbers to matrix-ids ... on which domain would you query the .well-known for the identity-server if I try to login via Correct me if I'm wrong, but at the moment I would say: if the user tries to login via phone number or email and is NOT registered at the "well-known central Identity-server" - he or she must definitely enter an identity server URL |
@IT-Sumpfling the identity server URL can be input when you login, so auto-discovery of it would be at the same time as discovery the homeserver. As for how it works, that's not correct and you don't take into account other mechanisms. I would let you read the IS spec and mxisd README if you want more details, but ignoring the identity server URL in a |
Hmm, I take for granted that you are more experienced regarding IS specs than me (I just skimmed over them now) - but IMHO for a identity-server entry in .well-known to make sense, the following questions would have to be answered:
|
The two remaining issues were whether we would support removing the After further discussion, removing the Regarding names, we decided that we would use So it seems like this issue is now ready to be turned into a spec PR. |
In the interests of tracking folks' approval on this one, it'd be good to get a thumbs-up reaction on this comment from @erikjohnston @richvdh @dbkr @turt2live @anoadragon453 and anyone else who cares (a bit like we've done on #1232 (comment) to track agreement before declaring the proposal having passed review). (@uhoreg doesn't count as he's shepherding :) |
There's a couple unanswered questions in the proposal still - I've added comments on the doc. They are probably answered in the comment thread here and haven't been transferred to the doc yet.
|
Regarding the prefix stuff, yes, the decision was "Option 0: Do nothing", to avoid scope creep and add extra work for client authors. Regarding |
To clarify: This ensures:
|
May be off-topic... |
@njouanin It is a bit off-topic, and I don't know if there is any official suggestion for that, though my own personal feeling is that it makes sense to put it in a specific endpoint tree. As far as discovery of these endpoint trees, since the well-known is a JSON file, one could put in a specific key that can be checked. For example (purely for illustrative purposes), one could add in a |
Upon further discussion, and better understanding @maxidor's reasonings, it seems like we have a consensus that a 404 should be left as-is, to allow for implementation-specific behaviour (such as default homeservers) and/or future discovery mechanisms. The actual PR that comes out of this may include clarifying or modified language to make this clearer. |
I didn't mean to open a can of worms on this, however it's still not explicitly described what that process is (outside of comments on here). The only reason I'm pushing for it to be in the google doc is so that the doc and the comments here are aligned. It's been incredibly frustrating in the past to track down where something was said to find out why it differs, particularly when trying to figure out the motivation for a particular design decision. Given the possible surface area for comments is 2+ rooms, 2 docs, this issue, and the upcoming PR, it'd be nice if the more static places (docs, issue, PR) are aligned. |
Yes, I plan on updating the Google doc with a summary of the discussions, and will probably do so some time after I get back home (Tuesday). |
Done via #1359 |
Documentation: https://docs.google.com/document/d/1OdEj06qA7diURofyonIMgTR3fB_pWf12Txye41qd-U4/edit, https://docs.google.com/document/d/1vF-uWlUYmf1Xo161m871H1upJbwiIPeikWGWzaE_lrU/edit#
Author: @maxidor, others
Shepherd: @uhoreg
PRs: #1359
We have several reasons why we might want to use .well-known URIs to discover API endpoints:
See also SYWEB-224 and SYN-167
We should just get on and do it. Unsure whether SRV should trump .well-known URIs or not for server-server traffic.
(Imported from https://matrix.org/jira/browse/SPEC-121)
(Reported by @ara4n)
The text was updated successfully, but these errors were encountered: