stringFromBase64

[jacob-alford]

Would there be value in a stringFromBase64? I think it might even be convertible into a Schema with a refine (tryCatching a btoa or the better version) and an imap

[skeate]

Hmm. What about Base64Of(OtherSchema)? and other things with an -Of suffix (which is completely open to bikeshedding)

The encoded form is just Base64. But you can pass in the schema for the internal type. Something like...

Base64Of(
  JsonStringOf(
    Struct({
      foo: String,
      bar: Number,
    })
  )
)

would decode eyJmb28iOiJhIiwiYmFyIjoxfQ== to { foo: 'a', bar: 1 }. its internal type representation is { foo: string; bar: number }.

Can also do the same kind of thing with Base64Url, Jwt, probably others

[jacob-alford]

Ohh, that's very cool. I was thinking about the direction to go with JsonSchema, and this seems like a great direction.

What's bikeshedding?

[skeate]

Bikeshedding:

Parkinson provides the example of a fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bicycle shed, while neglecting the proposed design of the plant itself, which is far more important and a far more difficult and complex task.

in context I mean it just as "I'm not dead-set on the Of suffix, feel free to suggest alternatives". literally thought about it for 1 second and added it on, to make it not a proposal to replace the Base64 etc modules

[jacob-alford]

Okay, I see. Yeah, I was also thinking in addition to. And Of makes more sense to me because the final type is provided by the consumer

[jacob-alford]

Oooh, and then we could even add a JwtOf 👀 but probably wouldn't be able to do the signature part though.

[skeate]

we could decode it to one of a few states: JwtVerified | JwtInvalid | JwtUnverified -- first two are if the schema includes the secret, last one is if not

[jacob-alford]

Wouldn't we some hash validator libraries for that? At least for verified

[skeate]

ah yeah, would explode the bundle size. We can dependency-inject it; an optional verify function that returns an Either or something. seems like most libraries would return the decoded payload which makes it slightly inefficient (duplicating effort) but 🤷‍♀️

for example, jwt.verify throws if it fails to decode when called synchronously; users can E.tryCatch that

[jacob-alford]

That'd be a good option! And then we don't really need to worry about hash options, or supporting a large number of algorithms

[jacob-alford]

Oooh, this gives me another idea, what about also having some of the basic auth headers included? If we build out the Jwt verification, we might as well also throw in Bearer ${Jwt} and Basic ${Base64(username + ":" + password)} too. Or any others

[skeate]

hmm. Not sure about this. The difference with a JWT is that it can contain information needed to do other things. Basic auth and such don't, really (except when actually doing authorization which we should not touch with a 10ft pole, imo)

[jacob-alford]

We can also make this a v2 target, but I think we could get JsonString(SomeJsonCompatibleSchema) in, and possible Base64(SomeStringSchema) in too

[skeate]

Base64(SomeStringSchema)

technically Base64 doesn't have to be string data; it's any binary data. though in context that really just means "it could also be a number"

[skeate]

extending this further:

FooOf(x) is a runtime X, but decodes from and encodes to Foo. So e.g. the XFromString modules could be reinterpreted as StringOf(X)

[skeate]

with a bit more thought I believe this doesn't really work. in one direction it's fine, since toString exists on everything in JS. but coming from a string we'd have to know a little about the internal schema.

Base64Of and JsonStringOf are fine since we know (and can restrict at the type level) that the internal schema is a string. but we can't do something like StringOf due to ambiguity of the inner type; consider how StringOf(Int()) and StringOf(Boolean()) could work with the same implementation of StringOf

[jacob-alford]

Yeah, that's kind of what I was thinking