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

DNS SRV entries for endpoint discovery #54

Open
azmeuk opened this issue Jun 15, 2022 · 3 comments
Open

DNS SRV entries for endpoint discovery #54

azmeuk opened this issue Jun 15, 2022 · 3 comments

Comments

@azmeuk
Copy link

azmeuk commented Jun 15, 2022

The discovery chapter suggests that The client first performs discovery on the user's profile URL to find the Microsub endpoint and authorization endpoint. Then endpoints should be discovered from the profile page.

Some feed aggregators (I am thinking of nextcloud-news or newspipe) would benefit from implementing microsub, but implementing a profile page just for the sake of the discoverability might feel out-of-scope (although nextcloud itself might be a good candidate to do this).

Other protocols define DNS SRV entries that can be used for discovery. For instance:

I suggest that the microsub-spec defines DNS SRV entries as an alternative endpoint discovery method, so clients might discover the microsub endpoints just by the domain.

What do you think?

@aaronpk
Copy link
Member

aaronpk commented Jun 15, 2022

I think I'm understanding what you're asking, but I think you're coming at it from a different angle.

There's really two parts to Microsub, the discovery aspect and the actual client-to-server protocol aspect. I think you're really only interested in the client-to-server part.

The discovery part is explicitly so that a user can define which Microsub server they want to use. So it doesn't make sense for an aggregator to host profile pages because that's not a user's home page. The premise is that a user has a profile somewhere and points to an aggregator service elsewhere.

@azmeuk
Copy link
Author

azmeuk commented Jun 15, 2022

Maybe I can tell about the usecase I am thinking of to be clearer.

Say there is a website mycloud.com with a OIDC server hosted at auth.mycloud.com and a mail server hosted at mail.mycloud.com, and a microsub server hosted at feeds.mycloud.com.

In the mails world, users are only required to know their email address user@mycloud.com and clients like thunderbird do all the dark magic so users do not need to configure anything.

Similarly, I wish users could use a microsub client by only filling the mycloud.com domain, so they would not have to know subdomains nor the full endpoint URIs like feeds.mycloud.com/microsub.

The premise is that a user has a profile somewhere and points to an aggregator service elsewhere.

Do you mean that the profile URI is expected to be given to a microsub client so it magically finds on which microsub server to connect, or do you mean that microsub cannot be used

@jalcine
Copy link

jalcine commented Jun 29, 2022

The first part! Also, it's important to note that Microsub implies a use of IndieAuth (via https://indieweb.org/Microsub-spec#Authentication_and_Authorization), which sets the idea of a profile URL being present as a normal behavior. The DNS lookup / peeking would be a bit out of the range of this.

(Originally published at: https://jacky.wtf/2022/6/Br51)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants