Notices by marius (mariusor@metalhead.club), page 2

I just realized that the default specifications for ActivityPub/ActivityStreams do not have a way to perform an update on an object's ID. (ie, moving it from example.com/1 -> example.com/2)

An Update activity does not allow ID updates because it would lose the reference to the original one. (It can be massaged by using an Origin property, but I don't like that).

Another option would be to use a Move activity (which is defined as moving objects between collections), where the Origin property is the object itself instead of a collection. (I like this behaviour better, as it requires less divergence from the spec)

#ActivityPub #fedidev #ActivityPubDev

Is anyone aware of a FEP for that?

#ActivityPub #ActivityPubDev #FEP

There are some implementation details in my storage layers that would prevent this problem from happening, I think. The main one being that the only way to change the public key of an actor is to update the actor itself, the key does not exist as a stand alone object that could be overwritten maliciously.

There might be some corner cases, but I'll try to come up with some tests.

@silverpill I can't really understand your example. The client doesn't have access to other actor's private keys, so it shouldn't be able to sign requests. Or you're thinking for the case of a client that is used by multiple users, *and* it stores private keys...

My clients generally use only OAuth2 for authorization to the service their users belong to and they don't do "signed requests" to other servers (because they don't really have access to the private key in the first place).

@marius

@silverpill the old way is just an Image with summary and name: https://marius.federated.id/uploads/basking-snick

Which then can be set as an attachment to a note.

The new way is slightly more complicated and I upload multiple versions that get set as URL values on an original Image:

https://marius.federated.id/uploads/bread-top-july

This one can also be attached to a note or whatever.

(if you view them in browser you get a raw image for the first, and an html documen for the second) With json+ld accept header you get the raw objects.

@marius

@silverpill so for the Pixelfed use case where usually there are multiple images, I upload them as separate images, and then aggregate them as attachments to a Note.

I think the difference to Mastodon&co. is that for GoActivityPub services, the images are not embedded and exist as stand-alone, dereferenceable objects

@marius

@silverpill and if you remember from last time we talked about stuff, the structure of these operations is decided in the clients, because the GoActivityPub servers are just (mostly)dumb pipes to the web and the rest of the fediverse.

@marius

@silverpill there's no mechanism to stop you updating an actor's public keys, but that breaks an assumption that's being made in the GoActivityPub logic, which is that key rotation is handled out of band using CLI tools that handle both the private key and update the Actor.

So, after such an update there would be a mismatch between the private key used by the internals of the library and the key retreived by other servers to check.

I haven't found a clean way to do this operation with a better UX sadly, so CLI is all we have.

@marius

@silverpill the reply above is for Updates, but for Create, usually we send the actor without any key and the server generates a key pair automatically.

@marius

@silverpill and this happens because the purpose of the library and all the reference tooling around it is to deal with ActivityPub and only that. There's no additional APIs (well, except for all the CLI stuff I just mentioned :D) that can make the the client/servers have better UX for key rotation.

Nothing prevents users to invent their own mechanism when they use it though.

@marius

@evan no joke.

I think that adding new properties holding only specific types of activities/objects is not a clean way of doing it.

What happens when I want to support EmojiReaction activities? Do I need to enhance all supported object types with an /emojireaction property?

I would see a FEP to obsolete /shares and /likes in favour of /reactions that can contain any number of activities (Announce, Like, Dislike, etc.)

@evan I don't like that to be honest. :D

@evan do you know is there an agreed upon opinion in the #ActivityPub working group (or in in the fediverse at large) if `Dislike` activities should be added to an object's likes collection?

#fedidev

@silverpill @marius my message above was about the recipients properties of actor/objects.

If your actor doesn't have a to/cc that includes the Public collection, it would be filtered out from collections that include it.

It's not about being accessible through HTTP.

> Negligence at Tea Puts 13.000 Women in Danger

@rysiek totally agree, but the people that released the information are definitely guilty of a lot more than just being incompetent, they're actively and unequivocally assholes... please let's try not to lionize them due to some misguided sense of pedantry about what hackers are or do.

There is such a thing as responsible disclosure after all.

I hope that the peeps on metalhead.club, and any other metal heads on the fediverse, know about the second version of the metal releases bot @RattleHead whose posts contain embeds from BandCamp for the daily posts?

(Sadly they're not showing up on Mastodon, but they're there.)

Here's today's: https://releases.bruta.link/releases/2025/July/18

#metal #metalhead #metalheadclub

@rimu well, the library I'm working on has support for C2S, also the reference server built with it: https://github.com/go-ap/fedbox

@rimu this looks good.

I had trouble picturing your suggestion because I still have trouble thinking of ActivityPub S2S as a separate protocol from C2S, and as such I think of Activities as something only the actor themselves can create using their client.

So when I was thinking about activities with batched objects from multiple actors my brain broke. :D

This being only about servers announcing batches of activities to other servers as a communication back-channel makes more sense.

(I'm still unclear why the announce activities are needed, shouldn't the original activity already have reached all servers? but I feel like that's a lemmy problem rather)

> However, the remote server might not know how to deliver the activity to private recipients, or recipients within a collection. The multibox endpoint removes this knowledge requirement from the receiving server and instead makes the sending server responsible for marking inboxes to explicitly deliver to.

@silverpill I think needs clarification, it's not obvious to me how *another* end-point that you need to know about and needs to be discovered makes things better than plain old sharedInbox. The large combination matrix that
@rimu mentions, is not really so apparent for activities that aren't addressed to the public collection IMHO.

@smallcircles

@rimu any textual documentation for this? Video is not my preferred format for technical stuff. :D