Coder Social home page Coder Social logo

nymtech / nym Goto Github PK

View Code? Open in Web Editor NEW
1.2K 51.0 229.0 234.5 MB

Nym provides strong network-level privacy against sophisticated end-to-end attackers, and anonymous transactions using blinded, re-randomizable, decentralized credentials.

Home Page: https://nymtech.net

Rust 73.77% Shell 0.64% HTML 0.67% JavaScript 1.98% Go 2.89% Python 0.31% TypeScript 18.33% CSS 0.06% Dockerfile 0.01% Makefile 0.12% C 0.35% Roff 0.02% MDX 0.80% Handlebars 0.02% C++ 0.04%
decentralized mixnet rust rust-lang zero-knowledge mixnets

nym's Introduction

The Nym Privacy Platform

The platform is composed of multiple Rust crates. Top-level executable binary crates include:

  • nym-node - a tool for running a node within the Nym network. Nym Nodes containing functionality such as mixnode, entry-gateway and exit-gateway are fundamental components of Nym Mixnet architecture. Nym Nodes are ran by decentralised node operators. Read more about nym-node in Operators Guide documentation. Network functionality of nym-node (labeled with --mode flag) can be:
    • mixnode - shuffles Sphinx packets together to provide privacy against network-level attackers.
    • gateway - acts sort of like a mailbox for mixnet messages, which removes the need for direct delivery to potentially offline or firewalled devices. Gateways can be further categorized as entry-gateway and exit-gateway. The latter has an extra embedded IP packet router and Network requester to route data to the internet.
  • 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-explorer - a (projected) block explorer and (existing) mixnet viewer.
  • nym-wallet - a desktop wallet implemented using the Tauri framework.
                      ┌─►mix──┐  mix     mix
                      │       │
            Entry     │       │                   Exit
client ───► Gateway ──┘  mix  │  mix  ┌─►mix ───► Gateway ───► internet
                              │       │
                              │       │
                         mix  └─►mix──┘  mix

Build Status

Building

Developing

There's a sandbox.env file provided which you can rename to .env if you want convenient testing environment. Read more about sandbox environment in our Operators Guide page.

References for developers:

Developer chat

You can chat to us in two places:

  • The #dev channel on Matrix
  • The various developer channels on Discord

Tokenomics & Rewards

Nym network economic incentives, operator and validator rewards, and scalability of the network are determined according to the principles laid out in the section 6 of Nym Whitepaper. Initial reward pool is set to 250 million Nym, making the circulating supply 750 million Nym.

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

Nym Node Operators and Validators Temrs and Conditions can be found here.

nym's People

Contributors

aid19801 avatar aniampio avatar benedettadavico avatar dependabot[bot] avatar doums avatar durch avatar edcalderon avatar farbanas avatar fmtabbara avatar futurechimp avatar gala1234 avatar jessgess avatar joeiacono2021 avatar jstuczyn avatar lnceballosz avatar lorex-ia avatar mfahampshire avatar mmsinclair avatar nadimkobeissi avatar neacsu avatar octol avatar pwnfoo avatar raphael-walther avatar sebastinez avatar serinko avatar simonwicky avatar tommyv1987 avatar twofaktor avatar yanok87 avatar zaneschepke avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nym's Issues

Periodic client refresh

Get the client to refresh its topology periodically, so that it detects and reacts to any changes in the topology.

Check required sfw-provider args

It seems more difficult than I'd expect to initially start the sfw-provider. Should we mark more arguments as required? Can we provide some sensible defaults?

Replace args with proper config files

