
Show HN: The Bare Message Encoding - ddevault
https://drewdevault.com/2020/06/21/BARE-message-encoding.html
======
fiatjaf
All my life I've been searching for this thing. I thought my only choice was
either to include the schema in the message (JSON, CBOR, MessagePack) or use
bloated code-generation tools made by Google people who don't care about
simplicity and ease-of-use (Protobuf).

Apparently I was wrong and finally someone invented the Holy Grail of
structured data encoding.

------
cxr
> _stateless tokens tend to be a lot larger than their stateful counterparts.
> [...] Here’s an example: the cursor fields on the new GraphQL APIs are
> stateless. This is one of them: [...] A whopping 141 characters long! It’s
> hardly as convenient to lug this monster around. Most of the time it’ll be
> programs doing the carrying, but it’s still annoying when you’re messing
> with the API and debugging your programs._

This seems to be a consequence of the failure to really grok the Tao of HTTP.
Specifically, the belief that this stuff should be "sequestered" into a blobby
token in the first place is just starting off on the wrong foot and asking to
be frustrated—in exactly the way that the blog post goes on to describe.

Want to deal with authorization and/or authentication concerns? Mandate that
the request carries the right headers. HTTP can already accommodate that, and
if what's in the RFCs isn't a perfect fit for your needs, then extend the
semantics until it can do what you want and then document exactly what your
use case is and how your design solves it.

It's hard to say more, since the post doesn't really include examples of
decoded payloads, i.e., what this is all actually being used for, but in
principle really embracing HTTP is the way to go, rather than merely using
HTTP as the transport layer for a half-baked attempt at RPC.

It reminds me of the really poor design that the Git project settled on for
trying to manage the transition from the legacy "dumb" protocol to the newer
(less chatty) "smart" protocol—opting to probe for support by tacking a query
string on the end of the resource identifier. Except HTTP _already_ has a good
way to do content negotiation, and not all legacy servers respond the same way
to unexpected query strings (i.e., by ignoring them). So the end result is
that you can have a functioning server that fully supports the dumb protocol,
but when you try to push to it with the git CLI, the exchange fails because as
far as the server is concerned, it's seeing the client asking for a resource
that the server doesn't know anything about.

[https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protoc...](https://git-
scm.com/book/en/v2/Git-Internals-Transfer-Protocols)

Perhaps more apropos, in a "general lessons in computing" sort of way, is Chip
Morningstar's anecdote about Fujifilm failing to get the results they wanted
out of Habitat/Xanadu as a consequence of "losing the architecture":

[http://habitatchronicles.com/2004/04/you-cant-tell-people-
an...](http://habitatchronicles.com/2004/04/you-cant-tell-people-anything/)

