I don't think this really solves the problem, though. If a server implementation prefers content
over summary
(which it should), with this example the context of the book title will be lost unless the server is updated to understand read-of
.
The summary
property is intended to be used for fallback for when the server doesn't recognize the other properties of the request. Most Micropub servers understand content
and photo
, but this is a great example of an interesting content type that is likely not supported by most servers yet. In this case, summary
is the correct place for this fallback content. The content
property would be misleading since normally the content
property contains user-entered text. For example, if the user enters a note about why they wanted to read this, that could be included in the content
property.
It would be fantastic if Gitea were its own OAuth2 provider! In fact, IndieAuth is the perfect candidate for how to implement this.
IndieAuth is an OAuth 2.0 extension, which avoids the centralized problems with existing OAuth solutions by using DNS for "registration" of client IDs and user IDs. Every user account is identified by a URL (for Gitea this could be your Gitea user page), and client IDs are also URLs (would be the Gitea instance home page in this case.)
This would let people sign in to other Gitea instances without any sort of prior relationship or doing client registration and such. Happy to walk through this in more detail if you're interested!
What we really need is federated authentication, but that doesn't exist yet.
This sounds like a great use case for IndieAuth. w3.org/TR/indieauth
IndieAuth is an OAuth 2.0 extension, which avoids the centralized problems with existing OAuth solutions by using DNS for "registration" of client IDs and user IDs. Every user account is identified by a URL (for Gitea this could be your Gitea user page), and client IDs are also URLs (would be the Gitea instance home page in this case.)
To log in to your Gitea instance, I would enter my own Gitea profile URL. Your instance would then do discovery on my URL to find where to send me to authorize the login on my own OAuth server (my Gitea server), which would then send me back to your Gitea where it would be able to verify the authorization code against my Gitea instance.
I'd be happy to walk through this in more detail if you're interested!