Daniel Loreto

Closing. RFC approved and officially merged.

@conradludgate @MMZK1526 would you be able to send me PRs against our opensource repo: https://github.com/jetify-com/opensource/tree/main/typeid/typeid, updating the README table? Similar to: https://github.com/jetify-com/opensource/pull/314 Much appreciated!

@sloanelybutsurely Thanks for contributing! Three quick things: 1. Due to a quirk of our internal setup, I need to accept the PR in our opensource monorepo and then it'll automatically...

I actually considered using `base64url` as the encoding, but unlike `base32` that encoding is case-sensitive. Because this is written as a general purpose library, I didn't want to pre-suppose the...

Closing, since for the general purpose typeid we'll leave the encoding as is.

The latest draft says that 36 bits are being reserved for the unix timestamp in order to extend the max timestamp until year 4147: https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-02.html#name-uuidv7-timestamp-usage Does that address the concerns?

I think we definitely need a way for applications to define types and easily make those types available. I've been debating two options: 1. Something like you are suggesting, where...

A lightweight runtime is required but it is *bundled* as part of the TySON libraries, so that users of TySON don't need any external dependencies (no dependencies on Node or...

> It'd also be nice to have a comparison with [deno](https://deno.land/), as it [share some similarities with tyson's](https://github.com/jetpack-io/tyson#why). for example, deno runs scripts sandboxed by default, and require fine-grained permission...

A similar question came up here: https://github.com/jetpack-io/typeid-go/issues/5 So definitely open to having the spec define a formal binary representation. Did you already have a particular binary representation in mind?