We're still working through some of the finer points on "reliable
delivery", we're also hoping to incorporate some form of flow control.
We have yet to write a full spec of how we envision this mechanism to
work, so if you allow be to be brief, we expect the requirements for
"reliable delivery" to be:
- short term retransmission and acknowledgement of all messages (this
can be done using regular XMPP mechanisms).
- selectively dropping non-essential messages queued for
retransmission if there are any non-trivial transmission delays (e.g.
delta updates, which can be recovered by a receiver using getHistory
on receipt of a commit notification).
- keeping retransmission efficient by only sending of essential
messages over a significant amount of time (e.g. days, weeks,....
months? if a wave provider has gone offline. The retransmission policy
might be similar to what happens with SMTP (*)). Essential messages
would include the last commit notification for all wavelets on which a
provider has users.

(*) One might possibly add an active mechanism on the receiver's part
to query for new waves, however there are a few issues with this. e.g
after being down for a long while, receivers can't know the complete
set of servers to contact for waves without some central authority
informing a provider which providers have waves for whom.

regards,
Jochen