Arjen on Nostr: Time goes fast! Another report has arrived... ...

Time goes fast! Another report has arrived...

quoting
naddr1qv…2zrd

We're already a few weeks into '26, which means it's time for another quarterly update! TollGate, GitHub actions, Resilient networks, it's all here!

---

TollGate

First of all, let's talk TollGate. On the software side I'm hitting some roadblocks, but i'll get to that in a second.

Community Calls

The good news first is that the community keeps going strong and is growing at an exponential rate. We've recently introduced TollGate community calls, every 21st at 2100 o'clock (at cobrador island)

Announcement

Event Driven development

Bitcoin events, that is. In November we went to my back-yard, Amsterdam, to show off tollgate at the open-source booth of the event. We had an amazing amount of engagement at the booth and ran out a big pile of flyers quickly. I'm deeply impressed and grateful for the care Pedro put into designing and printing these!

I've also been able to represent TollGate on stage in a panel discussion about KYC & Bitcoin. That was a first and a little scary with such a large audience, but I think it went well and I hope people realize that Killing Your Customer to death will only just kill innovation. Innovation that won't go a way, It will just go elsewhere.

Bitcoin AMS, panel discussion: Watch it here

While this event was going on we in parallel helped Dimi get a tollgate setup working at Adopting Bitcoin El Salvador. Well into the night we dove into a call to get it to work. We may have succeeded partially, but we learned a TON. Particularly that TollGate can also exist as a (OpenWrt) cloud deployment where the operator controls the full network of many accesspoints themselves. To be continued...

Onboarding

As part of our collective efforts to improve the onboarding experience for new cobradors (TollGate operators), I created this explainer video on flashing an OpenWRT router with TollGate OS.

Flashing tollgate video: Watch it here

Software

TollGate & Nostr

Initially I thought it was a great idea to "force" tollgate to be nostr-based. But as we're building implementations and want to keep the protocol open. We realised that although Nostr is an amazing addition, the TollGate protocol should not depend on it. Because then it's easier to get more implementations going, also on low-powered devices like ESP-32's. Though the PR is from after the new year, the discussions took place in the last few months:

Pull Request: View it here

TollGate & GitHub

Although TollGate can be developed on GitHub, principally we want to move away from it. Part of that mean moving over to a decentralized build-system as soon as it becomes available. As part of that I made our pipeline compatible with 'act' , a local runner for github pipelines.

Pull Request: View it here

Software challenges

A big annoyance in our development is unfortunately the unmaintained wallet library 'gonuts' we rely on still. I've had to hack in support for offline functionality earlier. Using a library that is not built to be used offline causes issues, like network timeouts, and deadlocks when we try to work around these long timeouts.

Although we are talking with the cashu team to move over to CDK, we're not ready to implement it yet. One issue that's holding us back is the binary sizes of CDK, making support for cheap routers difficult. But kudo's to the Cashu team on helping us out on this front!

We're considering to pull out the core functionality of TollGate into a 'core' library that handles the accounting. Making it pluggable in a rust implementation, but also usable on platforms other than open-wrt. like Desktop, ESP-32, etc..

