Thanks @Christian Bundy, so sbot indeed keeps messages whose suffix it doesn't know.

@keks Upon receiving .boxfffffffffffffff without knowing that format, the db (as well as the in-memory representation) can just store it as "a bunch of encrypted bytes, using the format 2^64 - 1" rather than "a bunch of encrypted bytes, using the format identified by the utf8 string "fffffffffffffff"". This is really just about efficient representation of unknown formats.

I think this would be by far the simplest solution, but if you people disagree, I'm also fine with e.g. a bounded-length alphanumeric suffix. Just as long as it disallows escape sequences, is restricted to the basic multilingual plane (excluding " and control characters to keep json compatibility), and puts a maximum on the length of suffixes, I'm happy.

@Christian Bundy

Also, since we're talking about lookup tables, is this somewhere that we could/should use multiformats? The lookup tables may already exist.

Binary encodings for the ssb multiformats are coming up next, you can get a sneak preview here. But there is no (preexisting) multiformats table for the kind of decryption algorithms ssb private messages need.