This will be platform-specific.

For Linux:

• ask PyPI what the latest version of "tahoe-lafs" is
• download the distribution and .sig from PyPI
• check signature
• make sure signature's public-key is the same as one in tahoe-gui's source
• create virtualenv
• "pip install" install package from PyPI into the virtualenv

For OS/X:

• figure out latest version (how?)
• download distribution + sig (from where?)
• check sig
• check sig's public key
• install (how?)

For Windows:

• figure out latest version (how?)
• download distribution + sig (from where?)
• check sig
• check sig's public key
• install (how?)

Link is broken to dmg - > https://buildbot.gridsync.io/packages/Tahoe-GUI.dmg

on ubuntu yakkety in a virtualenv I get the following traceback

$ python3.5 -m pip install git+https://github.com/LeastAuthority/tahoe-gui.git
[snip]
$ tahoe-gui 
Traceback (most recent call last):
  File "/home/arthur/.virtualenvs/tahoe-gui/bin/tahoe-gui", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/home/arthur/.virtualenvs/tahoe-gui/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2976, in <module>
    @_call_aside
  File "/home/arthur/.virtualenvs/tahoe-gui/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2962, in _call_aside
    f(*args, **kwargs)
  File "/home/arthur/.virtualenvs/tahoe-gui/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2989, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/home/arthur/.virtualenvs/tahoe-gui/lib/python3.5/site-packages/pkg_resources/__init__.py", line 660, in _build_master
    ws.require(__requires__)
  File "/home/arthur/.virtualenvs/tahoe-gui/lib/python3.5/site-packages/pkg_resources/__init__.py", line 968, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/home/arthur/.virtualenvs/tahoe-gui/lib/python3.5/site-packages/pkg_resources/__init__.py", line 854, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pyopenssl>=16.0.0; extra == "tls"' distribution was not found and is required by twisted

Greetings! The link to the binaries for OS X and Windows are invalid. Presently, they are:

https://buildbot.gridsync.io/packages/Tahoe-GUI.dmg
https://buildbot.gridsync.io/packages/Tahoe-GUI-win64.zip

...and both links return:

No Such Resource
File not found.

When using the signup process, I found myself wanting more feedback beyond the (ephemeral) messages in the progress-bar. I also think a separate label for the "invitation code" text-field is a good idea (on my windowmanager, as soon as I focus the window, that text-field is focused and so I can't read the "invitation code" placeholder text in the field, ever).

This might be overkill, but I was thinking perhaps something like this:

• once you type in the invite code, you get a list of steps
• the current one is highlighted (possibly with its own spinner/progress-bar)
• when that step is done, it turns grey (with the final status message)

Part of my thinking here is that we're going to want more information in the wormhole, for example to install tahoe-lafs. We probably want to send a URI indicating where to fetch "a release" from (and this would probably be a wheel file? so there might be several such URIs, one for each platform) along with SHA256-sums of the expected hash for these.

So one "step" will be "download the release", which could take a while depending on connection. Another step will then be "verify release" (i.e. sha256sum what we downloaded and compare to the secure hash we received). Maybe (instead) we put an "expected public key" in the JSON, and we download a signature which we verify against the downloaded release, and if that works we check if we found the expected public-key.

The "list of steps" could include a wormhole-JSON-provided blurb/message and even a logo (e.g. the JSON could have a URI where to download the logo, or just inline uuencoded data or whatever) -- so then after you've gotten the JSON you switch to the "branded list of steps" thing and the user can see a fine-grained list of what's happening (and what's to come, so they have some idea how long the process might take).

Then, also, if a step fails it could have a "more info" or similar button where we can dump some logs or whatever else might help us help the user figure out what failed.