Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Monero EPEE
epee is a bespoke serialization format seen within the Monero project without
any official documentation. The best specification is available here.
This library implements the epee 'portable storage' encoding (itself referred
to as EPEE throughout this library), with the following exceptions:
- We don't support the
Arraytype (type 13) as it's unused in practice and lacking documentation - We may accept a wider class of inputs than the
epeelibrary itself. Our definition of compatibility is explicitly if we can decode anything encoded by theepeelibrary and all encodings we produce may be decoded by theepeelibrary. We do not expect completeness, so some successfully decoded objects may not be able to be encoded, and vice versa.
At this time, we do not support:
- Encoding objects
- Decoding objects into typed data structures. For that, please review the
monero-epee-traitscrate.
Instead, we support indexing epee-encoded values and decoding individual
fields in a manner comparable to serde_json::Value (albeit without
allocating, recursing, or using a proc macro). This is sufficient for basic
needs, much simpler, and should be trivial to verify won't panic/face various
exhaustion attacks compared to more complex implementations.
Because of this, we are also able to support no-std and no-alloc, without
any dependencies other than core, while only consuming approximately one
kibibyte of memory on the stack. We also have no unsafe code.
For a more functional library, please check out
cuprate-epee-encoding.