@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.

@thisismissem @julian @naturzukunft is this in a FEP or RFC someplace?

@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.

@FenTiger @julian @evan

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?

@evan @thisismissem @julian @naturzukunft

@benpate @julian I suppose this is where fine grained authorization (such as RAR) comes in - assuming that people will understand it - which they might not!

Looking forward to talking about the details properly...

@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.

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?

@evan @thisismissem @julian @naturzukunft

@benpate @evan @thisismissem @julian @naturzukunft SWICG c2s task force wen (or will the payments task force just naturally become the c2s tf over time)

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.

@FenTiger @evan @thisismissem @julian @naturzukunft

@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 @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).

@julian @FenTiger @benpate there's no way to know that.

@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...

@FenTiger @julian @evan

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

@benpate @FenTiger @julian they should just pass them along! If you don't implement a side effect for that activity type, just leave it alone and pass it along to clients.

@benpate @FenTiger @julian the plan there is to have finer grained scopes for particular activities. And also limiting them by domain: "let this server Like and Reply to objects on its own domain"

Add more granular scopes specific to ActivityPub

fep - Fediverse Enhancement Proposals

Codeberg.org (codeberg.org)

@benpate @FenTiger @julian there's a whole chapter about the API in my book:

https://evanp.me/activitypub-book/

@by_caballero @benpate @thisismissem @julian @naturzukunft that's too hard. We have an API. It already works.