The appveyor tests were failing because their VMs only have 127.0.0.1,
and stripping it out resulted in an empty hint list, which meant Transit
couldn't work at all.
With increased usage, I'm seeing a buildup of stale channels. Since the
channels aren't properly ephemeral yet (where they get closed as soon as
the last subscriber disconnects), clients which terminate without
calling close() tend to leave the channel lying around. We don't have
"persistent wormholes" yet, so channels should be much more ephemeral
than they currently are.
Apple's stock python doesn't use GNU libreadline, instead it uses BSD
libedit with a readline compatibility interface. The syntax to enable
tab completion is different for libedit. By including both bindings,
autocomplete should work on both flavors.
Closes#37. Thanks to @wsanchez for the catch and the fix.
(one displayed message per received welcome["motd"])
There's not much value in prohibiting the server from sending multiple
MOTD messages, and it would prevent us from using it to display a "your
client is using an old API, please upgrade" message after having already
sent a regular "please donate" MOTD message. (We could send a second
welcome message with ["error"] to kill the client, but ["motd"] is the
most convenient way to deliver a non-fatal warning).
This is an alias for the same host, so it's not really an incompatible
change. The new hostname is my personal domain, and seems a bit more
suitable for this service.
The reasoning is that this string is only ever likely to refer to the
version of the primary/initial client (the CLI application, written in
Python, that you get with "pip install magic-wormhole"). When there are
other implementations, with unrelated versions, they should obviously
not pay attention to a warning about the other implementation being out
of date.
This gives us room in the future to put other keys there, like one which
says we want to use Noise for the phase-message encryption instead of
our current HKDF scheme.
This will be useful for the upcoming "persistent wormhole" mode. A
client might send an allocation request, crash/terminate before
receiving a response, then restart, then re-send the request. If the
server sees a request with the same request_id a previous request, it
can return the same nameplate.
We'll need code changes on both sides to support this (nothing sends or
checks request_id yet), but this lands the schema change early to reduce
future disruption.
