Introducing the first Nym Service Provider
Nym is an open, decentralised privacy infrastructure. The infrastructure is run by people all over the world and is composed of different node types that each perform slightly different roles. In short, when using the infrastructure for privacy, your communications traffic would first be encrypted by a Nym client on your device and then sent on to:
Gateway nodes which are the first hop into the mixnet;
Mix nodes that mix people’s traffic through three sets of nodes, making it untraceable;
And finally, Network Requesters are the hop out that takes the user from the exit gateway to an app — which they are now using in a privacy-enhanced mode!
Previous blog posts have covered Gateways, Mix nodes and Validators. This post is a deep dive into Network Requesters, which is the first type of Nym Service Provider, connecting the core privacy infrastructure to user-facing applications.
Before delving into Network Requesters, let’s have a broader look at the role of Service Providers in general — of which Network Requesters are just one type…
NOTE: Nym will very shortly be issuing grants for starting up and running Network Requesters. If you want to be among the first to provide mass access to network level privacy, sign up here and stay tuned…
Service Providers
The design space for Service Providers (SPs) is very open: some will allow access to external services on the internet, shielding the user from the prying eyes of data scraping and machine-learning-enabled observers; other SPs will allow access to shielded services that can only be accessed via the mixnet.
Developing SPs doesn’t involve rethinking how you design your app from the ground up (in terms of code anyway). You can think of SPs just as ‘applications that can communicate with a local Nym client’. This means that you can spend more time exploring the growing ‘private-by-design’ application design space, and less about integration!
It’s likely that people running SPs will also run their own gateway for their app, to ensure reliability and uptime. That said, a small SP could easily rely on the public gateways available to them if they wanted to.
On the internet no-one needs to know you’re using the mixnet…
You might be wondering how SPs protect privacy. SPs enable people to use even not-so-private applications in a privacy-preserving way. They may facilitate anonymised requests to public web services outside of Nym network to applications such as Keybase or Telegram, Mail servers, or even blockchains.
SPs do this in the same way as a standard proxy service: it takes your message request from the mixnet, and passes it to the specific endpoint elsewhere. The clearnet recipient — such as a web server — doesn’t (and shouldn’t) even need to have any awareness of Nym. To them, the SP is just another application sending them a web request. The metadata exposed by the request will only be that of the SP. As a result, the origin of the request — the Nym user — will be protected, and any observer monitoring the clearnet traffic will be none the wiser than if they were interacting with the server from their metadata.
SPs that do not communicate outside of the Nym network can offer similar services to the standard range of application or server solutions available on the internet, but privacy-enhanced, and existing solely within the Nym network. Something like secure untraceable data backups are an immediate example: think anonymous Dropbox or file hosting services.
Introducing the Nym Network Requester
We already have one SP in our github repository and the docs for you to try running it: the Network Requester (NR). The NR is a binary that can be run alongside a Nym client on a VPS, which allows for private network requests to be made outside the mixnet from your local Nym client.
Why would you be using this? When you are using your desktop app, it communicates to the application backend servers, or makes outbound web requests. The Network Requester sits on the ‘other side’ of the mixnet making these requests for you, thereby hiding your metadata.
For example_:_ you can use the Nym SOCKS5 client to connect your local Telegram desktop app to the Telegram servers to collect and send messages. This means that the Telegram servers see a request from the Network Requester instead of your local computer. The Network Requester acts in a similar way to a proxy, routing requests for you and passing back the responses it gets from Telegram’s message servers.
How does it work? It’s a piece of code which checks an inbound request from its Nym client, checks the domain that is being requested and whether this domain is on a whitelist, and if so, forwards the request and then passes the response back to the requesting client (i.e. you).
From the user’s perspective, this all happens under the hood. All you have to do is point your local SOCKS5 client to a NR that supports the domain you wish to access, and then point your local app into the SOCKS5 client!
Explore how to run a Network Requester
Explore the Nym privacy platform
Join Nym Discord (Network Requester channel)
Privacy loves company
Discord // Telegram // Element // Twitter
The internet is global and so is Nym: join the Nym Community wherever you are and help build the private internet today.
English // 中文 // Русский // Türkçe // Tiếng Việt // 日本 // Française // Español // Português // 한국인
