my only warning against aeron is that it’s a transport, and rather focused on Java (+ a c++ implementation).
Messaging wars is, however, a real thing. Perhaps, one should not jump right in immediately. Indeed, there are many distinct layers to messaging. Addressing things, transport and messaging patterns are three dimensions. Message serialization and deserialization another. Delivery guarantees, retries and other aspects come on top.
The number of option combination is enormous. As TBP has limited resources, I’d go with options that don’t require too much implementation, while delivering most value. To make sure, one doesn’t kill future options, I’d never couple to a specific messaging system (see e.g. Hexagonal Architecture @ Netflix).
From the standpoint of application code, the most it needs to know is an api in the form send(message), where, if necessary, an identity of a peer or a channel could be explicit, if necessary: send(where, message). The rest is “infrastructure”. Assuming, correct error handling, of course.
When going this route, the messaging implementation can be replaced, e.g. swapped for local testing without additional infrastructure.
Addressing remote actors can be as simple as naming them, e.g. in static configuration or some form of registry.
For deciding on the messaging patterns I’d really recommend to look into the patterns described for zeromq as these generalize independent of the programming language.
As for simple options that have enough implementations in various technologies, brokered: NATS seems to be the current runner-up, while brokerless or with hand-written brokers, zeromq is a safe cross-language choice. If one does choose the erlang way, no infrastructure is necessary, because erlang native clustering provides discovery, addressing, and, of course, messaging. Whatsapp seems to know how to scale an Erlang cluster to 10k Nodes, meaning 10k nodes of potentially millions of processes each. Partisan is another planet-scale approach. That should be good enough for now, and running a small cluster is part of the demo in my initial post 
.
Standards like MQTT or AMQP are good but with added complexities, which one would initially probably not need. With ports&adapters (“hexagonal” architecture), one can always switch to a more complex messaging infrastructure later.
Perhaps, one note on message guarantees. The brain is wet-ware, so, physically, there’s no delivery guarantee of messages. Even interference is highly likely to happen. Thus, perhaps, complex features, such as delivery guarantees are not as important for distributed Monty, as these are likely to couple that implementation detail, potentially closing the door on creative robust voting algorithms.
