Hamish Peebles

When there is only a single value being (de)serialized, candid forces you to use a 1 item tuple containing that value. I didn't follow that same pattern here, when there...

> What's the motivation for using a different wire format? This fragments the ecosystem, and is not compatible with the rest of the SDK tooling. You are free to fork...

> > When using candid we couldn't extend enums or add non-optional fields to structs, now that is trivial. > > We are working on the fix to support extensible...

> Could this be used as convenience over `arg_data_raw` and `reply_raw` for skipping unnecessary serialization/deserialization in canisters that proxy calls to other canisters? Yup the (de)serializer could simply do nothing...

We are building a chat app and we want to increase the size of messages which contain only a single emoji. So each time we render a message we check...

What if we added `fn next_available_memory() -> MemoryId`? (Might need to return `Option`) Then against each object that you wish to store in stable memory you could have an `Option`...

I think libraries that use this crate should simply always take the memoryIds as inputs then everything can be controlled by the devs of the main app.

My suggestion was to keep using `MemoryId` exactly as it is now, but to add the `next_available_memory` function solely to handle the case where libraries you depend on are themselves...

Do you have a link to your code? Also, the `reset_memory_manager()` was a temporary thing to move from one version of our code to the next, that may be what...

Hey! Sorry I've only just seen this! You need to add the canister's name to this list [here](https://github.com/open-chat-labs/open-chat/blob/master/backend/libraries/candid_gen/src/lib.rs#L36). Realistically we could remove this list as it isn't actually needed, although...