Resolutions

If you want to skip all the ruminations and sketches, I'd say at the moment, I'm feeling "Sketch 3" is probably what's looking like the most fruitful direction at the moment.

But it's not fully settled.

Ruminations

There's been a tug-o-war between simplicity and utility going on here.

If inputs can be strings, it... seems like a noticeable simplification to the whole system.

(And if inputs can be just strings, it's also a significant readability increase.)

But some inputs get complex enough that going for a struct with map serialization seems desirable.

Maybe we should consider a moderate third option, which is a keyed union, string for most things (and a stringprefix union inside there), and a struct with map representation otherwise, which is just ComplexInput, and still contains most of it as a string, but then adds an options/detalis map.

Something worth keeping in mind with these is extensibility. Going super rich with unions (e.g. all the way down to TarInput vs GitInput, and a big stringprefix union for those) could be nice in one respect, but also doesn't seem to make extensiblity feel much better. (It's not worse, either. This is a vibes thing.)

Contributors to the simplicity direction in the tug-o-war:

• Just, literally, simplicity.
• Able to copy-paste in one hunk is nice.
• Being able to print out a single string. Means we can use these in log messages without fear.
• Remember, there's also a lot of times we turn around and use these as map keys — the catalog mirrors info does this in some places.

One major contributors to the tug-o-war in the complex direction:

• Anything to do with gosh-darn posix permission overriding. Cramming that into more and more options strings is possible but becomes increasingly gross.
  • Especially gets complicated because if we try to have them preface the hash component... just the sheer way it gets serialized gets odd. (Wrapper types, unions where you probably didn't want them, etc? Or a mid-string optional — but no, because IPLD Schemas doesn't really care for that.)
    • Then again, the only reason to want to have them prefix the hash component is because we're also considering having a "literals" feature that abuses the "hash" component for content.
• The idea of having "literals" as a form of input. If they're gonna have big content, it becomes problematic.
  • Possibly desirable to have a separate field for them that's not all stringjoin, just because. Also for multiline purposes.