[manton]Anyone following Evan P’s work on an OAuth 2.0 profile for ActivityPub client-to-server? I asked whether IndieAuth could play a role here, but I haven’t a chance to figure out if that actually fits. Identity with WebFinger-style addresses vs. domain names might be too much of a mismatch.
[snarfed]I like the Nostr NIP-05 approach: it does user@domain identifiers, but in client UIs, when user is `_`, it hides the user and uses the bare domain as the id
[tantek][manton] it could work bc AP has no dependency itself as a spec on WF. Also we already know how to integrate a client API with IndieAuth: Micropub. So AP Client API could use the same method
[manton]Currently the IndieAuth spec says pretty clearly that the client ID must be an HTTP(S) URL. I’m imagining that Mastodon people will want to enter a user@domain-style identifier instead, although they could do http://domain.com/user and be compatible with IndieAuth.
[manton]Would it be worth exploring an extension to IndieAuth to support user@domain? Compatible servers would translate that for the user to a real URL.
[manton]The advantage would be avoiding yet another OAuth profile with its own way of describing a user, e.g. name and profile photo would just use IndieAuth conventions.
[manton]Lemme know if I’m totally off-base here. I’d love to see more of the new work in the ActivityPub world be as IndieWeb-friendly as possible, where appropriate.
[tantek]Thus if some implementation wants to translate some random format like ~user into an HTTPS URL and then use IndieAuth, it can do so. Layering additional UI/processing like that is allowed (not disallowed), nor does have to be in spec
[manton]Something (probably the IndieAuth server) is going to need to do a WebFinger lookup to translate that to the URL that is used for the rest of IndieAuth.
[KevinMarks]The usual OAuth pattern is to put in the base domain - that's how mastodon OAuth works, and it relies on login or session cookies from there, just as IndieAuth does.
[tantek][manton] there's a big difference between "what ActivityPub IDs can support" and "what UX an ActivityPub implementation will want to present" and there is no need to assume a 1:1 correspondence there. That's what I meant when I said above: "Thus if some implementation wants to translate some random format like ~user into an HTTPS URL and then use IndieAuth, it can do so. Layering additional UI/processing like that is allowed (not
[tantek]The IndieAuth server does not need to do any WF or translation. The AP implementation/client can do all that in its own UX, and then talk IndieAuth over the wire to the server
[manton] Currently the IndieAuth spec says pretty clearly that the client ID must be an HTTP(S) URL. I’m imagining that Mastodon people will want to enter a user@domain-style identifier instead, although they could do http://domain.com/user and be compatible with IndieAuth.
[KevinMarks] AP client id's are URLs too.
[tantek] [manton] there's a big difference between "what ActivityPub IDs can support" and "what UX an ActivityPub implementation will want to present" and there is no need to assume a 1:1 correspondence there. That's what I meant when I said above: "Thus if some implementation wants to translate some random format like ~user into an HTTPS URL and then use IndieAuth, it can do so. Layering additional UI/processing like that is allowed (not
aaronpk what does "the proposal has been merged" mean?? https://codeberg.org/fediverse/fep/pulls/162#issuecomment-1204683
[capjamesg] While you have your standards hat on aaronpk, mind looking at https://github.com/protocol-registries/link-relations/issues/63