# ActivityPub client to server is severely impaired by "authorized fetch" because usually before building an Activity to send to an Actor's outbox, ...

submitted by

#ActivityPub client to server is severely impaired by "authorized fetch" because usually before building an Activity to send to an Actor's outbox, one would want to validate some of the IRIs they operate on.

For example, I want to build a Follow request for a remote actor (represented by an IRI or webfinger resource). My client won't allow me to add this random IRI as the Object of the Follow and just send it, it wants to dereference it and make sure it's a valid Actor.

However when authorized fetch is enabled on that actor's instance, this dereference will fail, because the client can't generate a valid HTTP Signature for its request. :(

4
1

Log in to comment

Hot Top New Old

Thanks for posting this (and the solution)! It’ll come in handy when I put together my own C2S impl.

 reply
1

@mariusor isn't this what proxyUrl is for? or am i misudnerstanding what you're talking about?

 reply
1
OP

@kopper dunno, might be.

I don't remember seeing that referenced anywhere related to "authorized fetch", and I don't remember what the ActivityPub spec mentions about it.

Maybe it's what I want, I'll have a look.

 reply
1
OP

The way I solved this is terrible.

The client just materializes the Actor's inbox URL by appending "/inbox" to the IRI passed to follow, and then just builds and sends the Follow blindly.

I'm not sure what a client side version of "authorized fetch" would look like sadly.

 reply
1
Insert image