Skip to content
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

Introduce a .well-known discovery endpoint and DNS SRV records #82

Merged
merged 3 commits into from
May 16, 2024

Conversation

glpatcern
Copy link
Member

Following today's discussions, would this be enough? Maybe complemented with some details in the README.md file?

spec.yaml Outdated Show resolved Hide resolved
@glpatcern glpatcern requested a review from mickenordin May 7, 2024 08:32
Copy link
Collaborator

@mickenordin mickenordin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@DanScharon
Copy link

DanScharon commented May 7, 2024

wonderful!
Is this intended to enable the discovery of a user's federated instance?
For example I would enter the email address of a person I wish to share with (person1@example.com) and my instance would look up https://example.com/.well-known/ocm which would point to https://cloud-storage.example.com and my instance would ask https://cloud-storage.example.com whether it has a user with the email address person1@example.com that I could share with?

@glpatcern
Copy link
Member Author

wonderful! Is this intended to enable the discovery of a user's federated instance?

@DanScharon that's precisely the idea, assuming that the vendors will implement that mechanism in Nextcloud, OCIS, etc.

I intend to include that workflow in the README.md, possibly coupled with the other idea that emerged at the CS3 workshop, that is the DNS SRV record.

@glpatcern glpatcern force-pushed the wellknown-disco branch 2 times, most recently from b355af4 to da1b7d5 Compare May 7, 2024 16:19
@DanScharon
Copy link

wonderful! Is this intended to enable the discovery of a user's federated instance?

@DanScharon that's precisely the idea, assuming that the vendors will implement that mechanism in Nextcloud, OCIS, etc.

I intend to include that workflow in the README.md, possibly coupled with the other idea that emerged at the CS3 workshop, that is the DNS SRV record.

Excellent! Thank you for including this in the spec!

@glpatcern
Copy link
Member Author

I'd love a second read of the paragraph I added to the README.md, @mickenordin would you please have a look? Thanks!

Copy link
Collaborator

@mickenordin mickenordin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a fine addition.

We should probably extract relevent information from this discussion and add it to the spec text it self: #37 (comment)

But I dont think it needs to happen in this pr, we can do it separately.

@glpatcern
Copy link
Member Author

We should probably extract relevent information from this discussion and add it to the spec text it self: #37 (comment)

That's true, this comment is even referenced "as is" but it would be good to get more up to date information about current issues with .well-known. Agreed that it's for another PR.

And otherwise, with @labkode we better defined how to use DNS SRV records, which is a much more viable solution than assuming that an organization can deploy https://example.com/.well-known/ocm sort of URLs: the latter are typically not under the control of the EFSS team.

@glpatcern glpatcern changed the title Introduced a .well-known discovery endpoint Introduce a .well-known discovery endpoint and use DNS SRV records May 13, 2024
@glpatcern glpatcern changed the title Introduce a .well-known discovery endpoint and use DNS SRV records Introduce a .well-known discovery endpoint and DNS SRV records May 13, 2024
@glpatcern
Copy link
Member Author

@DanScharon we slightly modified the logic for discovery: the goal is the same, but typically a https://example.com/.well-known/ocm address is hard to be maintained by the cloud storage team as it "belongs" to the institutional web site and its auth system. Instead, a DNS query can do it, see the new description.

@glpatcern glpatcern linked an issue May 14, 2024 that may be closed by this pull request
@glpatcern glpatcern mentioned this pull request May 14, 2024
@glpatcern glpatcern force-pushed the wellknown-disco branch 2 times, most recently from 96bec35 to 1f42a6d Compare May 14, 2024 09:04
@glpatcern glpatcern force-pushed the wellknown-disco branch 2 times, most recently from 2966e02 to 56d8e3e Compare May 14, 2024 11:34
@glpatcern glpatcern merged commit 4847245 into cs3org:develop May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Server alias
3 participants