to echo what @mix says, i recommended using the sodium-friends ecosystem because it's actively maintained by our open source friends (e.g. Dat project maintainers), well-documented, and performant.

from the sodium-friends/sodium-native docs:

All methods exposed are more or less a direct translation of the libsodium c-api. This means that most data types are buffers and you have to manage allocating return values and passing them in as arguments intead of receiving them as return values.

This makes this API harder to use than other libsodium wrappers out there, but also means that you'll be able to get a lot of perf / memory improvements as you can do stuff like inline encryption / decryption, re-use buffers etc.

This also makes this library useful as a foundation for more high level crypto abstractions that you want to make.

it's intentionally low-level, so your preferred high-level abstractions can be decoupled from the solid low-level foundation, i think writing helper functions for your situation is a good thing!

i also notice that the crypto module powering Scuttlebutt, chloride, is now powered by sodium-friends underneath: sodium-chloride. so that's another option to use, however it's undocumented and it's only a simple wrapper to be compatible with a previous abstraction so Dominic didn't have to re-write other code.