Escaping $-prefixed object keys

[DavidBuchanan314]

Under the atproto data model, "data field names starting with $ are reserved for use by the data model or protocol itself, in both JSON and CBOR representations.". Ok, cool, but what if I want to store a JSON-shaped object from elsewhere, that happens to contain $-prefixed keys? (or perhaps it's an "untrusted" data source that might have $-prefixed keys if someone is trying to be annoying).

I propose a simple escaping scheme. A logical "$foo" object key would be encoded as "$$foo", in both the atproto-JSON representation and DAG-CBOR representation.

I don't have a concrete need for this right now, but as-is, the inability to represent objects with logically-$-prefixed keys strikes me as a "hole" in the atproto data model.

I don't think any code changes are needed to support this, it should kinda Just Work for anyone who wants to do it - But, per the spec:

Applications, extensions, and integrations should not use or unilaterally define new $ fields, to prevent conflicts as the protocol evolves.

I think it would be cool if this $-escaping scheme could be formally blessed (essentially un-reserving the $$ prefix). However, as I mentioned, I don't have a concrete need for it, so I'll just leave this here in case anyone else does.

[bnewbold]

This sounds reasonable. It being just the leading character makes things easier, don't have escaping deeper in the field name. I guess trying to represent two-dollar prefix would be just three-dollars (instead of four-dollars)?

Will want to review and think more carefully before formally updating to the spec though.

There are a couple other places we limit "any old JSON": the most notable being floats not supported in the data model. We also have some best practices around limiting depth of nesting, length of arrays, etc.

[DavidBuchanan314]

I actually hadn't thought about representing two-dollars, but yes, three-dollars would make sense. (and the whole rest-of-string can be left as-is)