Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UX: Streamlined API for the simplest use cases? #333

Open
nickray opened this issue Jul 8, 2022 · 1 comment
Open

UX: Streamlined API for the simplest use cases? #333

nickray opened this issue Jul 8, 2022 · 1 comment

Comments

@nickray
Copy link

nickray commented Jul 8, 2022

We've been using and recommending age for a "small" use cases, like wrapping/unwrapping sensitive material, where there's only one X25519 or passphrase recipient and a tiny amount of data. This is very nice as the users of the software can easily be instructed to use the age CLI to prepare data, and nobody is rolling their own (combination of) crypto.

For this, instead of using things like std::iter::once and the rest of the top-level example in https://docs.rs/age, it would be great to have simplified (not composable) high-level APIs directly in age itself.

I imagine something like fn encrypt(recipient, plaintext: &[u8]) -> Result<Vec<u8>> and fn decrypt(identity, ciphertext) -> Result<Vec<u8>> as top-level library exports, with a few ergonomic additions to construct appropriate identities and recipients, so users can easily decrypt given a passphrase, or encrypt against say a SSH public key, etc.

Is this in scope for the project or do you prefer to stick with the composable parts and let the user figure out how to combine them?

@str4d
Copy link
Owner

str4d commented Sep 11, 2022

Yeah, this seems useful. The API was simpler in the past, but when the Recipient and Identity traits were introduced in 0.5.0 to replace the earlier enums, the APIs did gain some (needed) complexity.

I do have another significant API refactor planned (to remove the split between recipients and passphrases), but that shouldn't affect an API at this high level.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants