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

nprofile1qqspp9hkhc9y6lcwesklfmfvs6plzsl0eq0whglvumd2m5hu5ax8anqprdmhxue69uhkymmnw3ezummjv9hxwetn09hxxtn5v43ksqghwaehxw309ahx7um5wghxx6rpd9kkztnfdenx7ufdcwp

Publishing to

bostr.orangesync.tech

nostr.chaima.info

orangesync.tech

Author Public Key

npub1zzt0d0s2f4lsanpd7nkjep5r79p7ljq7aw37eek64hf0ef6v0mxqgwljrv

Show more details

Last Notes

2025-09-07 18:41:07 UTC

- reply

Mostly permissions. Apps require user permission to connect to a new network for the first time. Traffic from a mobile access point could be difficult to tunnel through a VPN. Background Mode can be unreliable because the operating system prioritizes the battery over apps.
Ideally such features would be developed at the OS level. However, we also didn't have the bandwidth to go far down the mobile rabbit hole, because there are plenty of low hanging fruits in OpenWRT.
We are looking for mobile developers who know what's the right way forward. @nprofile…aud2 @nprofile…ympz

2025-09-06 21:25:32 UTC

- reply

Yes, please! Let's make a TollGate compatible client for mobile devices. We are aware of some of the challenges, but we want to help to make this happen.

2025-08-30 22:20:46 UTC

- reply

TollGates already have a relay. @nprofile…lcnq used the relay for his demo last cohort

2025-08-25 21:12:32 UTC

- reply

E-hash

2025-08-24 16:25:45 UTC

- reply

You can find us at this year's nostrhackday if you want to learn more about it. Perhaps Deutsche Telekom could benefit from adopting the protocol in future..
#nevent1q…vq9v

2025-08-18 22:03:51 UTC

- reply

https://github.com/aantonop/wifiportal21

2025-08-10 09:50:58 UTC

- reply

Awesome that you're trying it out!
There's a config file under /etc/tollgate/config.json where you can set the payout addresses.
If you need any help, we have a Signal group for TollGate deployments.
https://signal.group/#CjQKIFUj7wFVxIbHjujYAWGTKeMIvi1DdVYk2Zem3uNlmIwWEhAiFlw7arUvnitB1V0_cTaA

2025-08-10 08:55:16 UTC

Using TollGate on @nprofile…ntld with @nprofile…66ue.
#BH2025
https://cdn.hzrd149.com/4598af8d2d2c77b8fb9ba2a2d9abd6ff0c5b0046cd133a176f4f29c0707f4447.mp4

2025-07-28 06:51:22 UTC

- reply

Not sure, apparently there was an on-chain Implementation from Antonopoulos once though ..

2025-07-28 06:48:08 UTC

- reply

#nevent1q…pluq

2025-07-28 06:47:10 UTC

- reply

Not yet, because mobile devices have restrictive permissions. Maybe @nprofile…nztg can help us to navigate the constraints on mobile devices though..

2025-07-19 13:36:47 UTC

GM, see you in Riga...?
https://image.nostr.build/80982766efff4472885d733323088ece4bf4261c90b32ad62cf672a211ba226d.jpg

2025-06-11 22:35:40 UTC

- reply

Hashpool could also be useful for on-boarding people to TollGate without teaching them about money. Give them a router + bitaxe. They plug it in and they pay their electricity bill. Thanks to hashpool their routers already have all the e-cash that they need..

2025-05-29 16:40:37 UTC

TollGate is further decentralizing.
This npub is now managed by c03rad0r, c03rad0r and c03rad0r.

2025-05-28 10:05:00 UTC

- reply

#ThanksForBuildingTollGate
Different actors have different needs. In some places the TollGate operator needs to be stealthy (plausible deniability) even if that results in worse discover ability for users.
The difference types of TollGates are standardized as so called "recipes".
@nprofile…qtp5 started an entirely new TollGate recipe that is based on identity for a queuing system that he is building. Waiting tickets are nostr identities and npubs that are still waiting get free access to internet.

2025-05-28 09:50:26 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…a0kj helped by brainstorming around the challenges that TollGate faced before we knew how to target OpenWRT devices with existing nostr and e-cash libraries. One of his contributions, was the idea of using small time locked proofs to make the purchases more frequent and granular.

2025-05-28 09:49:40 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…6qgd is working on a simple "build your own TollGate from scratch" workshop for onboarding students who are new to Bitcoin onto this approach to networking.

