Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Record and display local nicknames for networks #17

Open
ethanjli opened this issue Sep 30, 2021 · 0 comments
Open

Record and display local nicknames for networks #17

ethanjli opened this issue Sep 30, 2021 · 0 comments
Labels
stage: dev On/for a development version type: feature Brand new functionality, features, pages, workflows, endpoints, etc. work: complicated The situation is complicated (known unknowns), good practices used

Comments

@ethanjli
Copy link
Member

ethanjli commented Sep 30, 2021

Right now, ZeroTier networks without confirmed domain names are displayed as their ZeroTier network ID plus the network's self-declared name (which is an impersonation vector); ZeroTier peers are displayed only as their ZeroTier addresses. The ID and address strings are not meaningful names for users. Instead, the user should set a locally-stored, locally-unique nickname (more formally, a "petname") for each network they try to join, as part of the join process; the network's self-declared name should be transformed into a nickname suggestion. When a network has not been assigned a nickname, Latreutes should prompt the user to set a nickname (perhaps with an editable field in the header of the network's entity card/panel); however, the self-declared name can still be displayed as such under the "Basic Details" accordion. The local nickname should also take precedence over the confirmed domain name, if it exists.

The local nicknames should be stored durably on the filesystem, via Tauri (not just in the webview's local storage).

For additional design considerations, refer to https://www.inkandswitch.com/backchannel/ (which solves a different but related use case) and https://link.springer.com/chapter/10.1007/978-3-642-04766-4_4 (which proposes additional constraints on nicknames for security usability).

@ethanjli ethanjli added stage: dev On/for a development version type: feature Brand new functionality, features, pages, workflows, endpoints, etc. work: complicated The situation is complicated (known unknowns), good practices used labels Sep 30, 2021
@ethanjli ethanjli added this to the Local nicknames milestone Sep 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stage: dev On/for a development version type: feature Brand new functionality, features, pages, workflows, endpoints, etc. work: complicated The situation is complicated (known unknowns), good practices used
Projects
None yet
Development

No branches or pull requests

1 participant