Hi Volker,
Thank you for picking this back up.
I continue to have strong concerns about depending on JSON numeric encoding alone to determine whether a number is intended to be an integer or float. The JSON data model is clear in having only a single overall numeric type, and I think we need a more general and robust solution to this modeling problem than relying on observed implementation behaviors. In many situations and use-cases the encoding and distinction is not important, but because atproto is content-addressed, it is important. I think a wrapper encoding like the ‘$float’ option you mention would be more suitable.
In your analysis of implementation behaviors, you noted JavaScript and Go as language ecosystems where special care and configuration is required to ensure consistent encoding behavior. Those are both popular languages in general, and top languages in the atproto ecosystem today. As noted above I don’t think the behaviors of individual JSON implementations are particularly important for making this decision, but it is concerning to me that these languages would not work reliably “out of the box”.
I’m putting together some more specific examples and a counter-proposal to share with the list. I’d love to get feedback on all this from more folks, both atproto developers and IETF community folks. The upcoming IETF 127 meeting seems like a good time frame for converging on a path forward.
–bryan