DNS SRV entries for endpoint discovery
- Dominant language
- No language data
- Stars
- 23
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
The [discovery](https://indieweb.org/Microsub-spec#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](https://github.com/nextcloud/news) or [newspipe](https://github.com/cedricbonhomme/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:
- [RFC6186](https://datatracker.ietf.org/doc/html/rfc6186) for SMTP, POP and IMAP,
- [RFC6764](https://datatracker.ietf.org/doc/html/rfc6764) for CalDAV and CardDAV,
- [The matrix protocol](https://matrix.org/docs/spec/server_server/r0.1.2#resolving-server-names) defines its SRV entries.
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?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the Discovery chapter of the Microsub specification and compare its profile-page endpoint discovery with the SRV approaches in RFC6186, RFC6764, and the Matrix protocol. Done means deciding whether DNS SRV discovery belongs in the specification and, if so, documenting the endpoint records and client discovery behavior.
Written by the indexing model from the issue text.
Assessment
- Domain
- backend-api-design, documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100