This requires a DB delete/recreate when upgrading. It changes the server
protocol, and app IDs, so clients cannot interoperate with each other
across this change, nor with the server. Flag day for everyone!
Now apps do not share channel IDs, so a lot of usage of app1 will not
cause the wormhole codes for app2 to get longer.
This removes "side" and "msgnum" from the URLs, and puts them in a JSON
request body instead. The server now maintains a simple set of messages
for each channel-id, and isn't responsible for removing duplicates.
The client now fetches all messages, and just ignores everything it sent
itself. This removes the "reflection attack".
Deallocate now returns JSON, for consistency. DB and API use "phase" and
"body" instead of msgnum/message.
This changes the DB schema, so delete the DB before upgrading the server.
The main wormhole code is str (unicode in py3, bytes in py2). Most
everything else must be passed as bytes in both py2/py3.
Keep the internal "side" string as a str, to make it easier to merge
with other URL pieces.
Just make up a code like NUMBER-STUFF, and add --code= to the
send-text/send-file command. Also don't use tab-completion on the
codewords part of the receiving side, unless you stuck to the even/odd
PGP wordlist. (tab still works for the channel-id).
This is a proxy for the other client's version, and encourages both
sides to upgrade to the current version each time the server is
upgraded (which will be once per release).
To be useful, both sides must add -v. If the sender uses -v but the
receiver doesn't, the receiver won't show the verification string, so
the sender can't compare it to anything (and must either abort the
transfer or accept it blindly). Maybe the receiver should show the
verification string unconditionally. Maybe the sender should
indicate (in unprotected plaintext, along with the PAKE message) whether
the receiver should show it or not.
