Reasons for the forking (or we should say reseting)

For the sad reasons that we all know about, bincode has leaved us because of those who has doxxing the original developers.

Apich Orgnisation strongly opsite any type of doxxing and will not tolerate it. (We also suffered from these kind of events before but only for our personal interest reasons) But in any sense, we respect the original developers and their work.

For the dependency issue of RSSN and the bigger Rust community, we have decided to fork the project and continue the development. The project will be renamed to bincode-next and will be hosted on GitHub and Codeberg.

Special disclaimer

We fully respect the any copyright notice from the original developers.
We will not tolerate any form of doxxing or harassment.
We will not tolerate any form of discrimination or hate speech.
We will not tolerate any form of plagiarism or copyright infringement.
As one of the mission of Apich, we will continue to test the edges of the current AI system assisted coding and development. Discussions on that is welcomed but only without hate.

Original develop teams' last messages

Due to a doxxing incident bincode development has officially ceased and will not resume. Version 1.3.3 is considered a complete version of bincode that is not in need of any updates. Updates will only be pushed to the in the unlikely event of CVEs. Do not contact us for any other reason.

To those of you who bothered doxxing us. Go touch grass and maybe for once consider your actions have consequences for real people.

Fuck off and worst regards, The Bincode Team

Original readme continues below

Bincode

A compact encoder / decoder pair that uses a binary zero-fluff encoding scheme. The size of the encoded object will be the same or smaller than the size that the object takes up in memory in a running Rust program.

In addition to exposing two simple functions (one that encodes to Vec<u8>, and one that decodes from &[u8]), binary-encode exposes a Reader/Writer API that makes it work perfectly with other stream-based APIs such as Rust files, network streams, and the flate2-rs compression library.

Usage Manifesto

The bincode developers do not endorse or support: the gas and oil industry, gambling, the military industrial complex, or any usage of AI. This means we will not accept any contributions coming from or related to these fields. This includes both PRs and filed issues. If you fall in one of these categories; do better.

Additionally, if any contribution you make makes use of generative AI, be it in code or PR/issue descriptions, you will be immediately banned from this organization.

API Documentation

Bincode in the Wild

google/tarpc: Bincode is used to serialize and deserialize networked RPC messages.
servo/webrender: Bincode records WebRender API calls for record/replay-style graphics debugging.
servo/ipc-channel: IPC-Channel uses Bincode to send structs between processes using a channel-like API.
ajeetdsouza/zoxide: zoxide uses Bincode to store a database of directories and their access frequencies on disk.

Example

use bincode_next::{config, Decode, Encode};

#[derive(Encode, Decode, PartialEq, Debug)]
struct Entity {
    x: f32,
    y: f32,
}

#[derive(Encode, Decode, PartialEq, Debug)]
struct World(Vec<Entity>);

fn main() {
    let config = config::standard();

    let world = World(vec![Entity { x: 0.0, y: 4.0 }, Entity { x: 10.0, y: 20.5 }]);

    let encoded: Vec<u8> = bincode_next::encode_to_vec(&world, config).unwrap();

    // The length of the vector is encoded as a varint u64, which in this case gets collapsed to a single byte
    // See the documentation on varint for more info for that.
    // The 4 floats are encoded in 4 bytes each.
    assert_eq!(encoded.len(), 1 + 4 * 4);

    let (decoded, len): (World, usize) = bincode_next::decode_from_slice(&encoded[..], config).unwrap();

    assert_eq!(world, decoded);
    assert_eq!(len, encoded.len()); // read all bytes
}

Specification

Bincode's format is specified in docs/spec.md.

FAQ

Is Bincode suitable for storage?

The encoding format is stable, provided the same configuration is used. This should ensure that later versions can still read data produced by a previous versions of the library if no major version change has occurred.

Bincode 1 and 2 are completely compatible if the same configuration is used.

Bincode is invariant over byte-order, making an exchange between different architectures possible. It is also rather space efficient, as it stores no metadata like struct field names in the output format and writes long streams of binary data without needing any potentially size-increasing encoding.

As a result, Bincode is suitable for storing data. Be aware that it does not implement any sort of data versioning scheme or file headers, as these features are outside the scope of this crate.

Is Bincode suitable for untrusted inputs?

Bincode attempts to protect against hostile data. There is a maximum size configuration available (Configuration::with_limit), but not enabled in the default configuration. Enabling it causes pre-allocation size to be limited to prevent against memory exhaustion attacks.

Deserializing any incoming data will not cause undefined behavior or memory issues, assuming that the deserialization code for the struct is safe itself.

Bincode can be used for untrusted inputs in the sense that it will not create a security issues in your application, provided the configuration is changed to enable a maximum size limit. Malicious inputs will fail upon deserialization.

What is Bincode's MSRV (minimum supported Rust version)?

Bincode 2.0 has an MSRV of 1.85.0. Any changes to the MSRV are considered a breaking change for semver purposes, except when certain features are enabled. Features affecting MSRV are documented in the crate root.

Why does bincode not respect `#[repr(u8)]`?

Bincode will encode enum variants as a u32. If you're worried about storage size, we can recommend enabling Configuration::with_variable_int_encoding(). This option is enabled by default with the standard configuration. In this case enum variants will almost always be encoded as a u8.

Currently we have not found a compelling case to respect #[repr(...)]. You're most likely trying to interop with a format that is similar-but-not-quite-bincode. We only support our own protocol (spec).

If you really want to use bincode to encode/decode a different protocol, consider implementing Encode and Decode yourself. bincode-derive will output the generated implementation in target/generated/bincode/<name>_Encode.rs and target/generated/bincode/<name>_Decode.rs which should get you started.

bincode-next 2.0.3