* bunch of wip with focus on serialization * Being able to send normal data (NO SURBS yet) to yourself again * Fixed RepliableMessage deserialization * Recovering data from surb messages * Extracted common code in sphinx payload construction * Cleanup within received buffer * requesting, sending and using additional reply surbs * Following discussion with @simonwicky, removing sender proof and decreasing size of sender tag * Made sender tag more easily configurable * Refactoring of message creation * Propagating reply surb acks but not retransmitting them yet * Surb retransmissions * requesting additional surbs from the retransmission flow * correctly determining the point of requesting additional surbs * Ability to use socks5 (and network requester) with surbs * Improved surbs retranmsission reliability * naive way of not over-requesting surbs * wip on tag storage * Improved error propagation for message construction * Requesting more surbs for stale entries * Better controlling the point of having to request additional surbs * Using pseudorandom sender tag instead of a hardcoded one * First cleanup round in MessageHandler * Error cleanup and if simplification * Assigned a more permanent name to the ReplyController * Removed PendingReply redundant type * Made socks5 client less eager to over-send reply surbs * 'anonymous' field on socks5 client to decide whether to use surbs or attach address * Dead code and import removal in client-core * Updating ClientRequest variants * Adjusted decision threshold for requesting more surbs * Native client cleanup * Made socks5 client usage of surbs configurable * Restored statistics in network requester * Validator-api compiles once again * Further improved surb request logic * boxing the recipient in controller requests * Removal of hardcoded values in favour of propagating them from the config * more validation during surb requests * Fixed ClientRequest::Send deserialization * Added length checks for request deserialization * post-merge formatting * Unit tests once again compile and pass * controlling retransmission_reply_surb_request_size from config * More Recipient boxing action * Requesting additional reply surbs for retransmission BEFORE dipping below the threshold * Making clippy generally happier * Wasm client compiles (but might not yet work correctly) * Feature/use expect instead of panicking (#1797) * Implementation of 'Debug' on 'RealMessage' * expect with failed channel name instead of throwing empty panics * Introduced Debug trait constraint in ProxyRunner * Derive Debug for socks5_requests::Message * Fix decrypting stored received msg (#1786) * Fix decrypting stored received msg * rustfmt * Moving binary message recovery to separate function Co-authored-by: Jędrzej Stuczyński <jedrzej.stuczynski@gmail.com> * real_traffic_stream: reduce frequency of status print (#1794) * Properly defined unnamed errors * Dealing with previously ignored errors * logging improvements * Removed old example code 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
You can chat to us in Keybase. Download their chat app, then click Teams -> Join a team. Type nymtech.friends into the team name and hit continue. For general chat, hang out in the #general channel. Our development takes places in the #dev channel. Node operators should be in the #node-operators channel.
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 recieves:
where s' is stake s scaled over total token circulating supply.
Licensing and copyright information
This program is available as open source under the terms of the Apache 2.0 license. However, some elements are being licensed under CC0-1.0 and MIT. For accurate information, please check individual files.