Post #2346350
2026-05-07 11:54 UTC
Replies (1)
-
@uriel@x.keinpfusch.net 2026-05-07 12:30
@Profpatsch@mastodon.xyz @strypey@mastodon.nzoss.nz The simple fact that a gRPC call eventually maps to local code does not really change the underlying contract. What matters is that the RPC definition describes clearly what is expected, what is returned, and what semantic guarantees exist between the two parties. What actually happens internally in the receiving implementation is ultimately the responsibility of the implementer on that side. One server may store data in PostgreSQL, another in memory, another may trigger asynchronous workflows internally — but from the protocol perspective, the contract remains stable and explicit. and that’s a good design, because AP is precisely not an RPC system, but a distributed system based on “common conventions” In the end, I think this is largely a matter of definitions. The real question, or at least the question I think should be discussed, is whether ActivityPub would be better expressed as an RPC-style protocol, since RPC seems to cover many of the same requirements more explicitly and with less room for divergent interpretation. From that point of view, the advantage would not be that RPC somehow dictates the internal behaviour of every implementation, but that it makes the external contract much clearer: these are the calls, these are the expected inputs and outputs, and these are the semantics both sides agree on. That would reduce the risk of interoperability depending on “this is my interpretation of the protocol”, which is exactly the kind of ambiguity that becomes painful once different projects start federating beyond the original use case.