@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.
@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.
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 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"
@benpate@FenTiger@julian also, and this is very important: if you want apps to have a global reputation, so that social pressure can keep them from being abusive, they need to have a universal id across different API servers.