2025-05-28 09:49:11 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…sqmy and @nprofile…lhu2 are among the first TollGate based internet service providers in Madeira. They operate TollGates at Cassa De Lavada and are ready to operate TollGates between their homes, thus enabling the first proof of concept that TollGates can cut costs by enabling hoseholds to share a gateway.

2025-05-28 09:48:09 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…z78s is a valuable TollGate contributor. He created informative slides for conferences, developed a TollGate website, designed stickers and t-shirts, and helped produce content to improve public understanding of TollGate.

2025-05-28 09:47:44 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…9m52 recently helped us to think through a nostr relay based approach to routing packets, such that authorities aren't required to organize IP addresses. If this is implemented and it works as expected, it would enable counterparties to send eachother HTTP requests in a synchronous manner through NATed networks as if they were using clear net IP addresses from IANA.

2025-05-28 09:46:57 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…74sv introduced us to the [image-builder](https://github.com/imaginator/TollGateFirmware) and the [SDK](https://openwrt.org/docs/guide-developer/toolchain/using_the_sdk), enabling us to produce OpenWRT packages within minutes instead of waiting over an hour for a full OpenWRT build.

2025-05-28 09:46:23 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…mncc helped to compile libsecp256k1 for OpenWRT targets at a time when TollGate needed a nostr signer, but we didn't know how to get suitable nostr clients to run on the router yet. More recently @nprofile…mncc made an e-cash frontend for x86 machines, which can be modified to automatically make small frequent granular data purchases from the TollGate on the users behalf.

2025-05-28 09:45:51 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…0anf is supporting TollGate by introducing contributors to the concept and by being the first to operate a TollGate in a co-working space, so that users are exposed to the idea.

2025-05-28 09:45:18 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…tx45 is developing a beautiful mobile wallet app for making small, frequent purchases from TollGates. However, they face challenges related to permissions on mobile devices, particularly when automatically selecting a WiFi gateway from within the wallet.

2025-05-28 09:44:38 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…m8jm, @nprofile…z8te, @nprofile…58km, @nprofile…srrg and @nprofile…k6nu were early TollGate supporters. They provided encouragement when there wasn't any demoable version of TollGate yet and they helped to boost the confidence of early contributors so that they could take the leap.

2025-05-28 09:44:03 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…pxlr contributed to TollGate with ideas and by brainstorming on blockers. @nprofile…pxlr worked on a Tauri based mobile app that sends http requests with e-cash in them to the TollGate so that TollGates could buy internet from other TollGates.

2025-05-28 09:43:07 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…mvvw was an early TollGate operator and he is a toxic TollGate maximalist. @nprofile…mvvw made rudimentary demos of what TollGate could do and harrassed people with the idea of TollGate till they helped him to improve on the existing implementation and/or make new iterations. @nprofile…mvvw is grateful for this first row seat to witness this new way of paying for infrastructure taking shape.

2025-05-28 09:42:04 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…7u3d is also a critical component of TollGate's ecosystem. He built the first iteration of the TollGate mobile app, he built an installer for TollGate-OS, implemented an e-cash wallet for routers, and he made the workflows that build TollGate packages more efficient with the help of docker registries. He built go code for OpenWRT targets which enabled us to use existing nostr libraries in TollGate. Arjen also drove design discussions with @sandwich and @hzrd to refine the way we interact with TollGates based on nostr events and that are generated in a client that lives in the captive portal - this is how the first iteration of [TIP-01](https://github.com/OpenTollGate/tollgate/blob/main/protocol/01.md) started.
Arjen also contributed to TollGate with knowledge about github actions, best practices in nostr best practices when programming. He event contributed by presenting TollGate at conferences and drawing in new contributors who had a significant impact on the project.

2025-05-28 09:40:58 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…yw4h is a core driver of TollGate's ecosystem. @nprofile…yw4h initially suggested building TollGate on e-cash and captive portals because e-cash is a bearer asset that can be used for payments even without an internet connection, and captive portals can manage firewall rules effectively. He helped us add new OpenWRT targets to our workflow and suggested using redeem.cashu.me for redeeming e-cash during TollGate's early stages. @nprofile…yw4h continues to contribute valuable R&D involving SIM cards, the GSM stack, and multi-WAN, driving significant progress.

2025-05-28 09:40:11 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…n5a2 made a simple [raspberry pi based TollGate](https://gist.github.com/elsirion/58d1af3f770bb683e30b7999306b77a3) completely from scratch by manipulating the firewall rules rather than relying on an existing captive portal.

2025-05-28 09:39:08 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…zpkd contributed by starting a [rust implementation](https://github.com/OpenTollGate/tollgate-merchant-rs) of TollGate's merchant module and he researched creating a version of TollGate that could run on a raspberry pi (armhf).

2025-05-28 09:37:43 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…9x4s helped us to find simple solutions around implementing TollGate. He pointed out that we could build on Sandwich's [TollBooth](https://github.com/OpenTollGate/tollbooth) concept, by getting a simple nostr client that runs client side in a captive portal to send HTTP requests to an open port on the router, which then processes the e-cash. @nprofile…9x4s also made [wifistr](https://github.com/hzrd149/wifistr), which will help TollGate operators to find free gateways that they can sell access to without needing to KYC.

2025-05-28 09:36:25 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…gw67 was always a valuable supporter to TollGate. He has a deep knowledge of technology and helps us to navigate problems around TollGate. @nprofile…gw67 started [TollBooth](https://github.com/OpenTollGate/tollgate-gui) to help us make a simpler captive portal that runs client side and he works on the user's device. @nprofile…gw67 and @nprofile…pxlr are also working on totem, the nostr version of [Tamagotchi](https://en.wikipedia.org/wiki/Tamagotchi), which could have its own TollGate installed in future.

2025-05-28 09:35:41 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…07tt contributed by creating an [endpoint](https://github.com/OpenTollGate/tollgate-outdated-build-environment/blob/main/files/cgi-bin/redeem_boardwalk.sh) for redeeming e-cash, similar to redeem.cashu.me. This provided TollGate operators with additional options for receiving e-cash, which was crucial when we lacked the knowledge to create custom wallets for OpenWRT targets using existing Cashu libraries.

2025-05-28 09:35:02 UTC

- reply

#ThanksForBuildingTollGate
@nprofile…8xj2 was one of the first contributors to TollGate. He helped figure out how to modify [nodogsplash](https://github.com/OpenTollGate/tollgate-initial/tree/main) to allow longer input strings in the captive portal, preventing truncation of received e-cash notes. This involved learning to compile OpenWRT packages for specific targets.

2025-05-28 09:27:56 UTC

📢📢 We have a new release of our tollgate implementation
Still plenty of work to be done, but please do try it out if your a brave and #reckless soul who wants to bridge the past and the future.
Your issues, your pull requests and your code review are most welcome!
For installing tollgate package on routers:
https://github.com/OpenTollGate/tollgate-module-basic-go/releases/tag/v0.0.3
OpenWRT image containing TollGate in-case you want to start from a clean slate. Any e-cash that's still stored on your router's filesystem gets deleted when installing the image:
https://github.com/OpenTollGate/tollgate-os/releases/tag/v0.0.3

2025-05-27 22:02:52 UTC

Running TollGate @nprofile…glpg Oslo
#cobrador https://image.nostr.build/41a01a9ec7982c46327909185286fa6f6deafbcd6ea47b0a26d1afb9c2d69a48.jpg

2025-05-27 21:59:44 UTC

- reply

Running TollGate
#nevent1q…p7e4

2025-05-15 06:33:36 UTC

- reply

Hey Ken,
We're a (still) small open source project that aims to empower people to (physically) build internet networks themselves instead of having tot rely on centralized ISP's.
We do that by building economic incentives into the network stack (routers/cell towers) letting anyone with some hardware earn Bitcoin.
One of our main challenges is how to incentivice people that may barely know about bitcoin to run a TollGate, earning them SATs.
We'd be happy to chat tell you more about it if you're interested in this topic!
Some more info here: Tollgate.me

2025-05-11 08:33:39 UTC

- reply

Come and meet us at one of the conferences this summer!
#nevent1q…dtqq

2025-04-10 01:01:27 UTC

- reply

Bitcoin is the routing algorithm.
#nevent1q…q3kq

2025-03-01 08:37:29 UTC

- 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 UTC

- reply

WIP, we are crowd sourcing the proof reading 😀

2025-02-27 09:32:46 UTC

- 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 UTC

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 UTC

- reply

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 UTC

- 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 UTC

- 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 UTC

- reply

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

2025-01-16 07:17:45 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

## 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 UTC

- 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 UTC

- 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 UTC

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 UTC

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

2024-10-28 00:02:44 UTC

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

2024-06-28 12:18:04 UTC

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

2024-06-21 11:22:21 UTC

- 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 UTC

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

2024-06-08 08:57:25 UTC

- 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