Description of `proxyUrl` is unclear

[jernst]

Section 4.1 defines proxyUrl (note: Url not URI) as a URI used to somehow access access-controlled ActivityStreams objects. The description given is unclear how exactly this would work, and needs clarification. See also discussion in #101.

I notice that none of the actor files we collect at https://fedidevs.org/reference/actor/ uses this field. Is it needed?

[nightpool]

proxyUrl is necessary for client-to-server integrations. Very few client-to-server integrations exist, so it's not surprising to me that fedidevs doesn't show any (especially since it's collecting unauthenticated actors and this field is only useful for logged in users viewing their own actor)

[evanp]

@jernst evanp/one-page-pub and evanp/ap both use the proxyUrl pretty heavily. It's crucial for ActivityPub API clients getting remote contents.

In general, my answer to "should we remove feature X?" is "absolutely not", unless there is a critical security issue.

[jernst]

I accept it is useful, but the description, to me, is still unclear. I would not know how to use it.

[TallTed]

@evanp — Since you "use the proxyUrl pretty heavily", perhaps you could take a whack at improving the description, or putting an example somewhere appropriate, that includes more about how it is, as @jernst said in the opening of this issue, "used to somehow access access-controlled ActivityStreams objects"?

https://github.com/w3c/activitypub/blob/4ea3eccc84ebdb532080e10e4d934ed96bf2daf0/index.html#L825-L832

Something based on @cwebber's request for proxyUrl's creation in #101 might make all the difference —

For client to server interactions, it might be necessary to defer to a server to fetch an item for you that your server-user has access to, but isn't public. For instance, maybe I check my inbox, where I may receive something like for example a "Like" object that is inReplyTo an item my server-user has access to, but which doesn't currently appear in the feed. So, my client will need access to that. But if I just visit the URL, there's no way for me to get that item. If we define a proxyUrl endpoint, our server could get this on behalf of our authenticated user and deliver the object back to their client.

[evanp]

@evanp — Since you "use the proxyUrl pretty heavily", perhaps you could take a whack at improving the description, or putting an example somewhere appropriate, that includes more about how it is, as @jernst said in the opening of this issue, "used to somehow access access-controlled ActivityStreams objects"?

Hey, @TallTed. I usually do longer elaborations on a ActivityPub Primer page. I've started one at proxyUrl endpoint.

@jernst will feditest be testing the ActivityPub API? I'm excited to hear it.

[evanp]

@jernst I've written up a primer page with all the info. https://www.w3.org/wiki/ActivityPub/Primer/proxyUrl_endpoint . Let me know if that answers your question so I can close this issue.

[evanp]

Oh, and I'm charmed to be reminded that this feature originally came from pump.io. No wonder I think it's such a useful idea! Thanks for the throwback to #101, @jernst .

[jernst]

Very nice writeup. I get it now!! Ty!

Re testing the client-to-server protocol, I expect we will be able to test it by plugging tests into the framework, but I think the bulk of the effort needs to be focused on server-to-server because that's where there are many implementations that need to interoperate.

[evanp]

Closing based on commenter response.