Notices by marius (mariusor@metalhead.club)

So on my ONI instance that I've been use as an alternative fediverse profile for myself for about two years, the full storage used is about 3.4G, but out of that there's 2.5G containing mostly the Delete activities of mastodon.social. Crazy.

#mastodev #fediverse #ActivityPubDev #ActivityPub

@dmathieu and a link to where the behaviour is described in the spec: https://www.w3.org/TR/activitypub/#accept-activity-inbox

@silverpill

@toddsundsted "being unable" or "no project has support for them" ?

@silverpill

@silverpill to come back to this, I have added both this example and one of your original requests to the unit-tests, and they both validate correctly.

So I still have no idea why this is failing in production. The only thing I can think of is the http proxy messing with the value of the "target-uri" parameter.

@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.