This is a discussion thread for the proposed FEP-3b86: Activity Intents.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.
Summary
Activity Intents extend the capabilities of an ActivityPub server beyond a user’s inbox, and simplify the process of interacting with content on the wider social web. They do this by publishing a machine-readable list of public URLs where users can perform key activities (such as Follow, Like, or Announce) allowing other websites to easily initiate remote social interactions.
@benpate what happens if the object isn’t found, does the server automatically redirect back to on-cancel? That sounds like it’d be an open-redirect vulnerability, in which case, if the object doesn’t exist it should probably return a 404.
I hadn’t considered what would happen if there was an error on the home-server side. It makes sense that it would just display an error page, which should prevent the “open-redirect” issue. I can update the FEP to mention this.
I don’t have a very strong case for one way or the other. I do think these should be distinct from ActivityPub activities and properties so that they stand out as different, for a different purpose.
I’m open to suggestions on how to accomplish this better.
I think consistency is probably important. Probably also add language that implementations should (or even must) allow the user to choose to continue to the return URL, I’m not sure an automatic redirect is desirable here, and it lacks the security properties that OAuth’s redirect URIs have, since those need to be preregistered, such that you can’t just be taken off to any random place.
An “open redirector” is an endpoint on a web server that forwards a user’s browser to an arbitrary URI obtained from a query parameter. — OAuth 2.0 Security Best Current Practice § 1.2
You could perhaps also borrow a leaf from OAuth 2 where you have a single redirect_uri which has query parameters indicating success or failure. e.g., you could redirect back with the new object ID on success, and on failure redirect with an error code and description. Those errors could then be more concretely defined.
I’m not sure how one would otherwise prevent an open redirect attack.
href: Links also use the standard WebFinger href property, but also include wrapped replace values (as in {uri} or {name}) to designate parameters to be injected by the caller. (note: this is in contrast to the non-standard template property that was used by oStatus)
I think template can be used too, I would even prefer that option. The “JSON resource descriptor” format used by WebFinger was first introduced in RFC-6415. It describes template attribute in section 3.1.1: RFC 6415 - Web Host Metadata
I don’t know why template is not mentioned in WebFinger RFC.
There is also RFC-6570, which describes URI templates. Consider adding it as a normative reference: RFC 6570 - URI Template (if its requirements don’t differ from RFC-6415; I didn’t check).
I wasn’t aware of Fedi Links, so I’ve spent the morning trying to catch up. If I’ve misread the website, please forgive me.
The biggest difference I see is that Fedi Links requires a custom browser, such as the ones listed in Fedi Links: Compliant Implementations, or is waiting on changes to the big browsers like Chrome, Safari, Edge, and Firefox.
I think Activity Intents accomplishes the same thing, but is handled by websites themselves instead of relying on enhancements to browsers themselves.
I believe this makes a better case for implementing Activity Intents because it can be done much more incrementally, and can start producing real benefits without waiting on a massive implementation from the big browser vendors.
–
The simplest thing would be to publish the endpoints that already exist in Mitra. Down the road, it might make sense to add new endpoints (such as remote Likes)
I think the spec is pretty comprehensive, but I’ve been thinking I should write up an Implementation Guide as well, that collects the issues and feedback that other projects have. Would this be helpful for you?
The FEP seems to explain things pretty well. I don’t think implementation guide is necessary, but an up-to-date list of implementations would be helpful (I guess Emissary already implements this FEP?).
What are your thoughts on template? (I talked about it in my previous comment)
Yeah, I was just trying to follow WebFinger correctly. I didn’t have those other specs to go on, so I figured that template was just a non-standard extension that was only used by oStatus.
RFC-6415 makes me a little more comfortable using templates. Like you said, even if they’re not included in WebFinger itself, they’re at least recognized as a standard, and the semantic distinction should be enough for other developers to feel comfortable using it.
I’ve been reaching out to several projects about implementing Activity Intents, so this is probably our last chance to make changes before we start getting actual code out there that depends on it. I’ll try to make this change to the spec and get it pushed up to codeberg later today.
I think this is a very very similar use case, but Activity Intents doesn’t quite address this case (yet?). Activity Intents would let you interact with an object you find on another server – to share, like, dislike, or reply – but doesn’t include something that would simply open the object.
It would be easy to add something for this into the FEP. I’ll just want to be careful that we choose something that works with the rest of the activities. Right now, I’ve just cribbed all of the activities from the Activity Vocabulary document. It doesn’t include an “open” verb, which is why I didn’t, either.
What do you think? Is there room for an “open” activity? And, is there a better name to use than this?
I took another look through the Activity Vocabulary verbs, and View seems like a perfect match. So perhaps we just document this as the correct way to use it?
True. I guess I’m looking at it as the difference between a GET request and a POST request. For Like activities, the Activity Intent sends me to a GET page where I can review the transaction before I POST it back to my account.
Perhaps in theory, you are View-ing the object to confirm if you want to send the activity or not?
If it’s too much of a stretch, then we can work out something else. But, this wouldn’t be the weirdest thing devs have done with ActivityPub.
Remote interaction with intention to generate a View activity and GETting an object are distinct use cases, in my opinion. In the latter case, I would prefer to not bother the user with a confirmation popup.