* fix initial selected vpn mode * wip * Set gateway config * Init procedure and reading config * Update two comments * add nym-api field to app config * Remove hardcoded RUST_LOG from package.json * Use scope instead of explicit drop * Spawn vpn client in separate thread and separate runtime * Re-set nym-vpn-lib in Cargo.toml * add vpn handle to app state * add vpn client call to disconnect cmd * wip * Setup listener tasks * Read entire env after all * add env config file to app config * doc: add notes on config * refactor env config file as optional * add logic to connection status changes * refactor disconnect command * fix handle click connect button * update doc * add some fake delay to establish connection * localize backend messages * refactor extract registering listeners into modules * add more tracing logs * refactor clean code * refactor clean code * refactor vpn config creation * fix connect app_config read * refactor rename listener functions * add backend support for twohop mode * copy change * base connected status on Ready message Ready message sent from vpn client * filter out specific error * add logs * use exported receiver types from nym_vpn_lib * Handle exit message * Change to nym-vpn for consistency * prefix comment with TODO * update doc * remove nym_api config property use the one provided in the env config file * fix css compile error * log received backend error (frontend) --------- Co-authored-by: Jon Häggblad <jon.haggblad@gmail.com>
The Nym Privacy Platform
The platform is composed of multiple Rust crates. Top-level executable binary crates include:
- nym-mixnode - shuffles Sphinx packets together to provide privacy against network-level attackers.
- nym-client - an executable which you can build into your own applications. Use it for interacting with Nym nodes.
- nym-socks5-client - a Socks5 proxy you can run on your machine and use with existing applications.
- nym-gateway - acts sort of like a mailbox for mixnet messages, which removes the need for direct delivery to potentially offline or firewalled devices.
- nym-network-monitor - sends packets through the full system to check that they are working as expected, and stores node uptime histories as the basis of a rewards system ("mixmining" or "proof-of-mixing").
- nym-explorer - a (projected) block explorer and (existing) mixnet viewer.
- nym-wallet - a desktop wallet implemented using the Tauri framework.
Building
Platform build instructions are available on our docs site. Wallet build instructions are also available on our docs site.
Developing
There's a .env.sample-dev file provided which you can rename to .env if you want convenient logging, backtrace, or other environment variables pre-set. The .env file is ignored so you don't need to worry about checking it in.
For Typescript components, please see ts-packages.
Developer chat
We used to use Keybase for developer chats, but we have since migrated to Matrix and Discord. We no longer check the old nymtech.friends Keybase team.
You can chat to us in two places:
Rewards
Node, node operator and delegator rewards are determined according to the principles laid out in the section 6 of Nym Whitepaper. Below is a TLDR of the variables and formulas involved in calculating the epoch rewards. Initial reward pool is set to 250 million Nym, making the circulating supply 750 million Nym.
Node reward for node i is determined as:
and
Operator of node i is credited with the following amount:
Delegate with stake s receives:
where s' is stake s scaled over total token circulating supply.
Licensing and copyright information
This is a monorepo and components that make up Nym as a system are licensed individually, so for accurate information, please check individual files.
As a general approach, licensing is as follows this pattern:
- applications and binaries are GPLv3
- libraries and components are Apache 2.0 or MIT
- documentation is Apache 2.0 or CC0-1.0
Again, for accurate information, please check individual files.