# Bitwise Storage of Emotes

If we represent each emote as a bit in a binary number, and we know that Rust's biggest unsigned integer is 128 bit, we can store emotes as groups of bit flags per account.

On a ballpark of 1800 different emotes, that's a maximum of 15 storage entries per emoting user per entity they are emoting on - several orders of magnitude reduction from the previous maximum of storing everything.

## How it works

If we assign a binary number's bit to each emote, then flipping a bit can signify that emote's presence on a particular entity, like an NFT or an account.

For example, let's assume we have a 4-bit number and map its bits the following way:

- 1st bit: 💩
- 2nd bit: 🤔
- 3rd bit: 🙈
- 4th bit: ❤

If all 4 emotes are present, the number is 1111 (decimal 15). If none of them are present, it's 0. If only 🤔 and ❤ are present, that's 1010 (decimal 10).

Therefore, it is possible to represent the combination "🤔, ❤" as the decimal number 10 in a `uint128` field.

With 128 bits, we can represent 128 emotes in a single subset of data per user, which means a very emote-active user would have at maximum 15 rows of data (1920 entries) **per entity he is emoting on**, or more if we decide to future-proof for more social-justice additions into existing sets (i.e. put "hands" into one standalone subset even though there's maybe less than 128 now).

---

Pros:

- significant storage and performance savings.
- possible optimization according to usage statistics in reducing the number of row subsets.

Cons:

- loss of time-based granularity (when did Gav emote on Mona Lisa?)
- we need a pallet-hardcoded mapping of emote to subset of emotes to know which subset's bit to flip. This means adding new emotes requires a runtime upgrade.