@julian diving into the hard problems of building for the Fediverse at #Fedicon, starting with hilariously talking about how those hard problems look like to average users 😅
-
@thisismissem @naturzukunft @julian but they don't work right now, out of the box? I think that doesn't meet his requirements then.
@evan @naturzukunft @julian because we're an internet draft in front of the OAuth Working Group at IETF and we're having to balance a dozen different needs and compatibility issues. But we already have adoption in some places (bluesky/AT Proto being one of the most notable adopters)
-
@thisismissem @naturzukunft @julian hey, that brings up a great point. Does Mastodon support clients using OAuth for accessing the read-only parts of the API (reading an actor, reading an outbox, reading a note)? I've done it with no authentication and with HTTP Signatures but I don't know if you can use OAuth. That would be a huge step in the right direction.
@evan @naturzukunft @julian not for AP, because we're don't support anything related to C2S. We could add OAuth support there theoretically, but it's not a priority right now.
-
@evan @naturzukunft @julian not for AP, because we're don't support anything related to C2S. We could add OAuth support there theoretically, but it's not a priority right now.
@thisismissem @naturzukunft @julian right, but the ActivityPub API is not just about posting activities to the `outbox`. It also includes reading all the actors, collections and objects in the Activity Streams 2.0 format.
Anyways, I might look into it and make an issue and PR. If it worked properly, you could do a decent read-only application with the ActivityPub API, without making any commitment to the client-to-server part of the spec. That'd be a nice step forward for the API.
-
@thisismissem @naturzukunft @julian right, but the ActivityPub API is not just about posting activities to the `outbox`. It also includes reading all the actors, collections and objects in the Activity Streams 2.0 format.
Anyways, I might look into it and make an issue and PR. If it worked properly, you could do a decent read-only application with the ActivityPub API, without making any commitment to the client-to-server part of the spec. That'd be a nice step forward for the API.
@evan @naturzukunft @julian talk to the team first. Doing changes here is not simple.
-
@evan @naturzukunft @julian talk to the team first. Doing changes here is not simple.
@thisismissem @naturzukunft @julian @MastodonEngineering that was on my agenda.
-
I'm still catching up on this conversation, but I just want to add that this analysis is spot on. Very well said, Julian. Thank you!
I'm collecting a few thoughts on this that won't fit into a toot, so I'll probably post them elsewhere and link back here once I get it together.
-
@julian @naturzukunft FEP/d8c2 is poorly designed and the comments on socialhub show this. It's not how OAuth is meant to work.
We should be using Authorization Server Metadata + Rich Authorization Requests for any OAuth implementation for an ActivityPub API.
Scopes would ultimately be pretty minimal, e.g., profile, offline_access (both OIDC), and maybe like manage:keys for updating signing keys; the rest should probably be RARs.
For discovery, if the Actor object advertises an authentication method of OAuth or OIDC, the look for the authorization server URL, discover all OAuth specifics from there.
For clients, you could do dynamic client registration, but it has drawbacks, so I'd recommend Client ID Metadata Documents.
@thisismissem @julian @naturzukunft is this in a FEP or RFC someplace?
-
@julian @benpate @evan I think FEP-3b86 only really allows for actions that the home server already knows how to carry out; the advantage of FEP-d8c2 is that it allows clients to add functionality of their own; see eg Evan's checkin app, which can post geo-tagged activities even via a server which doesn't natively support them.
This is a good point, though I'm not clear how different servers would handle outbox requests for activities that they don't support. I'm pretty sure mine would just die.
My big concern with OAuth tokens is that they require me to give away write access to my Fediverse identity when I "like" or "reply" to something, which could easily be an attack vector.
We talked about scoping OAuth tokens, but it feels like a lot of moving parts. More details later
-
@thisismissem @julian @naturzukunft is this in a FEP or RFC someplace?
@risottobias @julian @naturzukunft anyone paying me to write it? No? Then there's probably not gonna be s document appear whilst I struggle to pay my rent
-
@thisismissem @julian @naturzukunft the point of discovery is to find the important endpoints and parameters for the flows. Many implementers who are concentrating on a single API skip discovery because the resource provider has already defined the specific flow. Alternatively, many API providers allow client registration out of band. It is absolutely 100% OK to do OAuth without using features like discovery and dynamic client registration.
I'm genuinely behind on this. I've skimmed Evan's FEP, but a lot of OAuth complexity is still opaque to me.
It seems like the missing piece with using the C2S API would be *figuring out* what endpoints I can call to initiate an activity.
Does FEP-d8c2 implement discovery in some way that I'm not seeing? Or, is this something *still to be defined* and I'm just jumping the gun, here?
-
This is a good point, though I'm not clear how different servers would handle outbox requests for activities that they don't support. I'm pretty sure mine would just die.
My big concern with OAuth tokens is that they require me to give away write access to my Fediverse identity when I "like" or "reply" to something, which could easily be an attack vector.
We talked about scoping OAuth tokens, but it feels like a lot of moving parts. More details later
-
I'm genuinely behind on this. I've skimmed Evan's FEP, but a lot of OAuth complexity is still opaque to me.
It seems like the missing piece with using the C2S API would be *figuring out* what endpoints I can call to initiate an activity.
Does FEP-d8c2 implement discovery in some way that I'm not seeing? Or, is this something *still to be defined* and I'm just jumping the gun, here?
@benpate @evan @thisismissem @julian @naturzukunft I think the idea is that you get an access_token which you can use to post to the outbox - which you can discover from the Actor object.
-
Yes. It seems possible, but would require a lot of complex thought to do well. And that complexity is pushed onto the user, who has to determine if they like the terms that the website is presenting in order to continue putting a "star" on an article.
You and I will implement this ethically. Others will implement it adversarially -- I want to build the protocol to protect against the next Cambridge Analytica.
-
@benpate @evan @thisismissem @julian @naturzukunft I think the idea is that you get an access_token which you can use to post to the outbox - which you can discover from the Actor object.
But most software doesn't support the C2S API, so that POST would either fail, or the server would lie and say "thanks for submitting this activity" and then just do nothing with it.
I'd like to know that the activity is going to fail BEFORE I hit submit. Otherwise, users will run into a dead end, and the server that originated the request won't have any way to fix it.
Servers should know AHEAD OF TIME if they can post activities or not.
-
I'm genuinely behind on this. I've skimmed Evan's FEP, but a lot of OAuth complexity is still opaque to me.
It seems like the missing piece with using the C2S API would be *figuring out* what endpoints I can call to initiate an activity.
Does FEP-d8c2 implement discovery in some way that I'm not seeing? Or, is this something *still to be defined* and I'm just jumping the gun, here?
@benpate @evan @thisismissem @julian @naturzukunft SWICG c2s task force wen (or will the payments task force just naturally become the c2s tf over time)
-
@benpate @evan @thisismissem @julian @naturzukunft SWICG c2s task force wen (or will the payments task force just naturally become the c2s tf over time)
@benpate @evan @thisismissem @julian @naturzukunft all joking aside I think c2s requires emelia and Aaron's rfc on the OAuth side, and some equally complex discovery mechanism based on alternate AuthZ (presumably something based on certificate-ized Object Capabilities?) if we wanna stay composable and not-100%-dependent on oauth...
-
But most software doesn't support the C2S API, so that POST would either fail, or the server would lie and say "thanks for submitting this activity" and then just do nothing with it.
I'd like to know that the activity is going to fail BEFORE I hit submit. Otherwise, users will run into a dead end, and the server that originated the request won't have any way to fix it.
Servers should know AHEAD OF TIME if they can post activities or not.
@benpate @evan @thisismissem @julian @naturzukunft It's certainly helpful to have a way to know if you should show that button on the UI or not!
-
@benpate @evan @thisismissem @julian @naturzukunft It's certainly helpful to have a way to know if you should show that button on the UI or not!
fentiger@mastodon.social benpate@mastodon.social exactly, we need some guarantee that the activity we POST to the outbox isn't just unceremoniously dropped and an HTTP 200 returned.
NodeBB doesn't support POSTing the outbox at the moment, but we do return an HTTP response for "not implemented", currently.
-
@benpate @julian I'm not sure OWA is the way forward here; mainly it's a lightweight authentication-only alternative to OAuth, and for FEP-d8c2-style SSO the authorization part - issuing the access_token - is important.
FEP-61cf does describe the "zid" mechanism that can be used to avoid the user having to type their handle in; maybe this will be useful (though it's not without its downsides).
-
