2026 Q3 Report

• The windy road to TollGate
• Bringing FIPS to mobile
  • Going forward
• FIPS
• FIPS as plumbing for Tollgate
  • A second (more scalable) initial use-case
• Myco - Organic propagation of apps & data
• Talks & Events
  • Podcasts
  • Freedom tech summit & BTC Prague
  • Sovereign Engineering SEC-08
• Moving forward
  • TollGate
  • FIPS
  • Myco
• Reducing
• TL;DR; PRs/Code
  • OpenTollGate/tollgate-rs (branch)
  • jmcorgan/fips (13)
  • jmcorgan/fips-initramfs (2)
  • OpenTollGate/tollgate-module-basic-go (3)
  • Origami74/myco (32)
  • OpenTollGate/tollgate-os (1)
  • SatsAndSports/cashu_spilman_channels (1)
  • fiatjaf/pyramid (2)

A note on AI usage: My reports and blogs are always handwritten. I do use LLM’s for gathering information and minor (spell) error checking.

Ahh, it’s been a while since my last report. Writing these actually help me reflect on the last few months and whether or not I made any progress on my goals. Sometimes I feel mixed about the progress, but this time I feel like I’m heading straight towards my goals. Though it didn’t feel like that the whole way through.

My goal with these reports is to also tell you a story. A story about the windy road to simple solutions. Communicating that is not always easy and the order of developments can be very confusing, also for me during the process. There is more intuition involved in these things than I’d have anticipated. And the thing about intuition is that you can only start making sense of it when reflecting back.

§The windy road to TollGate

About a year ago now I did the first experiments that helped dissect the protocols that make up the internet. TCP, IP, UDP. This was because we realized along the road to TollGate that in order for TollGate networks to flourish, they need to be built on a flat structure.

One TollGate needs to be able to trade data with every reachable peer nearby, not just with a mighty ‘parent’ gateway above it.

That has led to the creation of FIPS, which enables us to reshape TollGate into something that is only concerned with the accounting of the resource, which is data. And no longer with questions like “who do we connect to?”, “how do we prevent spoofing (impersonation)?”.

In the weeks and months prior to Sovereign Engineering I’ve been quietly working on redesigning TollGate around all the learnings we’ve gathered in the last year or so. Addressing our wrong or incomplete assumptions, like:

• We always pay the gateway above us, they never pay us
• TollGate is only a tool for traffic payments
• TollGate needs to directly charge monetary value (sats) for its service

In the initial redesign I decoupled TollGate from the network aspect. Turning it into two parts:

TollGate-core
This concerns itself with the basic messaging of the protocol, agnostic of resource, so it can sell data, electricity, liquids (fuel, water, beer), or anything else that makes sense.

TollGate-network
This part specifies how to use tollgate with either an IP network or a FIPS network.

One thing didn’t sit well with me though, and in some conversations with other people I expressed that something didn’t feel right about how I was dealing with the monetary aspect of things. I added a ‘pricesheet’ mechanism where one TollGate advertises its price and tiers you could purchase. Which sounds fine at face value but it’s almost impossible to automate the purchasing side. Because something felt off about my approach, I didn’t really continue implementation for a while because of it.

Shortly after those conversations, at SEC-08, during a hike (THIS is what @Sovereign Engineering is great at) I got introduced to the idea of making each TollGate its own cashu mint. Where the cashu tokens don’t represent sats, but they represent the provided resource. Bytes. Which get spent over x seconds, giving you a fixed bandwidth over the next x seconds. This changes the game entirely.

Why is that so special? Because then the protocol is solely concerned with the accounting of the resource consumed. The responsibilities of the monetary aspect get cleanly separated from the provisioning of the resource. I can give away bytes, I can sell bytes, I can exchange bytes.The TollGate protocol itself doesn’t have to care anymore, because all it now cares about is that it received a byte proof, so therefore it will deliver a byte. Period.

The unit is not the only concern that has been resolved. Because a big piece of complexity came from the issue that a mint may not always be reachable by the customer. Well, with the TollGate now being the mint, it is always reachable, and it will be bloody fast as well.

Just the challenged assumption that we need to charge sats directly was the last puzzle piece. Following that conversation I reworked the design docs, which solved every open concern I had and the design got massively simpler.

Read the documentation for this model here.

The next months will be the moment to go full steam ahead on this design.

§Bringing FIPS to mobile

I spent a good chunk of time on getting FIPS to work on mobile, mainly because I wanted to see the native transports work and bringing the mesh to a platform that can benefit a lot from a general-purpose mesh.

I created Myco as a test case for FIPS support on android. It was not very straight-forward to get FIPS to run on there because the OS has many more limitations as compared to desktops. You can have only one TUN adapter, which has to be spun up by the (android) app, rather than by the FIPS process. fips#127 Unfortunately Android only allows for one of those at a time to take its ‘VPN slot’. That’s quite annoying as you can’t use the TUN adapter while having another VPN running. The node can still run and route traffic, but you can’t use it yourself.

