Post #2346349
2026-05-07 11:34 UTC
@Profpatsch@mastodon.xyz @strypey@mastodon.nzoss.nz
The definition of an RPC system is that the caller has control over the callee, just that they are talking over the network instead of the same process space
Well, I can understand why RPCs are often perceived as being more “control-oriented”, because in practice you are explicitly invoking something like this_is_a_like_please_act_accordingly() inside the callee.
But at the same time, when an ActivityPub message says that an object is a “Like”, what is really happening conceptually? The sender is still expressing an intended semantic effect, and the receiver is still expected to interpret that effect and react accordingly. Soo.... is not an RPC, sure, but the effect is as predicable as an RPC.
So from my perspective, the distinction sometimes feels more about how semantics are described and negotiated, rather than about one model being purely declarative and the other purely imperative.
Replies (1)
-
@Profpatsch@mastodon.xyz 2026-05-07 11:54
@uriel@x.keinpfusch.net @strypey@mastodon.nzoss.nz Oh but that’s not true; from the top of my head the receiver can: 1) drop the information entirely because it does not want to interact with likes 2) accept it and store it somewhere 3) drop it on the floor because the sender is on a blocklist And probably a few more that are entirely valid. There is no real “predictableness” to it, and that’s a good design, because AP is precisely *not* an RPC system, but a distributed system based on “common conventions”