@Marius I think they do it for compatibility with Mastodon. How would you represent a photo-post? An Image? Or a Note with image property?
Conversation
Notices
-
Embed this notice
silverpill (silverpill@mitra.social)'s status on Monday, 04-Aug-2025 01:33:41 JST
silverpill
-
Embed this notice
silverpill (silverpill@mitra.social)'s status on Friday, 08-Aug-2025 22:17:57 JST
silverpill
-
Embed this notice
silverpill (silverpill@mitra.social)'s status on Saturday, 09-Aug-2025 03:44:20 JST
silverpill
@mariusor @Marius The problem with submitted public keys is that client controls the secret key. It can make signed requests and retrieve private objects, bypassing the server.
If the owner is not verified, the client can impersonate other actors on the server and retrieve private objects that are accessible to them but not to the current user (e.g. DMs).
-
Embed this notice
marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:22 JST
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.
-
Embed this notice
marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:23 JST
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.
-
Embed this notice
marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:25 JST
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.
-
Embed this notice
silverpill (silverpill@mitra.social)'s status on Saturday, 09-Aug-2025 03:44:32 JST
silverpill
>GoActivityPub servers are just (mostly)dumb pipes to the web and the rest of the fediverse.
Oh, I have a question regarding this. How do you deal with public keys in client-generated activities?
For example, can I Create an object with publicKeyPem property where I am the owner?
What if the owner is another actor? -
Embed this notice
marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:33 JST
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.
-
Embed this notice
marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:34 JST
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
-
Embed this notice
marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 03:44:35 JST
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.
-
Embed this notice
silverpill (silverpill@mitra.social)'s status on Saturday, 09-Aug-2025 04:39:00 JST
silverpill
{ "type": "Create", "actor": "https://social.example/actor1", "object": { "type": "Key", "owner": "https://social.example/actor2" "publicKeyPem": "..." } } This key is created by actor1, who controls the secret key. But it is owned by actor2. This means actor1 can sign requests using the secret key and everyone will think they are signed by actor2.
-
Embed this notice
marius (mariusor@metalhead.club)'s status on Saturday, 09-Aug-2025 04:39:02 JST
marius
@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).
-
Embed this notice