JMAP — reinventing IMAP

> Protobuf doesn't really have a schema.

That's not true at all. https://developers.google.com/protocol-buffers/docs/proto

The schema is not transmitted on the wire. The schema is used to encode/decode on each end.

The raw wire format is numeric tags and values, but no one actually uses protobuf without schemas.

"Reverse engineering" protobufs usually means:
1. Feed a few messages to protoc --decode_raw.
2. Guess the meaning of each numeric tag.
3. Write a .proto file assigning names and types to the tags.

Or, better yet:
1. Yank the protobuf descriptors out of the app binary, which provide the complete schema.

I don't see any .proto files in your repo nor any reference to libprotobuf. Did you reverse engineer from the byte level and write your own decoder?

> Versioning support is mostly non-existant - unknown fields are just ignored

Yes, that's the best way to do versioning, and is exactly the same strategy people use with JSON. Using actual version numbers is a pain as you end up with lots of branchy code to handle every version. That's what Google had before protobuf, and protobuf was explicitly designed to fix it.

Protobuf is better than JSON, though, because with Protobuf you have a schema where you can declare default values to replace things missing on the wire, whereas with JSON you have to check for the existence and type of every single field before accessing it or otherwise risk unexpected exceptions and security bugs.

> and conflicting definitions cause havoc.

In my experience this is not a problem people run into often. You have one owner of the protocol who decides which changes become official. If you want a protocol to be extensible, you use "extensions" which allow third parties to extend the protocol without conflicting (or in proto3 you use the "Any" type).

(Moreover, conflicting definitions would cause an equal amount of havoc for JSON.)

> he wrote that protobuf actually slightly predates JSON and these days they would have just used pure JSON instead.

Sorry, that post was wrong. That's definitely not the opinion held by senior engineers at Google.

1. The importance of type-safety and the implicit documentation provided by schemas is widely recognized inside Google.

2. The vast majority of code at Google is written in statically-typed languages (C++ and Java) where JSON is highly annoying to use due to being dynamic. Protobuf uses schemas to generate classes with pleasant interfaces.

3. Protobuf parsing as-is is responsible for several percent of CPU cycles fleet-wide -- some servers report 30% or more. That equates to many millions of dollars annually. JSON would be an order of magnitude slower, which would cost a massive amount of money.

4. Google stores petabytes of data in Protobuf format. This data would be much larger as JSON. No, compression doesn't magically fix it (compressed protobufs are still much smaller than compressed JSON, particularly for highly-structured (i.e. not textual) data).

5. Similarly, the network bandwidth overhead would be unacceptable.

6. The latency cost of encoding and compressing JSON would be unacceptable for many systems in Google even if there were CPU cycles to spare.