TollGate

TollGate enables WiFi routers to accept Bitcoin payments for internet access. This allows users with a router and an internet connection to operate as internet service providers.

Contributions welcome:
https://github.com/orgs/OpenTollGate/repositories

Public Key

npub1zzt0d0s2f4lsanpd7nkjep5r79p7ljq7aw37eek64hf0ef6v0mxqgwljrv

NIP-05 Address

[email protected]

Profile Code

nprofile1qqspp9hkhc9y6lcwesklfmfvs6plzsl0eq0whglvumd2m5hu5ax8anqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsfpp2te

Publishing to

nostr.land

relay.damus.io

nos.lol

Author Public Key

npub1zzt0d0s2f4lsanpd7nkjep5r79p7ljq7aw37eek64hf0ef6v0mxqgwljrv

Show more details

Last Notes

2025-04-10 01:01:27 GMT

Bitcoin is the routing algorithm.
#nevent1q…q3kq

2025-03-01 08:37:29 GMT

- reply

We aren't announcing TollGate yet, just sharing the website that @nprofile…2ewl is working on. We still have a few weeks of work before we can start testing with brave early adopters.. 🤣

2025-02-28 16:25:36 GMT

- reply

WIP, we are crowd sourcing the proof reading 😀

2025-02-27 09:32:46 GMT

- reply

Thanks @nprofile…hpd0, this is exactly the kind of feedback we were hoping for. It's a draft, but I'm sure it will be polished soon like this 😀
Cc: @nprofile…2ewl

2025-02-27 07:59:55 GMT

TollGate has a beautiful website now thanks to @nprofile…2ewl!
https://tollgate.me/
The new modular nostr based architecture is also progressing rapidly thanks to @nprofile…7u3d and @nprofile…zpkd.
Stay tuned for a big release with an app that handles the interaction with TollGates on your behalf and a modular nostr based architecture that runs on your TollGate.

2025-01-31 16:30:07 GMT

The mobile app that @nprofile…7u3d and @nprofile…zpkd made is a huge enabler for the user, because the user can now buy internet granularly and frequently, which means that they can roam between routers without losing any credit and without needing to interact with captive portals manually!
This is a huge win! Thanks guys, your amazing 🧡🙏
#nevent1q…vy57

2025-01-29 07:46:34 GMT

- reply

Feel free to ping us if you have any questions. A public Q&A could benefit others as well. We are learning about OpenWRT as we go. Experienced insights are most welcome 😀

2025-01-16 18:56:08 GMT

- reply

Amazing! This is going to make it so much easier and safer to deploy binaries to routers 😀
Thanks for doing what you do @nprofile…7u3d and thanks for helping him with this @nprofile…t4yq 🙏

2025-01-16 07:23:57 GMT

- reply

Yes, so questions like path finding and censorship ade left to the market..

2025-01-16 07:17:45 GMT

- reply

Exactly, this model emerged from the desire to enable devices in a mesh network to pay eachother, because the networks can't scale if they rely on philanthropy on behalf of the node operators.

2025-01-13 19:01:26 GMT

- reply

Ideally this would be a service that TollGate operators can offer on a nostr market place. Perhaps with a premium for a domestic IP addresses..

2025-01-13 18:23:32 GMT

- reply

We need a better VPN solution so that TollGate operators can buy megabytes from a VPN in a granular manner after having sold megabytes to their users. Do you have advice on how to do that right?

2025-01-13 18:05:38 GMT

- reply

You can already do it if you and your users are willing to bear the UX inconvenience of the old architecture. Soon you will be able to do it with good UX on many different types of routers 😀
Have you orange pilled your neighborhood yet? If not, you can just sell them ecash and call it a "gigabyte". Normies generally feel safer when given shitcoins.. 😢

2025-01-13 13:33:56 GMT

