I thought about self-organizing messages as well, although the ideas I'm presenting here use a more explicit approach. I am new to the scuttleverse and its concepts, so there might be some obvious flaws in my thoughts. Anyways, here we go:

Nearly everything in the scuttleverse is identified by a unique hash. Message types however use strings as a type. Some quotes from the scuttlebot documentation:

There is no official mechanism for making sure message-types interoperate, except for the documentation which you're reading here. As it becomes clear that new types are coming into common use, we'll add them to this site.

Manually posting information about the intended use to a central place seems primitive compared to the scuttlebot architecture.

To avoid accidental collisions with other applications, it's a good idea to add your org or application name (or both!) to the message type.

We are using a system where everything is uniquely identified by a hash, but the fundamental building block of all communication relies on namespacing?

This seems to be such a fundamental decision, that I'll just assume you had good reasons to chose the current system instead of hash message types. But even with string identifiers, it would be nice to come up with a self-organizing system. The meaning of messages should not be dictated up-front, but rather through their usage. One way of achieving this, would be to represent message types and message consumers (e.g. frontends like patchwork, or maybe patchbay plugins/modules) in the scuttleverse. Just like smalltalk uses objects to represent language concepts themselves (classes, control-flow, etc.) at runtime, the scuttleverse could use messages to represent message types and consumers.

For example, somebody might add a message-entity to the scuttleverse, which represents a move in a tic-tac-toe game. This entity consists of nothing but its identifier. Next, I might write a GUI frontend for playing tic-tac-toe via scuttlebut. I'd add a consumer-entity to the scuttleverse, which represents the frontend. This entity can refer to the tac-tac-toe message-entity, and claim that it uses the following fields of such a message: game, àctivePlayer and position. Additionally, the consumer-entity could provide human-readable information about how it interprets these fields. Of course, nobody forces me to set up the message-entity, or to be truthful in which fields it claims to use.

Other consumers might expect different fields in a tic-tac-toe message, or they might only consume a subset of fields. Every tool can still interpret messages as it sees fit. But by querying which tools accept which messages, and what they expect of these messages, we get a self-description of the system.

Another interesting dimension to this is that users could publish statements such as I use these consumers to handle this message-entity. This gives credibility to the message-consumer's claims on how it deals with messages. At this point, we could build some pretty interesting (and useful) features for scuttleverse clients. If a friend sends me a message, but my client does not know how to handle it, it could look up which consumer the friend would use to handle the message. Then, it could recommend me to install this consumer. This would be especially powerful for plugin-based clients (i.e. patchbay).

Finally, the message types for describing message-entities and message-consumers would be message-entities themselves. There is no need to add any of this on the protocol level, you would just add some messages. Which happen to be interpreted as a meta-description.

Nobody would be forced to use this, you could simply ignore the whole thing. I just believe that having a self-aware, reflective ecosystem of message-entities and message-consumers would make for a healthy, robust and extensible system. For example, if you want to write an alternative frontend with overlapping functionality with other frontends, you can query the system itself on how existing messages should be handled, rather than looking up disparate sources of documentation.