3 ms·

> 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 inc

> 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.

mariusor 4y ago
Thank you for articulating this very well, I was getting a bit frustrated at OPs contrarianism. :)
still_grokking 4y ago
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".
- mariusor 4y ago
  [flagged]
  - still_grokking 4y ago
    I'm just reflecting on what I've heard here so far. I didn't made up my mind, as for that I would need to study the primary sources myself. Talk is cheap. Even here on HN. But I start to get a kind of picture. And it doesn't look pretty to be honest. That's kind of discouraging and sad. That's not my fault. I'm just trying to understand what people here are saying.
- WorldMaker 4y ago
  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.

mariusor 4y ago

Thank you for articulating this very well, I was getting a bit frustrated at OPs contrarianism. :)

still_grokking 4y ago

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".

mariusor 4y ago
[flagged]
- still_grokking 4y ago
  I'm just reflecting on what I've heard here so far. I didn't made up my mind, as for that I would need to study the primary sources myself. Talk is cheap. Even here on HN. But I start to get a kind of picture. And it doesn't look pretty to be honest. That's kind of discouraging and sad. That's not my fault. I'm just trying to understand what people here are saying.
WorldMaker 4y ago
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.