Chamber3

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

Better guarantees

• Support case sensitivity?

Output format

• 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

Philosophy

• 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.

Standalone chamber-exec?

• 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.