WebOfTrust
Define how to mix serializations in embedded messages
EXN
The exn (exchange) message allows embedding other messages. But when the serializations do not match between the version strings we may have problems.
Need to review how to handle the mismatches. in the exn message version string verus embedded message version strings
Key State Notification
A related issue is the key state notification (also the tel state notification tsn). We store it in the database serialized but it is not an over the wire message and must be embedded in a reply (rpy) message, but then the version string for the data base serialization might be a mismatch. Seems like support for the version string is too much flexibility just for saving to the database when its just a notification not an actual event.
Maybe we get rid of the version string in key state notifiction and just always store it with the JSON. Or we promote the ksn to a full over the wire message so it is not embedded in a reply or both.
The complication with the KSN arose when we went to saidify all messages. We did not saidify the ksn but left it with a version string. So its a special corner case of a message without a message type without a said of itself (only a reference to the said of the assoticated key event) but with a version string. But we don't need the flexibility of a version string if its not an over the wire message only for database serialization and with the added complexity of not being saidified it is even more of a special case. One approach would be to convert the key state notice in the database to a dataclass and use a Komer instance instead of the current SerderSuber (see Baser.states)
Solution is to not embed messages but to attach them. For ACDCs and exns this is the current approach for for Forwarded key events and other in EXNs they are embedded and therefore must have the same serialization kind.
In order to attach effectively embedded messages and to also simplify the parsing logic we need a new pipelineing attachement count code that includes Serder messages so the parser knows to switch to searching for version strings instead of CESR codes (i.e needs to sniff the body of the count code.
With this we can change the forwarding logic to always attach the forwarded message to the exn that is the forward so that the parser knows to keep parsing the attached forwarded message and then process it in line with the prior exn that is the forwarding exn.. This is important because the forwarded message serialization is fixed for an event message (can't be changed later). So either the exn serialization must be selected to match what is embedded or we must attach. Its more flexible to attach.
For confidential SPACified messages we must use a hybrid approach
We then use a hybrid approach for SPACifying messages.. Use generic comm context messages to embed confidential messages and their attachments. The wrapper messages are generic and can wrap other embedded messages. In this case the wrapped messages and the wrapper must use the same serialization but we make the wrappers very light weight. So the wrapper serialization is always chosen as a function of the wrapped serialization. Where possible, i.e. does not leak correlatable identifiers, we can use attachments instead of embedding.