The Case Of The Disappearing Wave Server

There has been a lot of discussion on the wave protocol group about what happens when a wave server goes down. The standard reply to this is that the wavelet's current state can be copied as the start of a new wavelet. There are a few issues with this however such as the loss of history and that there would now possibly be two wavelet's within the same wave that are the same (straight after the copy). Possibly a better solution would be to re-home the wavelet into another wave server, this will be explored through this post.

For the purposes of the rest of this post the following wave structure will be assumed (unless otherwise stated):
Initial wavelet: firstwsp.com/waveid/wavelet1
-> created by bob@firstwsp.com
-> add participant john@secondwsp.com
-> add participant sue@thirdwsp.com

Second wavelet: secondwsp.com/firstwsp.com$waveid/wavelet2
-> created by john@secondwsp.com
-> add participant bob@firstwsp.com

Third wavelet: secondwsp.com/firstwsp.com$waveid/wavelet3
-> created by john@secondwsp.com
-> add participant sue@thirdwsp.com

Note: in the above descriptions the wave-name is listed after the ":". The wave-name is in the form <wavelet-domain>/<wave-domain>$<wave-id>/<wavelet-id> or <wavelet-domain>/<wave-id>/<wavelet-id> when the wavelet domain and wave domain are equal.

So the scenarios that I think need to be considered are:

1. firstwsp.com has an outage
2. firstwsp.com's business shuts down
3. secondwsp.com loses connectivity to firstwsp.com
4. bob moves from firstwsp.com's service to secondwsp.com's service

In all of the first 2 scenarios neither john@secondwsp.com or sue@thirdwsp.com would be able to write to the initial wavelet, and the third would stop john from writing to the initial wavelet as well. However they would both still be able to access the wavelet. The other wavelets in the wave are always still editable due to another host other than firstwsp.com being the authoritative server on those wavelets.

I think that the first scenario requires no action. If a certain wave provider is having a short outage then the wavelets that they host will have to be uneditable for the period of the outage. The reason that this is the best for this scenario is that from secondwsp.com's point of view there is no difference between scenario 1 and scenario 3.

Scenario 2 is a difficult one. Once firstwsp.com is out of business how do we move the wavelets that are authoritatively hosted there off? This is the "pull case". Compare this to scenario 4 where the user is making the choice to move off the service, this is the "push case".

What is required to re-home the wavelet for the push case? If the authoritative wave server allows the user to issue a wavelet-move message then what would be required for that message to take effect. Each secondary server would be required to change where it sends later messages to, and to accept the new server as the authoritative server for updates. The biggest issue I would see with this would be around the security side.

What options are there for the pull case? This seems the harder case.

I think I am asking more questions here and answering none, but I am still thinking through this myself. The one thought that I have had is that this may be impossible to fix 100% without the wave federation protocol being a non-centralised pair-to-pair protocol.