Post #2346336

Replies (1)

• @uriel@x.keinpfusch.net 2026-05-07 07:08

  @strypey@mastodon.nzoss.nz I will try to understand where I could contribute. The fact that I know many legacy telco protocols in considerable detail may still be useful, but I also believe that ActivityPub should start looking more decisively toward the future rather than remaining anchored to patterns inherited from the past. If you want my synthetic opinion as a system architect — or, as people prefer to say nowadays, a “platform engineer” — it would be roughly this: “ActivityPub is currently trying to do two things at the same time: it serializes and transports data, while also implicitly describing how the receiving side is expected to process that data — what constitutes a poll, a status, a like, a follow action, and so on. In distributed systems, this pattern already has a well-known name: RPC. From my perspective, the real question is therefore not whether ActivityPub should evolve in that direction, but how. Personally, I think a gradual transition toward a proper RPC-oriented model would make a great deal of sense, and gRPC would probably be an excellent fit for that evolution.” I would honestly prefer a “weakened gRPC” — a pragmatic, federation-friendly RPC model that keeps the good parts of typed contracts, explicit operations, streaming where useful, and clear interoperability rules — rather than continuing with what increasingly feels like SOAP on steroids: verbose objects, implicit behaviours, underspecified semantics, and a lot of hidden procedural meaning disguised as document exchange. One thing I believe ActivityPub could improve significantly is capability discovery. Right now, interoperability often relies on implicit assumptions, observed behaviour, and trial-and-error between implementations. Modern RPC systems such as gRPC usually provide explicit service reflection, feature negotiation, schema discovery, and version awareness. In a heterogeneous federated ecosystem, being able to formally discover which features a remote server actually supports would greatly improve interoperability and robustness, while reducing the current dependence on conventions and reverse engineering. And all of this could be described through a single .proto specification file, explicitly and unambiguously defining the RPCs, their semantics, supported features, and interoperability expectations. Which would end ambiguity. I suspect, this idea would make me quite unpopular there.

  Open ##2346337