Chamber3

Warning

The ideas here are out of date (from 2019) and did not materially impact chamber v3. They are retained for historical purposes only.

Refactor lib

Store.* doesn't really match the usage of the underlying APIs and we end up having to do a lot of contortions to make them fit. One method for speed/low detail/batch and and another for slow/high detail.
The distinction between Secret and RawSecret is too subtle and feels like a leaky abstraction.
SSM v1 (aka no paths) and SSM v2 should be 2 separate stores, or maybe SSM v1 should just be ripped out entirely.
Smaller API (expose fewer things) so we don't have to do the expand-and-deprecate dance so often

There's a use case for limited transforms of keys. Given that Chamber is often used as the entrypoint to Docker containers, and that in those containers having a shell or other transforming utilities might be undesirable, it seems reasonable to allow some basic transforms, namely Upper/Lower, or even a regex-based find/replace.
Sorting

Chamber started as an interface to SSM Parameter Store, and our stance has been that it should be a simple tool and we should avoid adding too many features, like listing ("You can just do it with the SSM cli") or output transformation ("Just use Python"). I think we should relax this restriction a bit. Knowing the implementation details (e.g., key name, export format) of Chamber seems harsh, and some basic functionality to help with that would go a long way.

If we expand the scope of chamber to include more user-friendly functionality, a pared-down chamber-exec binary would be useful for container environments.