@[email protected] @[email protected] @[email protected] exactly. Even if an actor was using C2S with cliient-side keys, the server could still MITM by stripping the signatures and re-signing with its own keys. Fedi has no root-of-trust so it's impossible for a remote server to ever know if this happened.

@[email protected] yeah, that's all fair. No good-faith instance should be messing with keys like that. But it is possible with the Fediverse as it currently functions.

@[email protected] true, but that's the case either way. When the server is responsible for key management, it can also decide which actor gets which key. As long as you let the remote servers tell you which key goes with which actor, then you have to assume that the actors don't actually hold their own keys.

@[email protected] @[email protected] to be fair, that's an absolutely absurd amount of space to waste on key management.

@[email protected] could you not implement a denylist based on domain + username?

1. A raw, unverified message comes in.
2. You grab the ID and look up the associated key.
3. The actor key (which is actually the shared key) successfully verifies the object.
4. You introspect the object to get the domain + username pair.
5. You check that against the blocklist.

In fact, I'm like 90% sure this is how Misskey implements blocks.

Ignoring what the specification recommends, could you build a fedi server that uses a single, shared keypair for all actors? Would that even be able to federate, or are there systems out there using key ID as a unique identifier?

#ActivityPub #ActivityStreams #FediDev #FediDevs