If you're wondering why I'm doing tonnes of OAuth implementation work in @hollo, it's because it allows me to more quickly ship prototypes of things like:
- Client ID Metadata Documents
- Expiring Access Tokens & Refresh Tokens
- Public Clients

Both of those are planned for Mastodon, but I'm still waiting on funding & needing to make upstream dependency changes or write entirely new dependencies.

By implementing in Hollo, I can get these features in the hands of downstream client developers like @cheeaun to have them test out and prepare for supporting these features. (They're all discoverable via OAuth Authorizatiob Server Metadata)

Like does a Mastodon API-like server support these things? Check the OAuth Authorization Server Metadata for client_id_metadata_documents_supported (or something) and check if grant_types_supported has refresh_grant and scopes has offline_access, or something like that.

And then that tells you how to interact with that Mastodon API-like server, e.g., do you need to dynamically register a client (current) or can you use Client ID Metadata Documents (future)

Getting these things into Mastodon can take significantly longer because of complex dependencies and extensive test coverage and other interesting issues. And then longer into developers hands due to release cadence & ease of development deployments