Maybe communication got crossways and I’m getting my bits and bytes mixed up. The original memo was a nat64(8 bytes). During the working group I lobbied for at least 256 bits(32 bytes) so we could hold an eth Keccak hash as a reference in the memo as it seems that having enough space to hold a crypto secure hash would be enough for most applications.
Of course a hash isn’t reversible so it isn’t enough for you to hold what you need(29 byte principal plus 8 byte u64….if you get the from principal from the transaction…if icrc-1 and not encoded in the account Id…lots of ifs here.)
An unbounded blob is just hard because someone can blast the ledger. We talked about letting the size be an implementation detail but that seems like a recipe for someone to shoot themselves in the foot.
Nat is unbounded and blob is unbounded so it is hard to codify 256 bytes.
I still think that with the http_request → http_upgrade_request pathway you get what feels like a 1 step process for your users even though two things are happening behind the scenes. The query won’t have to go through plug as you can send it from the anon principal.
The system could probably benefit from some bounded blob types above nat 64.
A page type that was 1024 bytes would be interesting.