At the moment, mixnode keys change on every node restart. This is going to cause friction for clients (especially if they don't refresh periodically) because a restarted node will change its key, causing MacIntegrity errors as clients send un-decryptable packets. Ultimately this breaks the path, a big no-no.

So we might as well store some persistent information on disk.

  • make an init command for mixnodes and providers
  • create persistent mixnode keys that survive across restarts
  • we need to consider whether we need node human names for this

Nym client crashing and disconnecting local websocket with complaint about binary data

..Received a message from 127.0.0.1:36940: {"type": "fetch"}
.Received a message from 127.0.0.1:36940: {"type": "fetch"}
Received a message from 127.0.0.1:36940: Binary Data<length=4>
thread 'tokio-runtime-worker' panicked at 'Other types of messages are also unsupported!', nym-client/src/sockets/ws.rs:66:18
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::begin_panic
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panicking.rs:400
   7: <nym_client::sockets::ws::ClientRequest as core::convert::From<tungstenite::protocol::message::Message>>::from
             at nym-client/src/sockets/ws.rs:66
   8: <T as core::convert::Into<U>>::into
             at /build/rust/src/rustc-1.40.0-src/src/libcore/convert.rs:547
   9: nym_client::sockets::ws::handle_connection::{{closure}}
             at nym-client/src/sockets/ws.rs:173
  10: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}}
             at /build/rust/src/rustc-1.40.0-src/src/libstd/future.rs:43
  11: std::future::set_task_context
             at /build/rust/src/rustc-1.40.0-src/src/libstd/future.rs:79
  12: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /build/rust/src/rustc-1.40.0-src/src/libstd/future.rs:43
  13: tokio::task::core::Core<T>::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/core.rs:128
  14: tokio::task::harness::Harness<T,S>::poll::{{closure}}::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:120
  15: core::ops::function::FnOnce::call_once
             at /build/rust/src/rustc-1.40.0-src/src/libcore/ops/function.rs:227
  16: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panic.rs:317
  17: std::panicking::try::do_call
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panicking.rs:287
  18: __rust_maybe_catch_panic
  19: std::panicking::try
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panicking.rs:265
  20: std::panic::catch_unwind
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panic.rs:396
  21: tokio::task::harness::Harness<T,S>::poll::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:101
  22: tokio::loom::std::causal_cell::CausalCell<T>::with_mut
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/loom/std/causal_cell.rs:41
  23: tokio::task::harness::Harness<T,S>::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:100
  24: tokio::task::raw::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/raw.rs:162
  25: tokio::task::raw::RawTask::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/raw.rs:113
  26: tokio::task::Task<S>::run
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/mod.rs:371
  27: tokio::runtime::thread_pool::worker::GenerationGuard::run_task
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:446
  28: tokio::runtime::thread_pool::worker::GenerationGuard::process_available_work
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:304
  29: tokio::runtime::thread_pool::worker::GenerationGuard::run
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:269
  30: tokio::runtime::thread_pool::worker::Worker::run::{{closure}}::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:158
  31: std::thread::local::LocalKey<T>::try_with
             at /build/rust/src/rustc-1.40.0-src/src/libstd/thread/local.rs:262
  32: std::thread::local::LocalKey<T>::with
             at /build/rust/src/rustc-1.40.0-src/src/libstd/thread/local.rs:239
  33: tokio::runtime::thread_pool::worker::Worker::run::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:134
  34: tokio::runtime::thread_pool::current::set::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/current.rs:47
  35: std::thread::local::LocalKey<T>::try_with
             at /build/rust/src/rustc-1.40.0-src/src/libstd/thread/local.rs:262
  36: std::thread::local::LocalKey<T>::with
             at /build/rust/src/rustc-1.40.0-src/src/libstd/thread/local.rs:239
  37: tokio::runtime::thread_pool::current::set
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/current.rs:29
  38: tokio::runtime::thread_pool::worker::Worker::run
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:130
  39: tokio::runtime::thread_pool::Workers::spawn::{{closure}}::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/mod.rs:113
  40: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/blocking/task.rs:30
  41: tokio::task::core::Core<T>::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/core.rs:128
  42: tokio::task::harness::Harness<T,S>::poll::{{closure}}::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:120
  43: core::ops::function::FnOnce::call_once
             at /build/rust/src/rustc-1.40.0-src/src/libcore/ops/function.rs:227
  44: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panic.rs:317
  45: std::panicking::try::do_call
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panicking.rs:287
  46: __rust_maybe_catch_panic
  47: std::panicking::try
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panicking.rs:265
  48: std::panic::catch_unwind
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panic.rs:396
  49: tokio::task::harness::Harness<T,S>::poll::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:101
  50: tokio::loom::std::causal_cell::CausalCell<T>::with_mut
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/loom/std/causal_cell.rs:41
  51: tokio::task::harness::Harness<T,S>::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:100
  52: tokio::task::raw::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/raw.rs:162
  53: tokio::task::raw::RawTask::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/raw.rs:113
  54: tokio::task::Task<S>::run
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/mod.rs:371
  55: tokio::runtime::blocking::pool::run_task
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/blocking/pool.rs:290
  56: tokio::runtime::blocking::pool::Inner::run
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/blocking/pool.rs:206
  57: tokio::runtime::blocking::pool::Spawner::spawn_thread::{{closure}}::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/blocking/pool.rs:186
  58: tokio::runtime::context::enter
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/context.rs:72
  59: tokio::runtime::handle::Handle::enter
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/handle.rs:33
  60: tokio::runtime::blocking::pool::Spawner::spawn_thread::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/blocking/pool.rs:185
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'tokio-runtime-worker' panicked at 'Failed to forward request: TrySendError { kind: Disconnected }', src/libcore/result.rs:1165:5
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::continue_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::result::unwrap_failed
  10: core::result::Result<T,E>::expect
             at /build/rust/src/rustc-1.40.0-src/src/libcore/result.rs:960
  11: nym_client::sockets::ws::accept_connection::{{closure}}
             at nym-client/src/sockets/ws.rs:232
  12: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}}
             at /build/rust/src/rustc-1.40.0-src/src/libstd/future.rs:43
  13: std::future::set_task_context
             at /build/rust/src/rustc-1.40.0-src/src/libstd/future.rs:79
  14: <std::future::GenFuture<T> as core::future::future::Future>::poll
             at /build/rust/src/rustc-1.40.0-src/src/libstd/future.rs:43
  15: tokio::task::core::Core<T>::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/core.rs:128
  16: tokio::task::harness::Harness<T,S>::poll::{{closure}}::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:120
  17: core::ops::function::FnOnce::call_once
             at /build/rust/src/rustc-1.40.0-src/src/libcore/ops/function.rs:227
  18: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panic.rs:317
  19: std::panicking::try::do_call
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panicking.rs:287
  20: __rust_maybe_catch_panic
  21: std::panicking::try
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panicking.rs:265
  22: std::panic::catch_unwind
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panic.rs:396
  23: tokio::task::harness::Harness<T,S>::poll::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:101
  24: tokio::loom::std::causal_cell::CausalCell<T>::with_mut
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/loom/std/causal_cell.rs:41
  25: tokio::task::harness::Harness<T,S>::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:100
  26: tokio::task::raw::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/raw.rs:162
  27: tokio::task::raw::RawTask::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/raw.rs:113
  28: tokio::task::Task<S>::run
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/mod.rs:371
  29: tokio::runtime::thread_pool::worker::GenerationGuard::run_task
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:446
  30: tokio::runtime::thread_pool::worker::GenerationGuard::process_available_work
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:304
  31: tokio::runtime::thread_pool::worker::GenerationGuard::run
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:269
  32: tokio::runtime::thread_pool::worker::Worker::run::{{closure}}::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:158
  33: std::thread::local::LocalKey<T>::try_with
             at /build/rust/src/rustc-1.40.0-src/src/libstd/thread/local.rs:262
  34: std::thread::local::LocalKey<T>::with
             at /build/rust/src/rustc-1.40.0-src/src/libstd/thread/local.rs:239
  35: tokio::runtime::thread_pool::worker::Worker::run::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:134
  36: tokio::runtime::thread_pool::current::set::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/current.rs:47
  37: std::thread::local::LocalKey<T>::try_with
             at /build/rust/src/rustc-1.40.0-src/src/libstd/thread/local.rs:262
  38: std::thread::local::LocalKey<T>::with
             at /build/rust/src/rustc-1.40.0-src/src/libstd/thread/local.rs:239
  39: tokio::runtime::thread_pool::current::set
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/current.rs:29
  40: tokio::runtime::thread_pool::worker::Worker::run
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/worker.rs:130
  41: tokio::runtime::thread_pool::Workers::spawn::{{closure}}::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/thread_pool/mod.rs:113
  42: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/blocking/task.rs:30
  43: tokio::task::core::Core<T>::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/core.rs:128
  44: tokio::task::harness::Harness<T,S>::poll::{{closure}}::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:120
  45: core::ops::function::FnOnce::call_once
             at /build/rust/src/rustc-1.40.0-src/src/libcore/ops/function.rs:227
  46: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panic.rs:317
  47: std::panicking::try::do_call
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panicking.rs:287
  48: __rust_maybe_catch_panic
  49: std::panicking::try
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panicking.rs:265
  50: std::panic::catch_unwind
             at /build/rust/src/rustc-1.40.0-src/src/libstd/panic.rs:396
  51: tokio::task::harness::Harness<T,S>::poll::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:101
  52: tokio::loom::std::causal_cell::CausalCell<T>::with_mut
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/loom/std/causal_cell.rs:41
  53: tokio::task::harness::Harness<T,S>::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/harness.rs:100
  54: tokio::task::raw::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/raw.rs:162
  55: tokio::task::raw::RawTask::poll
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/raw.rs:113
  56: tokio::task::Task<S>::run
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/task/mod.rs:371
  57: tokio::runtime::blocking::pool::run_task
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/blocking/pool.rs:290
  58: tokio::runtime::blocking::pool::Inner::run
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/blocking/pool.rs:206
  59: tokio::runtime::blocking::pool::Spawner::spawn_thread::{{closure}}::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/blocking/pool.rs:186
  60: tokio::runtime::context::enter
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/context.rs:72
  61: tokio::runtime::handle::Handle::enter
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/handle.rs:33
  62: tokio::runtime::blocking::pool::Spawner::spawn_thread::{{closure}}
             at /home/nar/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.9/src/runtime/blocking/pool.rs:185
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
...........

