Post #3153337
2026-05-07 12:41 UTC
@Profpatsch@mastodon.xyz @strypey@mastodon.nzoss.nz
I still struggle to see the fundamental problem here. If this were expressed as RPC, service discovery could simply expose whether a given server supports a method such as FEP_044f_user_allows_quote(), with a clearly defined return value — for example yes or no — and then the caller would decide whether it makes sense to invoke it.
From that perspective, I honestly do not see why this could not be modelled cleanly as RPC. On the contrary, it would make the capability explicit, discoverable, and testable.
It would also avoid the situation where a server sends ActivityPub objects or properties related to a FEP, while the receiving server does not implement that FEP and simply ignores or discards them silently. In an RPC-style model, unsupported functionality is not just an interpretation problem: it is a missing method, a missing contract, or an explicit unsupported capability.
Replies (1)
-
@Profpatsch@mastodon.xyz 2026-05-07 13:15
@uriel@keinpfusch.net @strypey@mastodon.nzoss.nz Yeah, I totally agree that we will need some negotiation capabilities at some point, but I’m doubtful RPC brings anything to the table that normal web standards can’t solve. e.g. the main use-case would be if a server wants to send type NewEvent or type Article and falls back to a Note if the other side does not support it (yet). Maybe gRPC has some mechanisms for including such negotiation, but not all languages have an implementation, whereas everyone speaks json and HTTP