I think you could push the separation of intents further. Make a "AP post" hold all of the metadata, but make the actual text an attachment like an image, video, audio etc.. then you could just store all of the text in blobs in storage to be easily replicated/mirrored and deleted on bulk... "even as ciphertext" requiring the original toot to fetch and decrypt.

also. I think the idea of attaching a user to an instance (domain) was always a mistake. A user should be whoever owns the key material on a frontend (endpoint), and it should be able to ask any "client in your meaning" to be it's new primary location (they can be AP broadcast... user with public key X is now defaulting to client Y)...

BUT all of this is fan fiction, nobody has even solved the storage problem. We're still defaulting to 10,000 S3 buckets.

Turning media URIs from dedicated single URLS to magnet:<hashes> that can be pulled down from multiple locations incase the original dies feels like REALLLLLY low hanging fruit that nobody has touched (and It kind of annoys me nobody has).

I believe ActivityPub API just gives you URLs to follow for prev/next/first/last.

That's actually kinda a database performance thing: by having the IDs sortable by time, you can efficiently shard the database and maintain indexes. Same reason to prefer UUID v7 over v4, as v4 in databases can lead to hotspots

This is exactly what I say in the talk that I still need to record, and why I was working on that ActivityPDS concept last september.

On did:key, you're right that handing over a private key for autonomous server actions is a real problem, and the non-rotatability makes it worse. Though I'd frame that as a limitation of did:key specifically rather than portable identity as a concept—FEP-ef61 mentions other DID methods as candidates, and the broader space of approaches to server-independent identity isn't exhausted by any single proposal.

But agreed that they're orthogonal and can coexist.

I think this exchange has been useful for me in clarifying that we're probably starting from different premises about what C2S is for. If frontend portability isn't the goal, then the case against standardizing the client API makes a lot of sense. I just can't quite let go of the feeling that portability at that layer is what most people imagine when they hear “C2S”—though I'll admit the spec itself is ambiguous enough that neither of us is obviously wrong.

Anyway, thanks for taking the time to respond. Lots to think about.

Your point about making the split explicit at the protocol level is well taken. I can see how that matters especially for extensions: a lot of FEPs end up adding actor-global state for things that are really client concerns, and having a clearer boundary in the protocol might discourage that drift. That's a concrete benefit I hadn't fully appreciated.

On the interoperability question, I think I see where we differ. You're reframing the core promise of C2S as “reuse the same account across different interfaces,” whereas I'd been reading it as “connect any frontend to any server.” Those lead to quite different designs. I'm not sure which framing is more faithful to what C2S originally intended—maybe neither of us is wrong, and the spec was simply underspecified on this point.

That said, if account portability is the goal, I wonder whether C2S is really the right tool for it. FEP-ef61 and the Nomadic Identity approach both tackle that problem more directly, by making identifiers server-independent at the identity layer rather than standardizing the client–server protocol. It feels like a different layer of the problem altogether, and I'm not sure C2S can carry that weight on its own even with your proposed architecture.

The point about AP objects remaining AP objects through hydration is interesting though. I can see how that keeps the pieces composable even without a standardized client API. I'll have to think about that more.