feat: validate petnames and slugs disallowing an empty string

[jsantell]

No description provided.

[cdata]

One thing that strikes me, reading through this: there are a number of places where "slug" or "petname" is the intended argument, and these are really stringly typed values. For example, if we validate the slug format on writes, we should probably also do it on reads.

We've previously adapted to stringly types by making concrete wrapper types for them. Maybe this is a case where we need a Slug and Petname wrapper type that can only be initialized on a code path that performs validation. Then, we can change all the related signatures to use this wrapper type instead.

WDYT?

[jsantell]

One thing that strikes me, reading through this: there are a number of places where "slug" or "petname" is the intended argument, and these are really stringly typed values. For example, if we validate the slug format on writes, we should probably also do it on reads.

We've previously adapted to stringly types by making concrete wrapper types for them. Maybe this is a case where we need a Slug and Petname wrapper type that can only be initialized on a code path that performs validation. Then, we can change all the related signatures to use this wrapper type instead.

WDYT?

Rationale behind guarding writes and not reads: we could introduce an invalid petname/slug somewhere, and at least we'll be able to query its existence and read/delete it (even in tests). On the contrast, assuming that all slug/petnames are valid internally in non-writes could cause an issue.

Because the values aren't (yet?) restrictive (only guarding against empty strings) or have multiple interpretations (ucan/nsrecord/jwt), I'm bearish on new String-types for Petname/Slug

[cdata]

Filed #385 for potential future exploration here.

[cdata]

Nice, LGTM