Override default deserialization

[jarrvis]

Is there a way to bypass deserialize call after getting data?
https://github.com/Level/browser-level/blob/main/index.js#L135

I need to work with js objects with no encoding. Details here:
https://gist.github.com/saulshanabrook/b74984677bccd08b028b30d9968623f5

I can disable encoding over level's public API but deserialization of browser-level still encodes objects as Uint8Array.

I understand that using level without encoding sounds weird as I may as well just use indexeddb directly if I don't need encodings. I use level to get a little nicer API and browser / nodejs / in memry abstraction.

[vweevers]

We went down this road before, and it wasn't a success (Level/memdown#186 (comment)). It causes compatibility and extensibility issues, removes the ability to swap keys and values (e.g. for indexing use cases) because the key encoding (or lack thereof) wouldn't sort keys consistently, and generally increases code complexity.

At some point in the future I would like to revisit this, but in a different way. Ideally, rather than just using one of 3 predefined encodings (buffer, view or utf8) an abstract-level implementation like browser-level would be able to define its own encodings (like say, the JS structured clone algorithm). In addition, we need a better separation between key- and value encodings (e.g. so that we can throw if keys and values are swapped and use an incompatible encoding). But, we're talking far future. At the moment I'm focusing on features that improve modularity (like hooks) and that's much easier to do with predefined encodings.

If you can explain the use case in more detail, we can perhaps find an alternative solution (I might be reading that gist too quickly, but is it storing encryption keys alongside the ciphertext? How is that secure?)