The balance of client/server shared knowledge will always be a hard balance to strike in any protocol ever invented by people.
At least in contrast to email there is a stronger/higher baseline: HTTPS (primarily), transferring primarily one MIME type (application/json) and one "document" format (JSON-LD). The "headers" metadata and "content" are in the same parser format (JSON). That combination alone is far narrower than email protocols (which needs to support nearly any MIME type at any point in any envelope, the headers and content of envelopes have always been different parsers and much of the MIME parsers were bolted in after-the-fact making things worse).
application logic seems to be mostly unspecified, kind of wild west
Other comments in this thread point to the larger "stack" of specifications beyond ActivityPub. ActivityPub itself is just one "layer" in the "stack".
That stack does rely on JSON-LD itself very heavily and many of the clients are in languages where JSON-LD tooling alone is "well-typed" without much in the way of further schemata. I can appreciate where in some static-typed language backgrounds most everything defined as stacks of JSON schemas starts to feel "stringly typed" and idiosyncratic. I don't agree with that sentiment and think JSON in general is far from the worst of "stringly typed", but I appreciate where that sentiment comes from here even if I disagree with it.
I think the surface area overall is a lot narrower than email and many parts of the "stack" are better defined, especially for specific client types. I think there will be some in-theory avoidable problems that resemble the idiosyncrasies with email, but I think in practice they still have a smaller "blast radius" than any similar problems in email.
At least the "stringly-typing issue" seems to boil down to having proper JSON-LD machinery in your language of choice. (In strongly typed languages some code-gen likely.)
Whether a new protocol should really be HTTP-based remains still a question to me. But OK, it's fashionable right now, everybody is doing it, so I can understand why someone would chose to go down this route. HTTP/3 is even quite good (if only a little bit to complex; but that complexity is actually inherent so likely better when it's contained in one place).
I think we have to generally assume HTTPS is the "new Telnet" for protocol bootstrapping and may be so for some time to come. Everyone has HTTPS debugging tools of every level "already installed" (curl/httpie/web browsers/fiddler/etc) and are mostly already trained in them. Every language under the sun has strong HTTPS libraries. Meanwhile, HTTPS gives a nice baseline for things like security (TLS was designed for multiple protocols, but let's face it is best tested and deployed in HTTP and always has been), caching, compression, many quality-of-life and quality-of-service tools. It's so much easier to bootstrap protocols from HTTPS as a baseline than "from scratch like an Apple pie" just as HTTP and Email themselves bootstrapped from Telnet. In the post-TLS era, bootstrapping directly from Telnet doesn't seem like an easy bargain anymore and yeah there are definitely advantages to getting your TLS and a bunch of other useful features/services "for cheap as nearly free" all at once in something like HTTP/3 (even if that is inheriting possibly "a lot of complexity").
Comments
The balance of client/server shared knowledge will always be a hard balance to strike in any protocol ever invented by people.
At least in contrast to email there is a stronger/higher baseline: HTTPS (primarily), transferring primarily one MIME type (application/json) and one "document" format (JSON-LD). The "headers" metadata and "content" are in the same parser format (JSON). That combination alone is far narrower than email protocols (which needs to support nearly any MIME type at any point in any envelope, the headers and content of envelopes have always been different parsers and much of the MIME parsers were bolted in after-the-fact making things worse).
Other comments in this thread point to the larger "stack" of specifications beyond ActivityPub. ActivityPub itself is just one "layer" in the "stack".
That stack does rely on JSON-LD itself very heavily and many of the clients are in languages where JSON-LD tooling alone is "well-typed" without much in the way of further schemata. I can appreciate where in some static-typed language backgrounds most everything defined as stacks of JSON schemas starts to feel "stringly typed" and idiosyncratic. I don't agree with that sentiment and think JSON in general is far from the worst of "stringly typed", but I appreciate where that sentiment comes from here even if I disagree with it.
I think the surface area overall is a lot narrower than email and many parts of the "stack" are better defined, especially for specific client types. I think there will be some in-theory avoidable problems that resemble the idiosyncrasies with email, but I think in practice they still have a smaller "blast radius" than any similar problems in email.
Thanks! This sounds now a bit nicer.
At least the "stringly-typing issue" seems to boil down to having proper JSON-LD machinery in your language of choice. (In strongly typed languages some code-gen likely.)
Whether a new protocol should really be HTTP-based remains still a question to me. But OK, it's fashionable right now, everybody is doing it, so I can understand why someone would chose to go down this route. HTTP/3 is even quite good (if only a little bit to complex; but that complexity is actually inherent so likely better when it's contained in one place).
I think we have to generally assume HTTPS is the "new Telnet" for protocol bootstrapping and may be so for some time to come. Everyone has HTTPS debugging tools of every level "already installed" (curl/httpie/web browsers/fiddler/etc) and are mostly already trained in them. Every language under the sun has strong HTTPS libraries. Meanwhile, HTTPS gives a nice baseline for things like security (TLS was designed for multiple protocols, but let's face it is best tested and deployed in HTTP and always has been), caching, compression, many quality-of-life and quality-of-service tools. It's so much easier to bootstrap protocols from HTTPS as a baseline than "from scratch like an Apple pie" just as HTTP and Email themselves bootstrapped from Telnet. In the post-TLS era, bootstrapping directly from Telnet doesn't seem like an easy bargain anymore and yeah there are definitely advantages to getting your TLS and a bunch of other useful features/services "for cheap as nearly free" all at once in something like HTTP/3 (even if that is inheriting possibly "a lot of complexity").