Morgan :)

I think the remaining work here is clarifying in the augmentations spec? Thanks.

Macros are fundamentally built on serialization: when you call async methods on the macro API, the macro communicates with the host via serialized data. The hosts we have today are...

I looked into this a little today; I don't like the flatbuffers schema format; one possibility that comes to mind is to use a JSON schema coupled with some more...

Flatbuffers have a [schema](https://flatbuffers.dev/flatbuffers_guide_writing_schema.html) that looks a bit like a proto schema. I played with it a bit, then ran into [vector of unions are not yet supported](https://stackoverflow.com/questions/43667158/flatbuffers-schema-vectors-of-unions) in the...

Yesterday I dug more on exactly what a [JSON Schema](https://json-schema.org/) is/does. My takeaways: - It looks sufficiently powerful to describe what we want, and to evolve the protocol over time...

So with about a day of hacking ... and with some of that spent stuck on a validator bug ... and tweaking the model code at the same time ......

@mosuem good question, thanks :) For users, JSON looks a bit better: it works with more tools (e.g. you can immediately get schema validation in VSCode) and gives a human-readable...

I think it's okay that we own the binary format: it would be not just a serialization format, it's also how the client _uses_ the data, since they don't copy...

I think we have to version any serialization format we use, to guarantee that we don't end up stuck. The expectation though is that the binary format would just be...

Agreed, it'd be nice if we can find one that's a fit. Looking closer at the flexbuffers [implementation](https://github.com/google/flatbuffers/blob/master/dart/lib/src/builder.dart) it really is very close to what we need, with passing in...