Giters

LeastAuthority / destiny

Destiny – Cross-platform Magic Wormhole graphical client

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Make Magic Wormhole Backend configuration editable

wuan opened this issue · comments

commented

Currently the configuration of

  • Mailbox URL,
  • Transit Relay URL and
  • AppID

can be viewed on the configuration page, but not edited.

Making these fields editable would add the following benefits:

  • App users can have full control on the backend they are using.
  • We do not need to bind the app to a certain choice (see #174) but we could at least add some preset values.
  • We will be able to get rid of F-Droid's "Non-free network anti-feature" (see https://f-droid.org/docs/Anti-Features/#NonFreeNet) which we have flagged with our Destiny app deployment at the moment as the Backend URLs are not configurable.
commented

Some usability considerations:

  • we should accept ws:// and wss:// URLs for the mailbox (the default public mailbox is ws:// only).
  • it would be nice to immediately tell a user if the value they typed seems plausible: that is, check it.
    • this has potential privacy implications (e.g surprising network connection, possibly)
    • the server address may be correct, but the server may be down or otherwise (currently!) unreachable so it should be made clear to user what happened (e.g. "We just checked and can't contact the server right now").
    • could do this as a "check it now" sort of button (to address privacy)
  • Can we make better UX than just a text-field? That is, there's currently only two values that we know of that will work (our server, and Brian's server) so presenting these as a drop-down (with possibility still of typing your own) might be better. Or tab-complete to the known ones easily. I assume we need "type in your own" as a possibility for fdroid.
  • There's basically never going to be a reason to change the AppID (since we're only doing file-transfer here, not general purpose wormhole).
  • It's possible in the protocol -- and may make sense for certain use-cases -- to have multiple transit relays configured. This possibility should be allowed or accounted for (at least for the future).
commented

The current state of the change is fine to move on. We can add improvements in further steps. Especially as:

  • That is what we do now
  • That could be added as some kind of extended validation later. But we should not enforce it. Why should users not be able to enter a server which is currently not reachable?
    • We should add some focus on having proper error responses for the transmission process itself, which can not be part of this ticket.
  • The text-field is there for a reason as it is required to avoid the Non-Free Net anti-feature. For better user experience we added the clickable presets.
  • Nobody forces anyone to change the AppID. And in the light of the Non-Free Net anti-feature we keep that editable.
  • Multiple transit relays could be added later. There is no support for them at the moment.
commented

Why should users not be able to enter a server which is currently not reachable?

That's not what I'm suggesting there.

Also sorry it didn't come across more clearly, but I meant the above comment to collect a bunch of other discussion / ideas so they're not lost or buried in PR comments. I didn't intend to make a bunch more work, just document some additional things (outside the PR).

Click-able presets sound great, the "combo-box" was just a naive illustration of the idea. I definitely agree free-form URLs should always be accepted, somehow.

Until 2 hours ago the associated PR didn't accept ws:// so I don't want to lose the reason why. There's also discussion of warning users about that too, so we should document why (and what they should do if they see the warning).

Regarding multiple transit relays, there is support in the protocol and other clients currently. Do you mean we don't support more than one hint if another client sends multiple hints? Or just that we can't connect ("listen") to more than one transit currently? Again: just writing this in an actual ticket so it's not lost (not suggesting we need support now).

Regarding AppID does F-Droid demand that be change-able? That seems odd.

commented

It is fine to create new issues here to track proposed topics separately when this will be closed.