Fred Blundun

O'Reilly lists some options here: http://archive.oreilly.com/pub/post/how_to_write_your_own_iso_stan.html

[This answer](http://security.stackexchange.com/questions/63435/why-use-an-authentication-token-instead-of-the-username-password-per-request/63438#63438) supports my claim above that protection for our API keys doesn't need to be as sophisticated as protection for a human-generated password.

We could even make it possible to upload a schema either without the "self" field or without the path and have the server fill the missing information in automatically.

This all sounds good. I wonder if it would be worth having a system where whenever a schema's version is bumped (e.g. from 1-0-0 to 1-0-1) we have a place...

I think that's a helpful way to think about it. In terms of file structure, we could group test JSONs into 2 categories: 1) invalid-forever, located in com.snowplowanalytics.self-desc/instance/jsonschema/1-0/tests/bad/ 2) valid-from-ADDITION,...

Maybe [json-bigint](https://www.npmjs.com/package/json-bigint) would help?

That sounds sensible to me.