Just run this example for a couple of minutes:

import asyncio
import json
import websockets

async def ping():
    pong_address = "kauuj71-RPvETjz8FMQugnsNSDJ8033E4lNS_anMFD0="
    uri = "ws://127.0.0.1:9001/mix"

    async with websockets.connect(uri) as websock:
        request_object = {
            "type": "ownDetails"
        }
        await websock.send(json.dumps(request_object))
        response = json.loads(await websock.recv())
        print("Ping address =", response["address"])

        request_object = {
            "type": "send",
            "message": "ping",
            "recipient_address": pong_address
        }
        await websock.send(json.dumps(request_object))
        print("Ping sent:", request_object)

async def pong():
    ping_address = "lzdJ2EkCHlPFVLdsBCkW_n6thaql2wImrGMG0gt_EX4="
    uri = "ws://127.0.0.1:9002/mix"

    async with websockets.connect(uri) as websock:
        request_object = {
            "type": "ownDetails"
        }
        await websock.send(json.dumps(request_object))
        response = json.loads(await websock.recv())
        print("Ping address =", response["address"])

        while True:
            request_object = {
                "type": "fetch"
            }
            await websock.send(json.dumps(request_object))
            print("Pong sent:", request_object)
            response = json.loads(await websock.recv())
            messages = response["messages"]
            print("Pong received messages:", messages)

            if not messages:
                await asyncio.sleep(0.1)

