FEP-3b86: Activity Intents

trwnh · March 2, 2025, 3:05pm

Why not use proxyUrl from ActivityPub?

benpate · March 4, 2025, 4:18pm

Is this what you’re referring to? ActivityPub

This is pretty close to what we’re working on here, but maybe not exact? I’m having a hard time finding any better documentation on this, or anyone implementing this in the wild to use as a reference. proxyUrl seems to to expect a POST that will authenticate a user to view a remote stream, not the simple GET address on their home server.

If this is already meant/used in this way, then we’re great, and nothing needs to be added to Activity Intents. But if it is in use for different purposes, then we’d be breaking something.

I will keep digging to see if I can find this in use already.

trwnh · March 5, 2025, 5:40pm

we could extend proxyUrl to allow GET with query parameter instead of just POST with form-encoded parameter. it’s already quite similar to mastodon’s remote interaction handler, except that one takes uri parameter instead of id.

github.com/mastodon/mastodon

Redirect instance1/instance2/@username to instance1/@username@instance2

opened 05:05PM - 05 Mar 23 UTC

nclm

### Pitch This idea is to have some redirection system in place so that: `http…s://instance1.tld/instance2.tld/@username` would automatically lead to: `https://instance1.tld/@username@instance2.tld` And other similar redirections: `https://instance1.tld/instance2.tld/@username@instance3.tld` to `https://instance1.tld/@username@instance3.tld` `https://instance1.tld/instance2.tld/@username/123456789` to `https://instance1.tld/@username@instance2.tld/123456789` ### Motivation There’s often a need for a quick way to open on an user’s own instance a profile or a post that is currently opened in the browser on a remote instance instead. For instance to follow, reply or favourite the profile or post on the page. The way to go now is to copy the username or the URL, open your instance, paste inside the search bar, and click on the first result, then you are able to interact. That’s great, but adding other quick ways would be beneficial. With this redirection scheme in place, a user would simply be able to type the domain name of their instance before the current URL to instantly go to the right page and click follow/reply/favourite.

GET /authorize_interaction?uri=https://object.example HTTP/1.1
Host: mastodon.example

this loads some page that shows the object and allows you to either follow an account or view a status.

basically i am saying that the definition of proxyUrl could be expanded to allow GET and then it can be used as a link relation:

{
  "rel": "https://www.w3.org/ns/activitystreams#proxyUrl",
  "href": "https://mastodon.example/authorize_interaction"
}

GET /authorize_interaction?id=https://object.example HTTP/1.1
Host: mastodon.example

this is assuming you really need a GET. personally i don’t see a reason to care about GET vs POST here, and in fact a POST can make sense because you are not simply asking for a representation, you are potentially resolving and caching a remote object into the local database.

benpate · March 7, 2025, 4:23pm

I found some information on the ActivityPub primer that says this is really intended for authenticated, C2S requests using POST.

I think we’re discussing something similar in spirit to proxyUrl but very different in the details. This feature in Activity Intents is aimed at helping me get back to my home server when I’m out on the open Internet.

So, I think we might take some ideas from this, but we shouldn’t try to extend or repurpose this existing data point. That would only lead to confusion.

benpate · March 7, 2025, 4:31pm

Hey, I never got back around to this, directly. I’m going to write this up using Object and see how it looks.

You made a good point about using View activities for this. I really want that one to work out, but unless we’re expecting to send View documents for every item we view, we should probably not use it in this way.

trwnh · March 7, 2025, 4:42pm

how is that different? when you’re out on the “open internet”, you can look up your own webfinger, take the link with the correct rel, and then plug your “open internet” URI into that endpoint. i don’t see how that isn’t just basically mastodon’s existing authorize_interaction endpoint, or how that’s any different than as:proxyUrl in spirit. the only technical difference is that proxyUrl generally returns JSON-LD instead of a HTML web UI, but that can be handled by conneg.

benpate · March 7, 2025, 5:13pm

I think you identified the issue. As it’s in use now, proxyUrl expects a POST and returns JSON. I want something pretty similar that expects a GET and returns an HTML page.

If we simply repurpose proxyUrl, there would be no way of knowing if the server supports a POST/JSON endpoint or a GET/HTML endpoint. It would confuse existing systems, and completely break Activity Intents.

I don’t want to clutter up WebFinger responses with unnecessary additions, but Activity intents is an incremental change that will take time for the many Fediverse projects to implement. We can’t use this existing value and expect everyone has already implemented it “the new way.” Doing that would kill adoption of Activity Intents entirely.

–
I missed this point in your original note, sorry:

Yes, https://w3id.org/fep/3b86/Object would be very similar to Mastodon’s /authorize_interaction endpoint. Several other activities also map directly to Mastodon APIs. The difference is that we’re not hard-coding a Mastodon-specific path, so different projects can support the feature set without mimicking Mastodon’s URL layouts, too.