(Jan '26): At least we're at the point where we support data measurement. Helping us making TollGate a viable option for reselling mobile connections that are metered per MB.

Pull request: View it here

---

CI/CD GitHub Workflows

One front where I had a break-through moment is defenitely the GitHub workflows! The revelation for me came when I did a new iteration on the idea, and while still mixing what would become Loom & HiveCI it served as a great tool for discussion.

When joining a Nostr developer get-together recently, the conversations really helped boil down the essence of what i've been trying to do. And two things remained:

Loom

What I found I really needed is a subprocess that runs somewhere other than my own machine. A job with a definitive start and end. An input, and x seconds later an output.

The idea is simple. Just like a subprocess in your own software, with cmd, args[], env vars and stdin that simply produces an stdout.

Then there are workers, they provide the compute. They advertise themselves with Architecture, cpu, memory AND pre-installed software.

This protocol provides the substrate trhough which CI jobs can run externally, but it's not limited to that. A worker with ffmpeg pre-installed can be used by someone in need of video-transcoding. The worker doesn't care, so long as someone's buying their compute. You provide the command, add a cashu prepayment, and get change when the job is done.

Demo video: Watch it here ( / first intro) Loom site: loom.treegaze.com Example run: Check it here (see nostr-events at bottom) Protocol: Check it here

HiveCI

The separation of concern shows here. A loom worker probably knows NOTHING about github workflows or CI/CD in general. But that is fine.

That's what HiveCI is for. The idea is that the logic that interacts with (n)git is captured here. It's a templating engine, that constructs Loom jobs in a such a way that it executes a github workflow file. And the results are published as a nostr events.

Demo: Announced it here HiveCI Site: hive-ci.treegaze.com Example job: Check it here (see nostr-events at bottom) Protocol: Check it here

Conclusion

I think further developing Loom is the way forward, because it's not just me with CI/CD benefiting from this general purpose compute. But anyone that needs to do some compute-intensive task. It also creates a market for people that want to rent out their compute.

Multiple people have shown an interest in using Loom + HiveCI as part of their git workflow, which I think is great, and a sign that it's the right direction.

---

The Network Stack

Research layer 2, 3 & 4

A good chunk my time the past quarter was spent on trying to better understand the lower levels of the networking stack. And I don't mean just how to configure a network, I mean the layers we have. Where does IP end and TCP begin. We always speak of these protocols as if they're one. They are NOT. They even live on different layers.

I've explored some ideas on how to overcome the issues I faced during an experiment for routing by pubkey. During that exploration I found that those issues are due to not properly separating the TCP and IP layers. Which is something that I believe makes it hard for ANY alternative to IP to get any adoption. They always replace BOTH, forcing ALL software on top to adapt, which will never happen. In my article "F*ck IP's" I tried to convey this idea and that it might be possible to route by pubkey (only replace IP) while leaving the upper layers in-tact.

It's been a lot of theory so far, I want to further explore this idea in '26, and do it by building out the practical experiments. Like the one mentioned in the article.

Article "F*ck IP's": Read it here Repo experiment pubkey routing: View it here

NoDNS

• I set up a public NoDNS resolver + a test-site, developed by k0

Post of public resolver: Read it here

nSite Deck

We've been talking about how great nsites are for a long time, but the reality is that the gateways and sites are quite slow/unreliable. During some of the off-days around christmas I made this local gateway.

It allows me to visit any [npub].nsite and it will load and download the site to my local relay+blossom (included in binary).

The goals: - Speed: Current nsite gateways are incredibly slow/unreliable - Offline use: Keep using nostr clients while offline. - Safety: Public nsite gateways are a huge attack factor.

It uses some of the things I learned since making NoDNS, like running a DNS server for just a single TLD like .nsite. I also found that it's useful to include a relay + blossom so there's no external dependencies. Both these things I want to include in the next NoDNS iteration.

Demo video: View it here The repository: View it here

Emerging vision

In the past few months, I've been extensively discussing with other devs the idea of independent, resilient, permissionless (physical) internet networks. How will we get there? As the year progressed the picture for me has become clearer. I see the goal, but I also see very actionable steps we can take now. But it requires cooperating.

Let me sketch the picture:

• We have a network, the size of a small town. maybe a 1000 devices max.
• The cable to the town is cut. No connectivity.
• DNS is inaccessible, we can't reach CloudFlare/Google's DNS servers after all.
• We can route traffic by IP inside the town.

Now, even if we have relays, blossom servers and mints on servers in the town. Nobody can reach them, as their 'identity' is tied to domain names (wss://relay.nostrville.com).

This scenario happens in real-life all the time. So, in the short-term I want the whole town to keep functioning. The components we need:

• 1k x relay - Every device stores some Nostr events.
• 1k x blossom - Every device stores some Blossom data.
• 1k x NoDNS - Every device resolves npub.nostr, making servers remain accessible during the outage.
• 100+ x nSite Deck - Serving clients to interact with relays + blossom.
• 1x 512 GB SD-Cards - To carry Nostr events & Blossom data.
• 2x legs - To cary in and out fresh data from the world on an SD. (1x would work, 2x preferable)

(1k x = each machine in network)

This is the challenge I want to propose in the upcoming SEC-07 cohort. We have the components, if we cooperate to create this resilient environment, nostr can survive anywhere.

Long term

Longer term we may need to find our way around IP all together in order to mitigate the centralized control over IP addresses. That's a way out there idea that needs further exploring separately.

Sovereign Engineering invitation: Check it here

My recent writing: - Article: Pac-Man the Web - Article: Fck Ip's - Article: Organic Tech