def main():
    asyncio.get_event_loop().run_until_complete(asyncio.gather(
        ping(), pong()
    ))

if __name__ == "__main__":
    main()

Once implementation is available, wherever appropriate, replace `futures::lock::Mutex` with `futures::lock::RwLock`

Basically wait a week or so for 0.6.0 release of https://github.com/asomers/futures-locks that will use tokio 0.2.0.
Why we want to change it to RwLock rather than Mutex? As there are way many more reads of the data compared to writes. It is read every single client request (for EVERY client) while it is written to only once per single client - during registration. So that would be a significant performance gain.

Edit: This issue refers to uses in sfw-provider as well as in nym-client

Messages returned by fetch are base64 encoded

Ping sent: {'type': 'send', 'message': 'ping', 'recipient_address': 'kauuj71-RPvETjz8FMQugnsNSDJ8033E4lNS_anMFD0='}
Ping address = kauuj71-RPvETjz8FMQugnsNSDJ8033E4lNS_anMFD0=
Pong sent: {'type': 'fetch'}
Pong received messages: []
Pong sent: {'type': 'fetch'}
Pong received messages: []
Pong sent: {'type': 'fetch'}
Pong received messages: ['cGluZw==']
Pong sent: {'type': 'fetch'}
Pong received messages: []
Pong sent: {'type': 'fetch'}
Pong received messages: []
Pong sent: {'type': 'fetch'}
Pong received messages: []
Pong sent: {'type': 'fetch'}

Code is here:

import asyncio
import json
import websockets

async def ping():
    pong_address = "kauuj71-RPvETjz8FMQugnsNSDJ8033E4lNS_anMFD0="
    uri = "ws://127.0.0.1:9001/mix"

    async with websockets.connect(uri) as websock:
        request_object = {
            "type": "ownDetails"
        }
        await websock.send(json.dumps(request_object))
        response = json.loads(await websock.recv())
        print("Ping address =", response["address"])

        request_object = {
            "type": "send",
            "message": "ping",
            "recipient_address": pong_address
        }
        await websock.send(json.dumps(request_object))
        print("Ping sent:", request_object)

async def pong():
    ping_address = "lzdJ2EkCHlPFVLdsBCkW_n6thaql2wImrGMG0gt_EX4="
    uri = "ws://127.0.0.1:9002/mix"

    async with websockets.connect(uri) as websock:
        request_object = {
            "type": "ownDetails"
        }
        await websock.send(json.dumps(request_object))
        response = json.loads(await websock.recv())
        print("Ping address =", response["address"])

        while True:
            request_object = {
                "type": "fetch"
            }
            await websock.send(json.dumps(request_object))
            print("Pong sent:", request_object)
            response = json.loads(await websock.recv())
            messages = response["messages"]
            print("Pong received messages:", messages)

            if not messages:
                await asyncio.sleep(1)

def main():
    asyncio.get_event_loop().run_until_complete(asyncio.gather(
        ping(), pong()
    ))

