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).
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).