--write-code-to-fd= : machine readable wormhole code

[joeyh]

A GUI application that uses magic wormhole would need to either open a terminal for the user to see the wormhole code, or could parse the wormhole send output to find the wormhole code. Neither option seems ideal. Would it be reasonable to have a mode where the wormhole code is output in a machine readable fashion, eg as the only output to stdout?

(This might be the kind of use case where it'd be better to use the magic wormhole library, but my application is not written in python.)

[warner]

What language is your application written in? I'm eager to see alternate implementations in other languages.

For arbitrary shell-type stuff, you might consider having the GUI application decide upon the code itself (randomly picking channel-id and words), and pass it in, as wormhole send --code=CODE. You'd want to pick a slightly larger channel-id (since you aren't allocating one, you're depending upon randomness to avoid collisions), but 3 or 4 digits should be plenty at our current utilization levels. And if the receiving side isn't using the built-in tab completion, then you could use an entirely different wordlist, so the receiver app would just pass in the pre-formed code to argv.

That said, I think something like wormhole send --write-code-to-fd=5 --text=- could be useful too. I thought I had a ticket for that somewhere, but now I can't find it.

[joeyh]

Haskell. But while a wormhole reimplementation in haskell would be super useful for me, I don't have time to build it right now and am stuck in shell scripting mode, or perhaps with writing a small python script using the wormhole libraries.

I wouldn't mind using my own wordlist, but possibility of channel id collisions seems too problematic.

--write-code-to-fd=5 would be perfect..

[joeyh]

#85 is where --write-code-to-fd= was previously suggested.

[warner]

aha, thanks

[joeyh]

After I filed this bug, and had implemented a hack to parse magic-wormhole's stdout and identify the wormhole code, 72dfb6e changed it to output to stderr. Unfortunately this means that git-annex's magic wormhole integration has been broken for years, and is likely to remain broken for longer since it's unlikely a fix will reach eg Debian stable.

Please please please provide an API for this so further such breakage can be avoided. Otherwise, I may need to reconsider using magic-wormhole.

[warner]

Ah, I'm so sorry.

How hard/disruptive would it be for git-annex to include a small Python program which used the internal Wormhole API directly? That API is pretty stable, whereas the CLI tool's behavior is more up in the air (I know localization is a problem too).

One nuisance is that if you're currently using plain wormhole send (even with --text), you're using a particular protocol (i.e. the set of messages sent over the wormhole connection, and how they're interpreted) that was designed to accomodate sending files too. So the little python program will be more complicated than strictly necessary.

That said, I think the src/wormhole/xfer_util.py utility function might interoperate with the regular wormhole send --text protocol, so maybe the git-annex helper script could just call wormhole.xfer_util.send() and wait for the Deferred to fire. The script around that should only be a few lines, something like (caution, not tested):

from twisted.internet.task import react
from wormhole.cli.public_relay import RENDEZVOUS_RELAY
from wormhole.xfer_util import send
APPID = u"lothar.com/wormhole/text-or-file-xfer"

def main(reactor, message):
    def got_code(code):
        print("code: {}".format(code))
    return send(reactor, APPID, RENDEZVOUS_RELAY, message, None,
                on_code=got_code)

react(main, sys.argv[1:])

The receiving side should be similar. Lemme know if this looks promising, I can help get those scripts get written.