## What is a TollGate?
TollGate is a set of tools that enables WiFi routers to accept Bitcoin payments for internet access. This allows anyone with suitable hardware and an internet gateway to operate as an internet service provider.
## What is nostr?
[Nostr](https://github.com/nostr-protocol/nips/blob/master/01.md) (Notes and Other Stuff Transmitted by Relays) is a simple yet powerful decentralised protocol that enables seamless JSON based communication between public keys through relay servers. In the context of TollGate, nostr serves as the perfect foundation for handling WiFi access payments by eliminating the need for traditional captive portals and providing instant, reliable connections through websocket technology. The protocol's relay-based architecture reduces common firewall issues while offering standardised payment methods. Its flexible nature means components can be deployed almost anywhere with minimal configuration, making it ideal for TollGate operators to set up and developers to maintain their services.
### What are the hardware requirements?
A TollGate must have at least two network interfaces. One interface connects to an internet gateway, while the other interface acts as a WiFi access point for users or other TollGates. Each TollGate runs its own DHCP server with a unique address range to avoid collisions with its gateway or its clients (who could also be running a DHCP server). Hence, each TollGate is a stand-alone system from a networking perspective. Finally, each TollGate has gate-keeping logic that manages firewall rules for allowing clients to access the internet gateway once they have paid and to cut them off again when their session ends.
Currently we are targeting [GL-AR300m](https://www.gl-inet.com/products/gl-ar300m/), [GL-MT300](https://www.gl-inet.com/products/gl-mt3000/?utm_source=website&utm_medium=menubar) and [GL-MT600](https://www.gl-inet.com/products/gl-mt6000/) because they come with `uboot` for system recovery and they support OpenWRT out of the box.
### TollGate's New Architecture
Previously we used WiFi captive portals like [nodogsplash](https://github.com/nodogsplash/nodogsplash) and [OpenNDS](https://github.com/openNDS/openNDS) for managing access to the internet gateway. These captive portals allowed us to quickly build a proof of concept. However, both captive portals came with severe UX and maintainability limitations - see [limitations of captive portals](#benefits-of-using-crows-nest-over-captive-portal).
A key benefit of building on `nostr` is that `services` can generate their own public key based identity (`npub`) in order to send and receive `json` content from other services as long as they have an outbound internet connection that can connect to public IP addresses. Nostr abstracts away the networking layer entirely, so developers don't need to think about things like firewalls, IP-addresses, ports and network boundaries.
Thanks to recent success that @origami74 had in running a nostr [relay](https://github.com/fiatjaf/khatru) and a [client](https://github.com/OpenTollGate/tollgate-module-valve-go) on the GL-AR300m, we are now able to build in ways that we could only have dreamt of before.
This figure illustrates the modules that TollGate is now comprised of:
![TollGate Modules](https://opentollgate.github.io/tollgate/tollgate_modules.jpeg)
And this sequence diagram illustrates the interaction between the services:
![TollGate Sequence Diagram](https://opentollgate.github.io/tollgate/tollgate-sequence-diagram.png)
TollGate is now comprised of three main types of services and a relay:
* **Crows Nest:** scans for available WiFi access points in search of gateways that are worth connecting to. Upon finding a suitable gateway, the crows nest rotates this devices `MAC address` and `npub` (for privacy), connects to the WiFi access point and submits a `payment event` if required.
* **Valve:** manages access to the internet gateway. Currently the valve is just a `nostr` wrapper around a CLI tool called [ndsctl](https://opennds.readthedocs.io/en/stable/ndsctl.html) for managing user sessions in captive portals. Thanks to the fact that the valve now has an `npub`, it can be controlled via events that are issued by the `merchant` service.
* **Merchant:** sets prices, redeems e-cash notes from `payment events` that customers issued and it issues events that the valve responds to. Merchants can be light weight and fit on the router if they outsource the e-cash redemption logic to third party APIs. However, thanks to nostr, the merchants don't strictly need to run on the router.
* **Relay:** simplifies connectivity for services. Nostr relays usually have a public IP address, though TollGates will also have a local relay so critical services that are in the local network continue to function when the TollGate loses internet access.
### What runs where?
Now that merchants are controlling `valves` via nostr events, it is perfectly fine for the merchant to be a more complex software bundle with an e-cash wallet and lightning support on an `x86 machine`. The merchant can just issue `nostr events` that control the valve irrespective of how the network connecting the `x86 machine` with the `router` looks. Having the ability to shuffle services around between devices like this enables TollGate contributors to create value with the skill sets that they already have.
#### Order in which devices are being targeted
The following table provides an overview of the order in which we hope to target various devices for each of TollGate's services:
<table>
<tr>
<th>Module</th>
<th>Low hanging fruits</th>
<th>Mid term targets</th>
<th>Long term targets</th>
</tr>
<tr>
<td>Crows Nest</td>
<td>Router, Mobile</td>
<td>x86, armhf</td>
<td>IoT</td>
</tr>
<tr>
<td>Valve</td>
<td>Router</td>
<td>x86, armhf</td>
<td>mobile</td>
</tr>
<tr>
<td>Full Merchant</td>
<td>x86, armhf</td>
<td>router</td>
<td>mobile</td>
</tr>
<tr>
<td>Legacy Merchant</td>
<td>router</td>
<td>-</td>
<td>-</td>
</tr>
</table>
##### Crows Nest
Routers need the ability to buy from other routers so that the network can grow outwards from the gateway. Hence, routers need a crows nest for TollGate based networks to scale. Previously, users interacted with the WiFi captive portals manually and they still can if they like, but it isn't recommended (see section [crows nest vs captive portal](#benefits-of-using-crows-nest-over-captive-portal)).
Users who own a TollGate can have the WiFi UX that they are already used to because they can connect to their own device using a WiFi password like they already do with their home router. They are not making any compromises since they are authenticating their devices on their own TollGate. The crows nest of their TollGate now purchases internet on their behalf without their client devices needing to know anything about TollGate.
Requiring that users own a router to get the full TollGate experience could hinder adoption. Sure, they can paste e-cash into the captive portal manually or with a script, but the UX depends on their client device and they have all the down sides of not making granular payments. Hence, users who want good UX without owning a TollGate would benefit from having the ability to install a [crows nest on their client devices](https://github.com/delcin-raj/tollgate-ui) (`mobile` and `x86`) for more granular and reliable data purchases.
##### Valve
Each TollGate needs to have a valve in order to manage access to the internet gateway. The valve runs on the router since that's currently our gate-keeping device. However, ndsctl seems to already have [debian support](https://manpages.debian.org/testing/opennds-daemon-common/ndsctl.1.en.html) so turning an `x86` or `armhf` machine into a TollGate might just be a question of getting the network interfaces and configurations under control on debian.
> Currently there isn't a clear line between ndsctl (which we rely on for gate-keeping) and the captive portal which brings a lot of complexity to TollGate. Hopefully the valve becomes more of a stand alone solution rather than a wrapper around part of a captive portal in future (see section [captive portal](#benefits-of-using-crows-nest-over-captive-portal)).
##### Merchants
##### Legacy Merchant
The "legacy merchant" is what we have been using so far. Its just a shell script that runs on the router and [submits incoming e-cash](https://github.com/OpenTollGate/tollgate-outdated-build-environment/blob/ebb875697ff7bb078382ece6107060f91e240809/files/cgi-bin/curl_request.sh#L287-L291) notes to a 3rd party API that redeems the notes over lightning and returns a HTTP response informing the TollGate whether the payment was redeemed successfully. This worked since day 1 of TollGate thanks to the robust and accessible cashu ecosystem and the fact that no cryptographic libraries or wallets need to run on the router. However, it meant that TollGate's feature set depended on the APIs of cashu developers who are also busy.
##### Full Merchant
Now that TollGate has full nostr support, operators can easily run their own e-cash wallet, lightning node and gateway selection business logic on an `x86 machine` and continue to interact with other components of TollGate as if this complex software bundle was running on the router. Clearly this model is more self sovereign and a faster route to building robust TollGates. We can still consider moving (part of) the merchant onto the router for more powerful routers or for `x86/armhf` based TollGates.
#### Benefits of using crows nest over captive portal
* **Lightning-Fast Connections:** crows nest eliminates the painful waiting and clicking associated with captive portals, enabling near-instant internet access. As a nostr client, it handles payments and authentication in the background without any user interaction.
* **True Privacy & Flexibility:** the crows nest architecture enables:
* Seamless switching between TollGates without wasting large amounts of prepaid data
* Identity (npub + MAC address) rotation between sessions making ISP data retention more challenging
* Protection against potential abuse since payments are small and frequent, with automatic verification of service delivery
* **Reliable & Consistent Experience:** captive portals are notoriously inconsistent across different devices, operating systems, and browsers. The crows nest provides a dependable experience by moving critical functionality to the client side, where we have full control over the implementation.
* **Universal Compatibility:** each crows nest comes with its own npub and produces nostr events, making it straightforward to add support for new devices. There's no need to deal with the complexities of scraping captive portals - devices can even pre-purchase data before switching networks.
* **Superior Performance:** our testing shows significantly faster session initialisation compared to traditional captive portal solutions, as we bypass the multi-second processing delays typically associated with router-based portals.
While a captive portal remains valuable as an on-boarding tool for first-time users, the crows nest enables seamless WiFi access. We believe this approach will eventually make the traditional captive portal experience obsolete for regular users. More detailed information about the issues we faced with captive portals and the solutions we already considered can be found [here](https://opentollgate.github.io/tollgate/early-development-and-mistakes-to-be-avoided).
Huge thanks to @nprofile…7u3d for making nostr so accessible for TollGate!

2025-01-13 13:29:46 GMT

- reply

Exactly, it is now easy for you to be the ISP who undercuts the cartel and delivers a cheaper + better service. They can try to stop you, but they can't stop all of us. It's a game of whack a mole again 😀

2025-01-12 10:04:46 GMT

- reply

Why not pay them SATs for data?
Most miners run at a loss, because anyone who sees an opportunity can compete with them. Once your paying Bitcoin for WiFi, anyone who sees an opportunity can deliver a better service to you.
Hopefully removing the moat from ISP businesses will make the market for connectivity super competitive.
https://image.nostr.build/aca195d42835b0db0456623b54495fc5c4f3e981d185d8e405052667b6656f88.jpg

2025-01-11 10:46:39 GMT

Wouldn't it be great if you could just walk into a conference and your phone starts streaming e-cash to the routers for faster and cheaper non KYC internet?
What are the best conferences for demoing TollGate in 2025?
#asknostr

2024-12-02 00:42:40 GMT

Your welcome to join this group for support with TollGate deployment:
https://signal.group/#CjQKIFUj7wFVxIbHjujYAWGTKeMIvi1DdVYk2Zem3uNlmIwWEhAiFlw7arUvnitB1V0_cTaA

2024-10-28 00:02:44 GMT

TollGate has a landing page for onboarding potential contributors now:
https://npub1suw0zfxerywd4zku4gjsjde22zhzye9dl2hsll6s3z2qap75p78s66lkhp.nsite.orangesync.tech/

2024-08-24 18:17:31 GMT

- reply

Maybe next time ... @nprofile…hmu7
https://image.nostr.build/d03030899ff1b8c8b948e6c6be8433b0118d1c753f46e834f19a0d71d6199828.jpg

2024-08-24 08:02:06 GMT

- reply

One sold, two to go :)

2024-06-28 12:18:04 GMT

This needs to be fixed https://image.nostr.build/18aa1e043c2b2caa8818e7053a82d2587c4644231378c0e6f7cec5b185fe68a6.jpg

2024-06-21 20:51:12 GMT

https://image.nostr.build/ab657e8fe163ae773f1c1b802ecd1203fd9376a5a9b8f914514b051d8ce801c1.jpg

2024-06-21 11:27:02 GMT

- reply

Would love to learn more about that package, maybe we can combine our efforts...

2024-06-21 11:22:21 GMT

- reply

Decentralization is hard to measure. Infrastructure is usually tree shaped for efficiency. Large routing nodes occur for efficiency reasons in the lightning network. Large internet exchange points and large substations occur in the communications and energy infrastructure for similar efficiency reasons.
Something that's nice about TollGate is the optionality. No contracts, no KYC and no big commitments. Just price signals that allow supply and demand to answer the questions that central planners think they have answers for.

2024-06-20 07:16:25 GMT

https://image.nostr.build/3428b70ccd06d30a9b363e17462ee8ffc8275ac2041be77a62ac9868083e9e73.jpg
https://image.nostr.build/92430dd8c85522bbe933bd21eefc660a6ed04334074a483bb13d4fe1c9404099.jpg

2024-06-08 08:57:25 GMT

- reply

Wifi doesn't typically have such good range, but nested captive portals could be a useful way to build free markets for connectivity on the pleb side of the internet gateway:
https://image.nostr.build/e3a615143321f52b7d5c33d6e017dfde51ec417f197fc4be22fc820f153c7c4b.jpg