I also worked on WiFi-Aware support, which is peer-to-peer wifi between phones. And in order to bridge the mesh on mobile to a wired mesh, I added mDNS support on mobile as well myco#16. It lets any phone that’s connected to an access point (SSID) to peer with other nodes in the same LAN network.

I did run into a plethora of issues that all stem from the assumption that each pair of peers has only one transport between them. But with BLE + WiFi aware, that assumption breaks. When 2 transports are available they just fight each other, causing instability. I quite enjoy uncovering these issues, it’s all stuff that you wouldn’t think about in any kind of traditional network. A solution is currently in pr fips#167 (open) on the fips side and myco#50 on the Myco side, which makes a mobile mesh way more stable.

§Going forward

I’m not the only one to embed FIPS on mobile. Fr34ky also created his fips2go app. Our goal is to work together on a drop-in library that any app can use.

There’s 2 problems we’d like to solve with that:

1. Stop every app from having to build its own embedding from scratch, so devs can ship FIPS apps, without requiring a separate FIPS app to be installed.
2. Since there’s only 1 VPN slot, not every app that embeds it can be on at the same time. We’d like to provide a mechanism for the embedded version to delegate to a dedicated FIPS app if present.

§FIPS

Aside from the mobile support I worked on getting the physical auto-mesh where you can chuck a router in the corner and it just starts meshing with other routers around.

I added this 802.11s mesh backhaul support to OpenWRT which enables the routers to send ethernet packets without an explicit access-point connection. This is a very important piece for TollGate as well as it alleviates TollGate of much of the decision making of who to connect to.

As mentioned in the mobile section, working with the physical mesh uncovered some issues around multi-transport peers not being supported (yet). This issue also occurred here as we might peer over wifi AND have a cable plugged in at the same time. It would cause constant flapping (=downtime). fips#167 (open) addresses that.

Another small thing on the OpenWRT side was to add an open “!FIPS” SSID that allows clients to roam around any AP with this name and auto-peer with it’s FIPS node. This is especially useful for phones that may be on the move all the time, they will then auto-connect to that AP and be able to reach the greater FIPS mesh. I think this is really exciting because I think you can achieve cellular(5G)-like roaming this way.

§FIPS as plumbing for Tollgate

As mentioned earlier, TollGate can be applied in more areas than just data, but here I want to talk about the 2 cases where it is applied to data.

Over the past months it became clear that TollGate as we’ve approached it so far hit too much complexity in the networking stack. The lack of identity and the forced IP tree-structure introduce a lot of complexity. Precisely the issues that led to FIPS, and now that it’s there and the native transports for FIPS (ethernet, BLE) are becoming more usable it’s the right moment to start using FIPS as the foundation.

This also means the nature of the payments changes. Instead of being one-directional (child pays parent), it becomes bidirectional: you pay for data I forward to you, and vice versa. A TollGate on FIPS has many peers and you don’t know where the traffic will come from or go to, therefore you need to maintain communication and payment channels with each of them, simultaneously.

Since the mint will now live on each TollGate itself, you can always reach it during a session. Acquiring a peer’s byte-tokens may still require connection to a mint like minibits of course, but that’s now an interaction that can be solved outside of the TollGate spec.

§A second (more scalable) initial use-case

Another use-case that I think will scale more on the short-term is that of IP exit-nodes, aka VPN’s. A FIPS mesh will not have IP’s, only gateways that are connected both to the mesh AND to the IP network can provide you with access to the wider internet.

This can be your own device at home, OR it can be a VPN provider which can use the TollGate protocol to charge for bandwidth. I stream sats to them, they open the (Toll)gate for me. I think this is a more immediate value and less complexity than physical router deployments.

I think this can be a great way to get more people to deploy TollGate and gather feedback that we can use in the physical TollGates. Any feedback on this topic is welcome.

§Myco - Organic propagation of apps & data

I started to work on Myco for 2 reasons. To bring FIPS to mobile, and to get a point across about the new paradigm I believe we should be following with nostr. We can have fully functioning, high-speed networks, even if ‘the internet’ is down. I wrote Pillars of Propagation to explain what I mean, but I thought this vision would be better served by an example, which became Myco.

The point was to utilize Nostr + Blossom in a way that assumes only local, organic propagation, meaning zero central servers. And we can use that mechanism to not only transport relevant content that we produce with Nostr-based apps. but also transport the apps themselves. Completely removing our reliance on an active outgoing internet connection whatsoever. The combination here is important, it must be Nostr + Blossom + FIPS, take away one and the model won’t work smoothly enough to make a difference.

In short, with the app you can bump phones (NFC) to share an app, which is an nsite or napplet. Then in turn that app can use the mesh in order to send out a nostr event, replicating to several hops away.

