I can see some different ways to solve this problem:
The first one is to make a special custom retraction function that, given a user entity eid, also looks up the other entities that should be retracted according to some rule. This requires quite a lot of discipline in the programming of the update logic.
The second solution is to add a special component attribute, only used for removing related data, preferably multiarity. When a message that refers a used is created or somehow delivered to that user, you also add a link from the user back to the message. Now, when the user entity is removed, the special component attribute linked form the user to message also removes the users messages.
The third solution is to introduce a certain reference attribute (a very generic name could be :entity/owns
) that is not a component attribute, but can be introspected with a special retract-entity function (on the peer side), that looks up all the links of this special attribute and see whether related entities should be removed as well, given a root eid.
A fourth solution is to introduce a special attribute that can mark attributes like :message/user
and give a retract-strategy. When your custom retract-entity function creates retraction data for a certain entity, it also looks for attributes in this entity tagged with some certain retract strategy. Like a more advanced :db/isComponent
attribute.