Hi Urza,
(Apologies for the late reply. I'm new around here and I didn't remember that HN won't send me an email notifications for replies to my comments.)
Before getting into Relaynet, let's consider how Internet apps work: They have a client and a server, and the client is responsible for producing and delivering its own data. That means that the server must be reachable and ready to respond to each request, at the exact time each takes place. This architecture (called Remote Procedure Call, RPC) is fine when the Internet is available, but it breaks when the Internet is cut off and it's also incompatible with alternative transports because they add a significant latency.
By contrast, Relaynet apps use a radically different architecture: Asynchronous messaging. Instead of clients/servers, apps have "endpoints"; and instead of requests/responses, endpoints exchange "messages". Endpoints delegate the delivery of such messages to one or more brokers, which we call "gateways" in Relaynet. This way, the sender and receiver don't have to be reachable and ready at the same time, because the gateways will keep a copy of each message until it reaches its final destination. Consequently, when the Internet is available, gateways will use it and messages would be delivered instantly, but when the Internet is cut off, gateways will switch to a secure sneakernet (https://en.wikipedia.org/wiki/Sneakernet). Additionally, endpoint messages (called "parcels" in Relaynet) are end-to-end encrypted and signed, so gateways can't tamper with them or see what's inside.
Behind the scenes, Relaynet apps communicate over the Internet/sneakernets via two gateways: A private gateway (a standalone app on the user's device) and a public gateway (a server-side app). Say Twitter supports Relaynet and exposes an endpoint at https://api.twitter.com/relaynet: When you post a tweet, your Twitter app will encapsulate it in a parcel bound for https://api.twitter.com/relaynet, but instead of delivering the parcel by itself, it'd send it to its local private gateway, which will in turn send it to its public gateway, and which will finally deliver it to Twitter's endpoint. Now consider the case where the Twitter server wants to send you data: It'd post the data to your public gateway (e.g., https://eu.relaycorp.tech), which would in turn send to your private gateway, which will finally send it to the endpoint in your local Twitter app; in this direction, the parcel is bound for an opaque address derived from the public key of the endpoint (analogous to Bitcoin addresses).
Now, when the Internet is cut off, your two gateways get disconnected. That's when couriers (https://relaynet.network/couriers) would step in and provide a secure sneakernet. Couriers will physically transport parcels between a place disconnected from the Internet and one connected to it. However, since parcels contain the address of the recipient, and that address would identify the service when it's bound for an Internet host (e.g., https://api.twitter.com/relaynet), gateways will encapsulate those parcels in a new layer of end-to-end encryption -- You can think of it as an "offline TLS". So couriers (or anyone who intercepts them) won't be able to see or change the parcels being transported.
As you may have anticipated by now, for a preexisting, Internet-based service to work on Relaynet, its developer has to make client- and server-side changes to their software. Alternatively, if the service offers an API, a third party could build a Relaynet integration (that's what I did in the Relaynet proof of concept with Twitter: https://twitter.com/relaynet_/status/1089211336171679745). Also, if you're building a service from scratch, you could build a fully decentralised one that doesn't need any servers (see: https://relaynet.network/service-providers)
Relaynet won't need any new/special hardware: Private gateways will support Android 5+/Windows/Linux (macOS and iOS support is on the roadmap), so you can use Relaynet as long as your device runs on one of those platforms.
I highly recommend watching this 12-minute video to learn more about how couriers establish this connectivity and also to see a demo of the software couriers will use: https://youtu.be/UXuLz3q_6bo.
How could this have worked in Belarus? Let's first assume that the implementation of Relaynet is complete and at least one service (e.g., Twitter) is now compatible with it. Based on what I know about the situation (https://netblocks.org/reports/internet-disruption-hits-belar...), this could've been done:
- First of all, people should've ideally installed Relaynet and the Relaynet-compatible app(s) they wish to use before the election (whilst the Internet is available). Generally, people living under repressive regimes should aim to have Relaynet installed before contentious events like elections. Starting to use Relaynet without the Internet is possible but fiddly (https://github.com/relaycorp/relayverse/issues/1).
- Similarly, couriers should've (ideally) planned their routes in advance, especially if they'll be collaborating with other couriers or if they plan to use Latvian/Lithuanian/Polish mobile Internet operators near their borders (without actually crossing the border necessarily). Russian and Ukrainian operators could potentially work too. Couriers would've also identified places likely to remain connected to the Internet in the big cities (Minsk and Barysaw seem to have been remained connected to some extend, although a lot of that would've been government agencies: https://twitter.com/netblocks/status/1293522490355064839).
- When the Internet was cut off, couriers would've stepped in by doing their route: Stopping at one or more locations without access to the Internet, and eventually getting to the nearest place with access to the Internet (somewhere in Minsk/Barysaw or near the border with another country).
- Each courier is free to charge their users if they want to (which would be reasonable, considering the risk and work they have to do), but we're not supporting that in any way in the software. That would be entirely between the courier and the user.
PS: All of this complexity is abstracted away from the end user. As far as they're concerned, all they need to do is install the private gateway and it'll default to a public gateway behind the scenes. Also, we won't be using this terminology with end users: The private gateway will simply be called the "Relaynet app".