Starting at the end:

Do these additions sound sane?

Um. After my 3rd reading, nothing you've described leaps off the page as unimplementable; but ... having designed and implemented a couple of comms protocols in the past, neither would I expect to detect any flaws from reading the description.

Such protocols are inherently asynchronous, and as such, it is extremely hard to envisage them from wordy descriptions. There are only 3 ways I know of to adequately design/envisage/test a protocol of this type:

• Comprehensive state diagrams.

  These are diagrams showing, in exhaustive detail, the time flow of messages and acknowledgements between commumicating pairs.

  You start with the simple, everything works case:

  Alice                         Bob
  [new msg]  ----------------->
            <----------------- [ack]
  [ack]      ----------------->
  [download]

  Then you introduce fail (non)events:

  [new msg]  ----------------->
  ...
  [new msg]  ----------------->
  ...
  [new msg]  ----------------->
            <----------------- [ack]
  [ack]      ----------------->
  [download]

  Then you introduce fail (non)events:

  [new msg]  ----------------->
            <----------------- [ack]
            ............
            <----------------- [ack]
            ............
            <----------------- [ack]
  [ack]      ----------------->
  [download]

  Then more fail (non)events:

  [new msg]  ----------------->
            <----------------- [ack]
            ............
            <----------------- [ack]
            ............
            <----------------- [ack]
            ............
  [new msg]  ----------------->
            <----------------- [ack]
  [ack]      ----------------->
  [download]

• Not really an alternative to the above (which I think are an essential starting point), but complementary to them, is a simulation.

  Effectively, a slowed-down, high level implementation -- I'd use threads and queues; you could also use processes and sockets, though I think that is harder -- of the real thing; that runs in-box, preferably with a gui front end that allows you to watch the flows and manually break connections, add and remove comms partners, etc. and see what happens.

  The first time I did this, we used a simple console-type screen and ansi escape sequences for the "gui". Three "systems" were the left, top, and right edges of the screen; and we had control "buttons" on the bottom edge.

  Some of the buttons allowed us to single step the "time", so that we could watch the protocol in flow; and others allowed us to block or loose a message or ack, to see what happened. Etc.

• Mathematical modelling. (Warning: I didn't understand and had(have) no real faith in this.)

  The second comms protocol I worked on was effectively the same as things like MSMQ and AMQP; but before they existed. It ran under OS/2, and was designed to allow disparate systems (mainframes, minis, PCs and specialist hardware) within a large Insurance Company, full interprocess communications. I was bought in for my OS/2 expertise (subcontracted, via a bespoke software house, via IBM Global).

  They, the insurance company, had an employee -- an apparently brilliant mathematician -- who's brief took him all over the company to drop in on projects of all types and see what of any insights he could provide. When he dropped in on our project, we were asked to take him through our state/flow diagrams -- they were drawn in a slide show/presentation software package the name of which I forget -- and there were about 150 of them.

  He sat through a 2 hour, highly compressed, slide-show presentation, taking notes, asking a few pointed question and left without giving any feedback. Two weeks later he came back carrying three of those AO-sized easel pads, covered in equations. The notations were unlike anything I'd ever seen before or since.

  He "showed" us how these related to the state/flow diagrams we'd presented. He then showed us 3 separate places where our diagrams did not cover all the possibilities. We (none of us) understood his nomenclature; nor could we relate it back to out diagrams such that we could find the flaws he identified. But, the customer had great faith in the guy, so we had to show that we had both listened and addressed his concerns.

  Since we couldn't understand his stuff; and he couldn't communicate the problems in terms we understood, we offered empirical proof. We set up a dedicated machine running OS/2 and a dozen agent processes that ran continuously, with full logging, initiating random conversations between themselves. Occasionally, (randomly) they would either drop, abort or just abandon conversation. And randomly, a separate process would randomly either kill a running agent; or start a new one.

  That ran for a day and a half before it logged a problem. The mathematician claimed it was one of the three he had warned of. He was vindicated.

  It ran on, non-stop (accept for copying the log files off to free disc space) for another month without either reproducing that error; or producing either of the other two.

  My part of the project was done and I moved on. I never heard what was done about the other two predicted flaws.

  The point of the story is: multi-partner comms protocols are hard. Bugs can lurk deep in them for a very long time before they manifest themselves; and when they do, they can be nigh impossible to reproduce or track down.

"Suggested" messages might also be handy in case when (for some reason I need to think through) two nodes happen to have the same number of messages, but some of the messages differ.

This sounds dangerous to me. The only 'secret' for a good comms protocol I can offer, is keep it simple.

The above sounds very like a case of: "Oh. This might be nice.". And that is (IMO) the start of the rot.

The very moment you start adding things; without having a very clear, real scenario that must be addressed you have started on the slippery slope of either featuritise or futuritise; and that is the very opposite of KISS. As soon as you start down that road; you are on a journey to failure.(IMO :)

Perhaps the best advice I could offer at this point is: Have you really looked at all the existing mechanisms and alternatives?

And the second best is: Keep your communications protocol (the triple handshake stuff) entirely separate from the inbox synchronisation stuff (the binary chop).

The third would have to be: if you go the route of writing this from scratch; mock up your simulation early, and run it hard. And make sure that you can quickly relate the logs back to your state/flow diagrams.

And if that all sounds like I am trying to put you off from doing this all yourself; I kind of am. Because reading your description above suggests that you are conflating the triple-handshake mechanism -- who's purpose as I described it was just for guaranteed delivery -- with the synchronisation mechanism -- which I suggested should be a secondary process.

A major purpose of the guaranteed delivery is that communicating ids should never be in the situation where they have differing opinions of their communications history. Either the message was sent and received, and both ids know that. Or, the delivery failed; and both ids know that.

The synchronisation process only happens between devices owned by the same ID; not between IDs.

I wish I could do a better job of conveying my meaning here; but I hope that this will be of some use to you. However, what you are asking for here is well beyond the scope of the type of help you should expect to get from a forum such as this.