FEP-3b86: Activity Intents

Standards Fediverse Enhancement Proposals
, ,
21

Why not use proxyUrl from ActivityPub?

22

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.

23

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.

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.

24

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.

25

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.

1 Like
26

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.

27

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.

28

@benpate I’m currently working on an ActivityPub server and came across this—very neat proposal!

Instead of having a dedicated endpoint for each activity type in ActivityPub, what if instead it was a general endpoint to prompt the server to create on behalf of the current session?

For example, sending a cross origin POST request with an entire activity (like Create/Note) and the end user has to accept the activity. This would allow for servers to accept a wide range of activities while also allowing them to strip or limit types depending on their implementation’s purpose.

An alternative to the above example is redirecting with a query parameter the homeserver fetches and fills in {templating parameters}

29

Welcome to SocialHub!

Interestingly, you had the same idea as me. Untrusted publishing / "share intent" functionality for arbitrary activities · Issue #53 · swicg/activitypub-api · GitHub discusses a single endpoint where you can submit entire arbitrary activities.

1 Like
30

Hey Grant, thanks for checking out Activity Intents. As @trwnh noted, we’ve had some discussion on making a more generic endpoint. Two thoughts:

You can certainly use a single endpoint for all inbound activitys. You’d just need to point each intent template to the same URL endpoint. So, Create could point to `https://my.server.social/do-the-thing?activity=Create\` and Follow could point to https://my.server.social/do-the-thing?activity=Follow

I can see some utility in allowing remote sites to initiate an arbitrary activity on the user’s home server. It would certainly open up Activity Intents to a wider set of uses than we can currently imagine. And yes, for security reasons my home server MUST MUST MUST confirm this with the user before actually publishing it.

But this confirmation step causes a UX dilemma. How should my server confirm with me if a remote web page initiates an activity that it doesn’t understand? As an example, let’s say I’m on a web page that POSTs this activity back to my home server to review:

{
  "type":"Foo",
  "bar":"baz",
}

My home server has no idea what a “Foo” activity is, or what the properties below it represent. So, it’s can’t really give me a confirmation screen that’s any better than showing me the raw JSON properties of the activity. While that might work for a software developer who knows what Foo/bar/baz represents, it is inviting all kinds of mischief when non-technical users learn to blindly accept the qr-code-looking gibberish that shows up on their screen.

If we can solve this “confirmation problem” somehow, I’d love to include a generic option in the Activity Intents FEP. But we can’t put such a heavy requirement on non-technical usersin the process.

31

@grant OpenWebAuth Protocol might be what you’re looking for (discussion thread: FEP-61cf: The OpenWebAuth Protocol).

cc @FenTiger

32

My thought is that unknown activities would show a warning similar to most browser’s SSL error pages. It would show “we don’t know how to correctly display the activity” or something along those lines with a “post anyway” hidden behind a dropdown. This would (hopefully) encourage hesitation to sending an unknown activity type.

This warning page would also show a JSON representation of the raw activity in a collapsible box (to avoid confusing people)

33

I understand the utility of it, but we need to find another way forward. For instance, some commonly understood way to generate a preview of the activity.

But if we have to show JSON-LD to end users, we’ve failed. I’ll bet that most ActivityPub developers shouldn’t have to parse through JSON-LD in their browser to confirm that it’s correct - to say nothing of non-technical people.

34

Isn’t this what AS2 Core tells you to do with name/summary/content?

There are alternatives to showing raw JSON. browser.pub for example has 3 views: visual, tabular, and raw.

I also don’t think that UX challenges justify saying that a capability should be taken away from people who need that capability. The information in the JSON-LD should be convertible to a plain text description, and if you don’t know what a term means it would ideally be something you can look up and find a term definition. If you see a term whose definition you don’t know you can use caution.

Consider the equivalent example of someone giving you an HTML document to publish. Or someone giving you a written plain text letter and asking you to publish that. It’s the same issue. They might have encoded a message you don’t understand. That’s not a reason to disallow publishing HTML or plain text. It’s a general issue with any user generated content. If you’re worried, run it through a sanitizer, but then that’s a different issue.

35

Ben, Grant, the way forward is to abruptly display a 404 to the end user because this is a bug.

Unless I am misunderstanding this conversation: If I stumble onto Instance A and they try to trigger a "Foo" Activity Intent, and I enter my handle, Instance A is supposed to webfinger the handle and discover that: no, my instance does not handle "rel": "https://w3id.org/fep/3b86/Foo

To that end, when Instance A attempts to trigger the intent, it should know ahead of time that my handle doesn't support it, and thus not offer my handle as a supported endpoint.

This is what happens in NodeBB right now when you try to register your Mastodon handle. It discovers that it supports only two intents, Create and Object, and so if you hit "upvote" (which would normally fire the Like intent), it won't offer Mastodon as a supported endpoint.

36

a, falling back to using name, summary, and content works when you're talking about activities and objects (e.g. "I scrobbled a zipwarg, but here's what a preview or summary of that looks like, so just push it to your outbox and call it a day)

But Activity Intents is about instructing another server to process an action on your behalf. If the receiving end doesn't understand the activity itself, how can it perform the requisite side effects?

37

Is your server publishing activities on your behalf without letting you review them?

By default, all activities have no side effects beyond getting published to an outbox. If there aren’t any understood side effects, then there’s nothing to perform. I’d be more worried about what is getting published on my behalf!

I think framing this FEP as “processing an action on your behalf” is getting it mixed up, but to be fair, there isn’t a clean split between activities as published resources vs activities as actions or procedures. Personally, I think any “side effects” should be separated out – and there’s a similar idea described in https://w3id.org/fep/fc48 by @silverpill for how a server might process custom activities with such “side effects”. (You’d need an extended outbox handler that checks for such side effects, but if you can standardize a generic framework for it, then you’d have some idea of what a client expects to happen or be done.)

The only “action” being discussed here is “publish an arbitrary activity”. It’s not a bug, because you wouldn’t trigger publishing an arbitrary activity through the Create rel, and you wouldn’t define a new rel for each and every possible (infinite) activity type. That’s why I linked the GitHub issue for the “share intent” proposal, because that proposal doesn’t care what type of activity it receives – it all ends up in your outbox eventually (when you approve it).

1 Like