Notices by marius (mariusor@metalhead.club)

@silverpill yep. Your bane, more JSON-LD bullshit. :D

@grishka

@silverpill are we allowing Mastodon guide ActivityPub development again, when alternatives exist?

@grishka

@grishka yeah, ed25519 for some of my actors supported by GoActivityPub. (Well, it could be anything that the Go crypto library supports, but only ed25519 is in some use)

@silverpill with the risk of repeating myself: the organization should be the server!11

@silverpill in the context of Mastodon's FEP, perhaps cache poisoning could be a problem, but from the context of ActivityPub, there's no "cache poisoning" because the canonical version of an object is the one the server retrieves explicitly based on its ID, anything else is hearsay and should not be trusted by default.

Also I find very hard to reason about what you call "cache poisoning" when the entity that serves the object is the same with the one that sends the activity.

@silverpill hypothetically the last one is the one I find the most consistent with the way I interpreted the Activity vocabulary spec, and the way I implemented the ActivityPub processing state machine.

@silverpill wrong about thinking that the activity type is the only meaningful information about the side-effect of its reception.

The official specification already has a case where Create/Delete have slightly different logic based on their objects:

https://www.w3.org/TR/activitystreams-vocabulary/#h-motivations-crud

vs.

https://www.w3.org/TR/activitystreams-vocabulary/#h-motivations-relationships

PS. I'm not defending the Mastodon FEP, but clarifying that the underlying assumption of using existing vocabulary for what is basically the same operation, be it on different object types, makes sense.

@silverpill I think you're wrong. It feels perfectly natural that the same activity can be used with different objects. That's the whole purpose of the Activity vocabulary itself being split between activities and objects, isn't it?

And yes, that sometimes means that different side-effects need to be implemented for processing the same type of activity.

@evan I've noticed that the public ActivityPub objects from tagspub are all behind CORS.

Can this be relaxed/removed? For one of my projects that fetches them directly from the frontend, it forces a second request through the proxyURL mechanism when the first one fails due to CORS.

https://metalhead.club/@mariusor/116691230280367219

@silverpill I wonder if this might have been also the culprit for why ONI was failing your otherwise correct RFC9421 signature requests.

:think_bread:

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