More flexible memo builder

[cbeck88]

One request we've had is that, we'd like to make it easier from a software interface point of view for teams like Moby to start using a new memo type in their app.

This ticket is for a more flexible memo builder for the type 1 authenticated memos.

Recall that, memos have 2 type bytes, and the first byte is a category, and the second byte is a type within the category.

The usecase we want to enable is that:

• For example, Moby team wants to have a new authenticated sender memo, but the 32 free bytes, they want to use in some novel way.
• They would write an MCIP for their new memo type, but they want to be able to start using it without waiting for a mobilecoin.git or SDK release, for faster iteration.

The proposed resolution is:

• Make a more flexible version of RTH memo builder (or possible just extend that builder) to allow that they specify the second byte as a run-time parameter, and inject custom functionality that writes the 32 byte memo.
• The SDK will then wrap and expose this, perhaps with some documentation around this being an advanced feature and that they should write an MCIP before using new memo types on mainnet
• Apps would then be able to make app-specific memos without needing to coordinate engineering work with core team and sdk team.

There was earlier discussion around this in MCIP 60

[stevenspiel]

How does one determine the next available second byte?

[wjuan-mob]

I think that our current design uses the mcips as the source of truth. You can reference

mobilecoin/transaction/extra/src/memo/mod.rs

Line 40 in f8be8e7

//! | 0x0003 | Defragmentation Memo |

for types that have been provided inside mobilecoin, but as types are added by the moby team for example, those would be added in mcips.

[cbeck88]

What we agreed in discussion around MCIP 60 is, you should still write an MCIP if you want to make a new memo and use it in production. You just don't need to wait for SDK or mobilecoin.git to do a release or anything before you can use it in flutter etc.