Notices by marius (mariusor@metalhead.club)

@silverpill ok, cool, that makes sense too.

Would it be too much trouble for you to create a minimum example that generates a signature using your libraries so I can adapt it to test on my dev setup?

@marius@marius.federated.id @marius@federated.id

@silverpill damn, I didn't have debugging enabled after restarting the server. I found the request, but the errors are not very enlightening on signature check failure.

Could you do another one please. 🙇

@marius@marius.federated.id @marius@federated.id

@silverpill gaaah!! 😱
Thank you.

The log is just telling me the signature failed verification:

err="actor IRI https://mitra.social/users/silverpill: verification failed: invalid signature: crypto/rsa: verification error"

Did you by any chance update your key recently? (I might use a locally cached version that's out of date, version in cache is since May 2025)

@marius@marius.federated.id @marius@federated.id

> I might use a locally cached version that's out of date

@silverpill it's not that, the key online matches the public key in cache.

Have you tested the key generation against some known vectors?

The only explanation I can come up with is that the signature is somehow incorrect... :(

(On my side I checked the verifier against the test examples given in the RFC9421, so I'm 90% confident the code should work as intended)

@marius@marius.federated.id @marius@federated.id

@david_chisnall as far as I remember Firefox also bundles an LLM with the install (useful at least for in browser translations) but it still manages to keep the size reasonable...

@silverpill when you get a chance, please send another request. While waiting for the upstream to solve the issue, I fixed on my end trying to validate missing nonces.

@marius@marius.federated.id @marius@federated.id

> it's incumbent on you to make the case for it.

@evan I was sure I managed to do that. :D

And so far, I don't think you provided me with any counter-factual arguments that I didn't address.

@hongminhee

@evan yes. I don't look at it as "2 POSTs" though.

I look at it as a "file upload" followed by an ActivityPub Create activity.

If you're looking for one POST request, just have /outbox do the work instead of mediaUpload.

@hongminhee

@evan if you want the simplest mechanism to upload media, why bother with multipart request bodies? Just do what I do in BOX->ONI, use a data URI for encoding the binary, either as Object.Content or Object.URL.

Can you tell me what's the difference between a request containing JSON with a data URI property and a multipart request body?

As far as I can tell the binary data is in both cases base64 encoded, so you're not saving on size, it can be malformed for both cases (but for multipart you now you need an extra check to not save the JSON-LD object if the bin-data is broken), etc...

(this suggestion is not entirely serious, but...)

etc...@hongminhee

> 1) It doesn't include addressing,

As always it's the Clients that are responsible for addressing, therefore the second step should cover it, if the user/client chooses to perform it.

> 2) What happens if the client doesn't post the `Create` activity?

Whatever the server desires: cleanup after a while, keeping the media, etc.
Why do you think it's relevant for the specification itself?

ActivityPub, to my reading, is not about how to *store* content, but about how to *distribute* content.
So after it was uploaded, it's no longer the concern of the spec, unless operated further through other ActivityPub requests.

@evan @hongminhee

@evan to clarify for 1): before the Create is performed, and the media object gets created on the server, the binary data itself is not accessible/referenceable.

@hongminhee

@hongminhee like I mentioned in a thread where Evan and Reiver were talking about this, I think having a mediaUpload that has a very similar behaviour to an inbox/outbox, but with one **small** changed detail is a bad API.

I would prefer there's either a two step process: upload media first, use resulting token in an object create, or use the outbox with for the binary data upload directly... The first one seems saner to me.

@evan I did on reiver's comment on github: https://github.com/w3c/activitypub/issues/578#issuecomment-4366469692

It's a compromise between the current SocialCG proposal, and what I said above.

Do you think it warrants it's own ticket?

@hongminhee

@silverpill the problem is missing nonces even when not specified in the signature-input.

6:33PM WRN Failed to load actor err="verification failed: parameter error: nonce validation failed: nonce already seen" log=auth

I'll review if the error is on my end, or in the library itself. I just realized this is the same issue I had with signatures coming from tags.pub at some point.

I'll probably message you with an update sometime tomorrow. Thank you for giving it a try. 🫡

@silverpill also, what the hell is that Activity? A Like without an object... o.O

@silverpill

I'm not sure which instance you mean, these two actors are different.

@marius@marius.federated.id

@marius@federated.id

The first one is on an instance that should have RFC9421 enabled, but the second isn't.

I enabled request debug on it, if you want to try again.

@evan probably, but the way code is structured I'm using the same client for all requests, including key fetch. I might find a way to separate between Activity requests and key fetches at some point, but until then it's kinda like that.

My logic was that in the case of a public resource most servers would just serve it even with an invalid authorization mechanism... but I guess that if you choose to fail early, that's no longer the case...

@evan in GoActivityPub an invalid signature returns a token "Anonymous" Actor entity that can be verified for permissions against the ACLs of the resource being requested. And in the case of public objects the check succeeds.

Perhaps I got lucky until now mostly relying on my own architecture for both clients and servers...

@evan in the end the Announce activities pushed by tags.pub have started appearing on the server where I had the issues. :D

@evan yep, my client double knocks with RFC9421 and Draft HTTP signatures. Triple knocks actually in the case of key fetches, where the third time is tried w/o a signature.