Consider type system alternative for stringly typed values

[cdata]

We have a number of cases where parameters are string types: UCAN JWT strings, base64-encoded CIDs/signatures/whatever, DID strings.

The possibility that we might improve the legibility of these values came up in #107 (comment).

Let's discover the best approach to representing these stringly typed values in code and apply this strategy broadly in our code base. Type aliases and newtypes are worth considering, but there may be other alternatives.

[jsantell]

TIL the name for single-valued types (newtypes) -- this looks preferable to aliasing. Some considerations:

• How frequently do our stringly-typed values (STV) use string methods? (Naively, I'd guess "not often")
• Are there STVs that could benefit from other behaviours lifted into the newtype? e.g. DID having a is_valid() method
• Wonder if there's anything we can learn from multiformats, which admittedly are more complicated than our STVs I believe, but mostly provide additional context to some string-ifiable interface.

Some reasons for my preference in not using STVs:

• These simple STVs require a lot of context to interpret, leveraging layers of existing standards -- layers, as in, a single string represents a text-encoding, possibly other codec, semantic meaning e.g. "a DID", as well as possible variants (CIDv1 with Sha256BlakeSomething encoding)
• We re-document in many methods that "The identity is a utf-8 encoded DID string, representing the public key of a sphere" which could be elided into a newtype
• Stronger guarantees in wiring up different noosphere components (a DID string can't be passed to a function wanting a UCAN JWT string)

[cdata]

How frequently do our stringly-typed values (STV) use string methods? (Naively, I'd guess "not often")

We can make the newtypes effectively passthrough for this usecase by implementing Deref<Target = String> for them. For example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e72bf35655119246ede3af5fcc819d46

Are there STVs that could benefit from other behaviours lifted into the newtype? e.g. DID having a is_valid() method

Probably! Especially as we delve into supporting other DID methods..

Wonder if there's anything we can learn from multiformats, which admittedly are more complicated than our STVs I believe, but mostly provide additional context to some string-ifiable interface.

Maybe some good ideas for us to borrow, but my intuition is that these are human-read and human-written identifiers that need a human-readable representation. Even though they are very unpleasant to read, they need to be represented as strings.

As for reasons not to use STVs, no argument against that at all, I'm on the same page.

[cdata]

At this point, I'm going to call this closed as we have deployed a newtype pattern to solve this as of #141