As an example app I built Bitchat and a disaster-response app (ICS). The nostr events get sent to people you bumped phones with and they forward it a couple more hops to their connections. Same for subscriptions. This makes it so that anything relevant gets seen and re-broadcast through the mesh organically. You benefit from the FIPS mesh, even when part of the mesh does NOT have Myco. And you benefit from Myco users that forward your Nostr events, even if they don’t use this Bitchat or disaster-response app.

I recently added Napplet support. link

§Talks & Events

I have attended a few events and done a couple podcasts over the summer.

§Podcasts

I went on the Open markets podcast to talk about FIPS and some of its potential use-cases. link. And recently had a chat with Gigi about many of the topics in this report.

§Freedom tech summit & BTC Prague

In June I was invited to speak about FIPS at the Freedom Tech Summit in Prague. I gave a talk about the Pillars of Propagation and a workshop on how to set up FIPS on your computer.

FIPS received a lot of interest during both conferences which I take as a good signal we’re solving a real problem.

§Sovereign Engineering SEC-08

Soveng saw a big boom in development around napplets and it really demonstrated its powers. It’s like magic to be able to generate an app within 5 min, that then works across all platforms, and is not dependent on any compilation, or installation effort from the end user.

We also deployed a real FIPS mesh between routers using the 802.11s backhaul, this is a special mesh-mode supported by most modern routers. What’s really interesting now is how FIPS by nature is SOOO good at bridging all transports. Because Android has only wifi-aware and wifi-direct but not this 802.11s mode. It can’t naturally jump. But a phone that is wifi-connected (access-point) to a router CAN bridge this. Fusing the two different transports together. This is a really powerful characteristic and should not be underestimated.

Anyway, this real mesh was made by putting a massive antenna-dish up on the highest floor of the building we worked at, directed at one of the participant’s apartments, creating a direct connection to their nodes. And we were able to connect to their apartment, solely over ethernet, with decent ping-times.

Another experiment I’ve done during SEC is the remote LUKS decryption of machines. For security of data at rest, people use LUKS, which encrypts an entire server’s filesystem, and to decrypt it, the machine boots a stripped-down version of linux with almost nothing in it. By adding FIPS to it, we can ssh in over fips, without any accounts and enter the password remotely. This is something that can be quite a hassle to set up with something like TailScale, which requires logins etc.

Other than installing FIPS, there is no config required. Adding a new server could be nothing more than plugging in the cable.

I worked on a NixOS version: #1 & #2

§Moving forward

§TollGate

In the coming months I will focus my attention back to TollGate and work on implementing the new design and thoroughly testing it.

I want to have actual deployments for FIPS exit nodes up and running, preferably by other people than myself. As I think that will provide good feedback on the design and implementation.

It is now just a matter of putting my head down and working out the software.

§FIPS

I will continue to work on FIPS the way I have been. My main focus there are the Android and OpenWRT deployment targets. This includes continuing work on multi-transport peers, bridging more transports and working on stability in environments with many (physically) moving nodes.

Johnathan is in the process of formalising the v2 specification as an RFC which I also read and provide feedback on. V2 will solve some fundamental issues that cannot be solved in the current V1 version of FIPS. Most notably: scaling from the current maximum of ~1600 nodes to about 4 million, application (pub)keys instead of a single node pubkey, and signed paths to root (Spanning Tree).

This will undoubtedly create more work on the integration/embedding side which I’ll work on.

§Myco

I will continue to maintain Myco as a testbed for both FIPS and as a Napplet Runtime for mobile. Planned features:

• Account support, login using nsec/amber to use Napplets with your own npub
• Add more demo Napplets that use mesh and create skills/tutorials on how to make them.

§Reducing

“What is the most important thing you could be working on in the world right now? And if you’re not working on that, why aren’t you?”

― Aaron Swartz

Because I see that TollGate and FIPS are the most important thing I could be working on, I will reduce the time I spend on things that are less impactful.

I will not actively work on Loom, SugarDaddy and NoDNS anymore. I will happily consult with anyone that’s interested on picking up those projects.

I personally feel that the last 1.5 years have been the discovery phase of the pieces of technology we need to truly decentralize our digital life. Now I think I have all the pieces, and it’s time to pick the most important ones and work with those.

§TL;DR; PRs/Code

Here’s a bunch of the most relevant PRs over the past few months.

§OpenTollGate/tollgate-rs (branch)

The greenfield voucher node lives on a branch. Or go directly to the Documentation.

§jmcorgan/fips (13)

§Features (8)

§Bugfixes (5)

§jmcorgan/fips-initramfs (2)

§Features (2)

§OpenTollGate/tollgate-module-basic-go (3)

§Features (2)

§Bugfixes (1)

§Origami74/myco (32)

§Features (23)

§Bugfixes (9)

§OpenTollGate/tollgate-os (1)

§Features (1)

§SatsAndSports/cashu_spilman_channels (1)

§Features (1)

§fiatjaf/pyramid (2)

§Bugfixes (2)