Also, I'm skeptical that two peers can exchange keys without a third party, without being susceptible to man-in-the-middle attacks. But maybe the paper linked in the article proves that it's possible?
https://dominictarr.github.io/secret-handshake-paper/shs.pdf
When I was playing with p2p 20 years ago, I found that NAT traversal was far harder than the messaging protocol (I just copied a few commands from IRC at the time). So hard in fact, that I failed to solve it after 2 years of effort. I realized later that NAT is part of a cluster of problems with networking, the main one being that TCP should have been a layer above UDP (not beside it) and that connectedness was never really a good concept (it should have used identifiers like this instead of IP addresses so the stream survives changing LAN/Wi-Fi/mobile networks). Unfortunately, the article doesn't talk about UDP much other than for broadcasting peer identifiers on the LAN. So I'm not sure how much use this would have in the real world for stuff like game networking, much less state transfer with something like a software transactional memory (STM). I wonder if anyone's made an STM that runs on a readonly transaction log like this, kind of like CouchDB, RethinkDB or Firebase maybe? But I digress.
And I might have used the empty string "" to represent a null hash.. wait I misread that, they use actual null to represent the null pointer in the linked list of message hash addresses, which is great!
Could this be used to build a web of trust? Or is it meant to be more transient, like maybe people broadcast on throwaway identities? Could we drop PGP into this?
Maybe this is more like an RSS feed than something realtime like WebRTC?
Other than that, this seems like a pretty decent protocol, these are just some thoughts/concerns that stood out for me.