Proposal: Include "instrument" in plaintext ActivityPub wrappers

So, I've found the source of a frustrating bug. Whenever I send certain messages, I immediately receive a message that I can't decode. It doesn't break the workflow, but it causes frequent errors in the log that I don't want to ignore. The root cause is that my SSE server is immediately delivering my message out to all connected clients -- including the one that just sent the message.

I need a way to filter out message that this client has sent, because they're going to cause errors every time that ts-mls cycles the encryption keys (which appears to be with every message).

My proposed solution is to use the generator property defined in the Activity Vocabulary and already used in our MLS in ActivityPub spec.

I'm experimenting with putting this in the plaintext Create wrapper around the encrypted MLS message. This seems to be what the MLS specs recommend, and I'm looking for two bits of feedback from the team:

1. Does this seem like a good idea? Do you see any problems with putting this cryptographically random (but still uniquely identifying) piece of metadata in the plaintext portion of the message?

2. @mayel Have you run in to this similar problem? Would this solve the issue for you, or are you handling it differently?

Start with the plaintext Create wrapper described in the issue, then review the linked Activity Vocabulary generator definition and MLS in ActivityPub specification. Reproduce the SSE behavior where the sender receives its own message and assess whether exposing the proposed identifier is acceptable. The issue is done only after the team agrees on the approach and defines concrete implementation and acceptance criteria.