If an ActivityPub server only receives and sends some opaque BLOBs what's the whole point of it?
There's still a difference between "try to black-box the incoming data as much as possible" and "treat the incoming data as opaque BLOBs and assume". The data is mostly JSON-LD which is a far cry from "binary large objects". It is always going to be "semi-transparent" as it will always be JSON. Whether or not you like the "-LD" extensions to JSON (they are heavy, they do have a lot of RDF baggage you may not desire), they give you a bunch of guaranteed "baseline schema" for the JSON objects that you can use for static typing that might be "good enough" for a lot of "meaningful manipulations" (such as following links to pick up related objects; LD => linking data) and that is all easily transparent.
A lot of the schemas beyond "LD" in ActivityPub are client/application-specific beyond most of the JSON-LD basics and should be easy to treat as a black box unless doing client/application-specific tasks. That's not necessarily "stringly typed", it's kind of a classic "serialization onion": The server at best needs to know that it is JSON and it may have JSON-LD metadata for relevant related linked objects (and a few other metadata fields common to "introspection", similar to "headers"). The client can dig deeper and know it is not just "any" JSON object but a more specific schema for a given class of thing the client cares about.
To be honest, this sounds indeed quite like the mess that email is.
If the server isn't just a "dumb 'BLOB' storage" it will need to handle application logic (sooner or later, as this is actually what servers are for)…
But given that the application logic seems to be mostly unspecified, kind of wild west, where every client application can do whatever it thinks it's users like, this will unavoidably end in all the problems you have with email, where the server needs to know about all the specific details, quirks, and idiosyncrasies of every client ever built.
The whole concept reads like an implementation of "'Postel's Law' fallacy".
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").
You don't seem to have much appreciation for how elegantly handled email is.
I for one have awe & respect for works like Dovecot, which can elegantly decompose a couple different ingress-email pieces of work into special-purpose daemons that each can be scaled & operated independently. The system is practically ancient at this point but a model of how powerful & amazing clearly separated concerns & loose coupled systems are.
You've been persistently negative & calling this all a mess. But it's unclear what you think is elegant & graceful, that does work well. And most of your accusations about things being bad and awful and messy and wild west and postel's law fallacy... none of them have refutable claims. None of them make a position that anyone can argue with. You just spread negativity around & insult thinks in vague terms. It's not very hackerly of you to make a bunch of mean-spirited assertions that arent even backed up enough for anyone else to go verify or test.
Cut the FUD man. Adjust your attitude some. Don't be Mr Rain. Not cool. Be cool.
It's both true than Dovecot is an elegantly designed piece of software and the protocoles surrounding email are a complete mess with decades of bolted on additions and a most used implementation - Gmail - which likes to do things in peculiar ways.
I think the complaints you see here are entirely legitimate. Anyone having been doing this job long enough knows that designing good protocoles is insanely hard and exemples of poorly designed ones in the commercial world abound. It would have been more surprising for the feediverse to get that entirely right than the reverse.
I say that while agreeing with the original comment which points out that a good implementation should solely focus on the specification and leave everything else to the clients.
The application logic is not mostly unspecified, but implementers seriously need to start actually reading the whole thing, and that includes reading the ActivityStreams specs and JSON-LD spec, since it seems like a whole lot of the objections comes from ignoring that there are several more documents to read other than just ActivityPub spec itself even though these documents contain explicit references.
If one were to implement it on top of a RDF database then it isn’t any different than a typical backend taking in SQL (or sparkQL) and spitting out json to the client.
People seem to want to fit a square peg in the round hole and then you have servers bucking over a handful of users.
I spent a day or two looking into this when the hype machine was going strong and it’s really not all that bad (with the right abstractions, I suppose).
Comments
There's still a difference between "try to black-box the incoming data as much as possible" and "treat the incoming data as opaque BLOBs and assume". The data is mostly JSON-LD which is a far cry from "binary large objects". It is always going to be "semi-transparent" as it will always be JSON. Whether or not you like the "-LD" extensions to JSON (they are heavy, they do have a lot of RDF baggage you may not desire), they give you a bunch of guaranteed "baseline schema" for the JSON objects that you can use for static typing that might be "good enough" for a lot of "meaningful manipulations" (such as following links to pick up related objects; LD => linking data) and that is all easily transparent.
A lot of the schemas beyond "LD" in ActivityPub are client/application-specific beyond most of the JSON-LD basics and should be easy to treat as a black box unless doing client/application-specific tasks. That's not necessarily "stringly typed", it's kind of a classic "serialization onion": The server at best needs to know that it is JSON and it may have JSON-LD metadata for relevant related linked objects (and a few other metadata fields common to "introspection", similar to "headers"). The client can dig deeper and know it is not just "any" JSON object but a more specific schema for a given class of thing the client cares about.
To be honest, this sounds indeed quite like the mess that email is.
If the server isn't just a "dumb 'BLOB' storage" it will need to handle application logic (sooner or later, as this is actually what servers are for)…
But given that the application logic seems to be mostly unspecified, kind of wild west, where every client application can do whatever it thinks it's users like, this will unavoidably end in all the problems you have with email, where the server needs to know about all the specific details, quirks, and idiosyncrasies of every client ever built.
The whole concept reads like an implementation of "'Postel's Law' fallacy".
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").
You don't seem to have much appreciation for how elegantly handled email is.
I for one have awe & respect for works like Dovecot, which can elegantly decompose a couple different ingress-email pieces of work into special-purpose daemons that each can be scaled & operated independently. The system is practically ancient at this point but a model of how powerful & amazing clearly separated concerns & loose coupled systems are.
You've been persistently negative & calling this all a mess. But it's unclear what you think is elegant & graceful, that does work well. And most of your accusations about things being bad and awful and messy and wild west and postel's law fallacy... none of them have refutable claims. None of them make a position that anyone can argue with. You just spread negativity around & insult thinks in vague terms. It's not very hackerly of you to make a bunch of mean-spirited assertions that arent even backed up enough for anyone else to go verify or test.
Cut the FUD man. Adjust your attitude some. Don't be Mr Rain. Not cool. Be cool.
It's both true than Dovecot is an elegantly designed piece of software and the protocoles surrounding email are a complete mess with decades of bolted on additions and a most used implementation - Gmail - which likes to do things in peculiar ways.
I think the complaints you see here are entirely legitimate. Anyone having been doing this job long enough knows that designing good protocoles is insanely hard and exemples of poorly designed ones in the commercial world abound. It would have been more surprising for the feediverse to get that entirely right than the reverse.
I say that while agreeing with the original comment which points out that a good implementation should solely focus on the specification and leave everything else to the clients.
The application logic is not mostly unspecified, but implementers seriously need to start actually reading the whole thing, and that includes reading the ActivityStreams specs and JSON-LD spec, since it seems like a whole lot of the objections comes from ignoring that there are several more documents to read other than just ActivityPub spec itself even though these documents contain explicit references.
If one were to implement it on top of a RDF database then it isn’t any different than a typical backend taking in SQL (or sparkQL) and spitting out json to the client.
People seem to want to fit a square peg in the round hole and then you have servers bucking over a handful of users.
I spent a day or two looking into this when the hype machine was going strong and it’s really not all that bad (with the right abstractions, I suppose).
Thank you for articulating this very well, I was getting a bit frustrated at OPs contrarianism. :)