if __name__ == "__main__":
    main()

Message should just be a normal string. It should be up to the sender to base64 encode/decode binary data themselves if sending through websocket.

Change how topology is obtained

Currently topology is created via Topology::new() that creates new directory_client every single call. It should be able to reuse it.

Database for gateway

Gateway should really be using some kinda of database for payload storage rather than raw storage on disk as that is kinda crude + thread unsafe.

Error referring to mismatched types caused by topology

Running on Debian Stretch

When running the cargo test command in the nym directory, I receive this error.

error[E0308]: mismatched types
--> common/topology/src/lib.rs:69:30
|
69 | address: address_bytes,
| ^^^^^^^^^^^^^ expected struct sphinx::route::NodeAddressBytes, found array of 32 elements
|
= note: expected type sphinx::route::NodeAddressBytes
found type [u8; 32]

error: aborting due to previous error

For more information about this error, try rustc --explain E0308.
error: could not compile topology.
warning: build failed, waiting for other jobs to finish...
error: build failed

Simplify concurrency with a proper actor framework

Currently we have semi-unintentionally implemented our own 'actor' system. It'd be better to get rid of all that complexity and use something like actix or Riker.

However, that requires some additional research whether we should even do it - I will admit I only had a very quick glance at the concept itself.

Split provider/mod.rs

The file is getting quite big with a lot of different types and different sets of functionalities - it should be split!

nym-mixnode mandatory host option

currently the doc states:

nym-mixnode run --layer 1 will start the mixnode in layer 1

but this errors with

error: The following required arguments were not provided:
--host

so either the README should state

nym-mixnode run --layer 1 --host localhost will start the mixnode in layer 1 on localhost

or (maybe preferred option) the host option should default to localhost

If a thread blows at startup, panic the entire application

At the moment, if a subsidiary thread explodes during startup, the main application thread just keeps on trucking. Ideally the whole node application startup process would fail, so that node administrators don't think startup succeeded.

Logging

Add proper loggers to all parts of the Nym codebase.

More secured auth token - some signature on request

Currently the service provider gives out authentication tokens to everyone. If you forgot yours - it just gives you back what you should have had (so anyone could learn your token this way);
The request would need some signature to ensure that the provider is talking with the right client.

Port run_network.sh from old Go mixnet

It was quite handy to have a way to run a local network for development purposes, port the script from the old Go codebase. It'll need to run the directory locally (or die in spectacular fashion). There's a branch at feature/script/localnet which is partly done.

Make sure to fix the docs for it as well.

Stop panicking!

We've been mildly sloppy as we rush to get things running. Sanitize all uses of unwrap and expect to ensure we don't accidentally destroy anything in situations where we expect bad inputs, handling errors gracefully.

Health Checker inside Validator

As the testnet has launched and is now effectively beyond the direct control of any single entity, we need to be able to measure network health in non-adversarial situations.

The validator node should be able to send a bunch of packets through the mixnet to get a view of whether packets are being routed effectively by the available mixnodes. Later, we'll expand this to form the basis of the mix-mining system detailed by Claudia and Aggelos, so we should write this code with that goal in mind.

Nym-client refactor

Refactor nym-client to pull apart complex files into modules of code that follow the single-responsibility principle. In tandem, clean up our multi-threading now so that we don't grow a big scheissball.

Take version numbers into account when picking routes

It will certainly be the case that not all clients upgrade simultaneously - but probably not all nodes will either. We may be able to use this to our advantage by taking version numbers into account when the client picks its route. Old clients can generate routes using old nodes (if compatible versions are running). New clients can take advantage of new features, better performance, etc of new mixnode versions, so there are functional incentives to upgrade.

Fix incorrectly used Arcs

When we're processing client requests (say in provider), we keep processing data as Arc<some struct> this only happens to work because some struct implements Copy. This should be Arc<RefCell<some struct>> or <Arc<Cell<some struct>> instead.

Check layer 1 connectivity at client start

When the Nym client starts up and gets a good topology from the directory server, there may still be a problem (i.e. if the layer 1 mixnodes are using IPv6 and the client can't speak that due to network constraints, packets will not route).

To work around this, at client start, do a simple TCP connectivity check to all layer 1 mixnodes and knock any failures out of the topology.

Client API consistency

Make APIs between TCPSocket and WebSocket consistent. This could also be a good time to look into @narodnik's async client API idea (mentioned in chat).

Create config struct for mixnode (possibly also for client)

Currently only our provider does nice argument parsing to create a proper config (i.e. fn new_config(matches: &ArgMatches) -> provider::Config. It would be nice if mixnode did something similar and we just passed the config itself to create the mix instance.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.