Rebuilding the internet
A from-scratch internet already exists. Reticulum moves traffic over the existing internet, LoRa, packet radio, WiFi, or anything else that carries bytes, and no ISP assigns its addresses, no DNS resolves them, and no company sits in the middle, a network owned and run by the people on it. What it did not have was the layer that makes a network somewhere you can live, the search engine, the news, the maps, the clock, the encyclopedia, the store. This is the account of building that layer, service by service, and how building a search engine kept forcing the next one into existence.
In A Declaration of Independence I made the argument that you can leave the cloud, and I published the inventory of a house that did. Every service in that inventory still had one landlord left, the connection itself. The files were mine, the models were mine, the mail was mine, and all of it reached the world through a wire that an ISP owns, addressed by names a registrar rents me, routed by an internet that works until someone decides it does not. So I went a layer below the wire, to the network itself.
The thing I found is that the hard part is already done, and almost nobody has done anything with it.
The network is already built
Reticulum is a networking stack built by Mark Qvist and a small community over the better part of a decade, and its defining property is that nobody is in the middle of it. It moves traffic over whatever medium you have, TCP over the existing internet, LoRa radios, packet radio, serial links, I2P, WiFi, or any mix of them at once, and the people running nodes are the network, there is no ISP, no carrier, and no central authority anywhere in the design. Being unopinionated about the medium is also what makes it an on-ramp. A person can join over the internet today and add radio only when and where they need it, one link at a time, instead of buying into a whole RF stack before anything works. The radio does not have to be slow either. Higher-throughput links like WiFi HaLow carry enough to move video and other heavy traffic over the air, so going off-grid does not have to mean going back to text. There are no IP addresses to be assigned and no DNS to be seized. An address belongs to its owner the way a house key does, it cannot be rented out, repossessed, or reassigned, and a conversation on the network is between its two ends as a property of the design, not a promise in a policy. On top of it sit working applications, LXMF for store-and-forward messaging, LXST for real-time voice calls with no phone company in the loop, and NomadNet, the web of pages people publish and read on the mesh, written in a format called micron that renders over a radio link.
I did not build any of that. The building blocks exist. The architecture exists. The people who designed it solved the genuinely hard problems, routing without coordination, privacy without gatekeepers, transport without carriers. What the mesh did not have is the part the internet spent 1995 through 2005 growing, the boring, load-bearing services that turn a network into a place. A network with no search engine, no news, no maps, no clock, no reference library, and no commerce is a technology demonstration. The internet did not become the internet when TCP/IP shipped. It became the internet when ordinary people could find things, read things, and buy things.
So that is the project. I am not designing a network. I am building the what-do-you-do-with-it layer, on top of what better engineers already built, the same way the first generation of web services was built on top of a stack its builders did not design. Starting over from scratch does not mean starting at the bottom. The bottom is done. It means starting over at the layer where people actually live.
A search engine needs something to find
The organizing project is Beacon, a free and open source search engine for NomadNet, the mesh's web of pages, a crawler, a node registry, a full-text index, and a ranking stack. There is one existing mesh search engine, Roogle, and it is real and running and closed source, with a link-count ranking and a dataset of about 1,400 nodes and 54,000 pages. Naming a mesh search engine after the very company the mesh most wants to leave behind strikes me as poor taste. Beacon is an open alternative, and the ranking is where it competes. Beacon itself does not live on the open internet, and that is deliberate. It runs on the mesh and answers queries over Reticulum, not from a server you reach through an ISP, so the tool that makes the mesh searchable is something the mesh owns rather than something the internet lends it. Beacon ranks on full-text relevance first, then folds in announce-derived node trust, page responsiveness, inbound links and their anchor text, click data, declared metadata, and a semantic layer that matches on meaning, so a search for "atomic clock service" finds the mesh's time service even when no page uses those exact words. The keyword score and the semantic one are combined by reciprocal rank fusion rather than a hand-tuned blend, and if the embedding model is unreachable the whole thing drops cleanly back to pure full text, so a missing model costs quality instead of breaking search. A last fairness pass keeps any single node from taking more than a few slots on a page, so one chatty publisher cannot crowd the rest of the mesh out of its own search results.
But that is mechanics. A search engine has nothing to index on an empty mesh, so making Beacon useful meant building the things it would index.
Search also carries more weight here than it ever did on the web, because the mesh has no DNS, and that is a double-edged fact. No registrar can seize a name that does not exist, but an address on the mesh is a long hash that no human will ever remember or type, and a network you cannot navigate by name is a network the general public cannot use. That gap is closing, rns-resolve further down builds a naming layer the mesh itself controls, and the client work in our MeshChatX fork to resolve a typed name where people actually browse is under way, but it is early and not yet everywhere. On the web, search was a convenience layered over an address book. On the mesh, until names arrive, search and directories are the address book, which raises the stakes on getting them right, and on not letting the only one be closed. And the address book itself rests on announces. Those are the broadcasts every node makes to say it exists, and they work now but will not scale to a network of millions. The naming problem and the discovery problem are the same problem underneath.
Search results need titles and snippets, so the mesh needed a metadata standard. Ranking needs freshness, so the mesh needed a trustworthy clock. Users search for what happened today, so the mesh needed news. They search for places, so it needed geocoding and directions. They search for facts, so it needed the encyclopedia. They search for things to buy, so it needed a store. And none of it matters if running a service on the mesh stays a specialist's hobby, so it needed a way to put an ordinary service on the mesh without modifying it.
MeshData and MeshAPI
Two standards came first. Without a shared way to describe a page or an API, every service would invent its own, and every crawler and client would need custom code to read each one. A standard lets a service describe itself once and be read the same way by everything.
MeshData is schema.org for micron pages. A page author declares what a page is, an article, a product, an alert, a service, inside an invisible comment block that every micron client already discards, so it costs nothing to render, affects no legacy client, and adds no extra fetch. About a dozen page types map one-to-one onto schema.org types, the vocabulary the clearnet web already uses to label a page, so carrying a page's metadata across to the web, or back from it, is a rename rather than a rebuild. The parser is a tolerant line scan, one typo drops one line rather than the block, and when a page declares nothing, the type is inferred from the page's shape instead of failing. Beacon consumes it for categorization, result snippets, product cards, and publication dates, and pages that declare it rank measurably higher, which is the gentlest way to set a standard, a reward for the pages that adopt it and nothing worse than indifference for the rest. The reward is capped on purpose, a single flat boost with a hard ceiling rather than a point for every declared field, so stuffing a page with metadata cannot buy rank, and Beacon treats each declaration as a claim to check, sanity-testing publication dates and cross-checking the declared type against the page's actual shape before it trusts either. The web taught this lesson once already, metadata adoption follows the crawler that rewards it.
MeshAPI is OpenAPI for Reticulum. A service publishes a manifest describing its operations, their parameters, and their auth requirements, and answers a discovery request with that manifest live over the mesh, the equivalent of a web service's openapi.json. One manifest generates both the machine-readable description and the human documentation page, which is an interactive micron page whose "try it" fires a real request over the mesh at the real service. The docs cannot drift from the API because they are the API. Auth is per-operation and uses the layer the network already provides, a caller proves who they are by identifying on the connection with the Reticulum identity they already own. No API keys, no OAuth, no password database. The network's own identity layer is the account system.
rns-time, GPS time over the mesh
Time is the dependency under every other dependency. Ordering events, expiring caches, ranking by freshness, scheduling, logging, every one of them silently assumes a correct clock, and a machine that is off-grid has no cell network or NTP pool to lean on. So the first service was rns-time, authenticated time over Reticulum.
The house already keeps real time, a GPS-disciplined stratum-1 clock on battery backup that rides out a power cut, and rns-time shares it with the mesh using the same four-timestamp exchange NTP uses, carried over a direct Reticulum link. The link can only terminate at the clock's published address, which its operator alone holds the key to, so the answer is authentic by construction and nobody can impersonate the clock. The residual error is path asymmetry rather than latency, which makes the protocol degrade gracefully all the way down to LoRa. Measured over the mesh, a client three hops away synced to within 2 milliseconds. You can point a machine at it now, at ntp.quasarke.net, and the same clock answers in the public NTP pool at pool.ntp.org, handing GPS time to the open internet as much as the mesh. The mesh has no pool of its own yet, and it should have one. I plan to build it on the same peer replication that lets rns-resolve's resolvers gossip signed records to each other, a handful of independent clocks answering under one name so no single operator is the mesh's clock. That one is designed, not built.
The clock also serves software that has never heard of Reticulum. A meshtunnel egress fronts the same clock on plain UDP port 123, so an unmodified chronyd, ntpd, or Windows time service pointed at localhost syncs over the mesh without knowing the mesh exists. That pattern, a mesh-native protocol for new software and a tunnel for old software, recurs below, and rns-time was where it was proven first. Verified from a stock Windows machine over the public mesh path, the operating system's own clock synced against a GPS receiver it has no internet route to.
Beacon needs this too, and not abstractly. Freshness ranking, recrawl scheduling, and publication-date sanity checks all assume the crawler and the publishers roughly agree what time it is. On the internet you inherit that agreement from infrastructure someone else runs. On a mesh, somebody has to be the clock.
rns-geo, geocoding and directions
Geography turned out to be the most connected node in the whole graph. rns-geo exposes the house's self-hosted geo stack, the OpenStreetMap data through Nominatim geocoding, OSRM routing, and an Overpass point-of-interest database, as compact questions and answers over the mesh. Forward and reverse geocoding, turn-by-turn directions synthesized into plain text, and named points of interest by category and radius. Map tiles never cross the mesh, they are far too heavy for radio. The mesh does not need the map. It needs the answers the map exists to produce, where is this address, how do I get there, what is near me.
What makes rns-geo structural rather than just useful is who calls it. The weather service geocodes every place name through it. The alerts service geocodes every subscription through it. The news service's regional tagging leans on its region data. Beacon uses it for place cards on place-shaped queries, and for the opted-in "coffee near me" feature that resolves to real named businesses with distances and a directions link. On the internet that role is a Google API with a metered key. Here it runs on a box in the house.
Coverage is limited by the hardware I have. rns-geo can hold North America, so it answers for this continent and stops there. The fix is more boxes, a peered mesh of geo nodes where someone in another region hosts their own map and a query routes to whoever holds the answer. It is the same federation rns-resolve already runs and the time pool is headed for, and it turns global coverage into something the community adds to rather than a bill I pay.
rns-wiki, the offline encyclopedia
rns-wiki puts the offline reference library on the mesh. The house holds a Kiwix archive, the full text of Wikipedia alongside a hundred-odd other reference works, medical, survival, technical, and rns-wiki makes all of it browsable over Reticulum, rendered as micron, searchable across 108 English-language books, with working inter-article links so the encyclopedia is walkable end to end over a radio.
The rendering layer became its own project, html2micron, a dependency-free converter from HTML to micron that handles the messy markup Wikipedia actually ships, not a clean subset of it. Data tables render as readable text. Section deep-links work in a format that has no anchors, by re-rendering an article from the requested heading. Most of its value is a catalog of micron's quiet traps. A handful of characters at the start of a line, a backtick, a dash, a hash, are read as formatting commands and silently eat the rest of the line. html2micron escapes them, so an article full of stray markup renders instead of deleting itself on the way to a radio. It is the kind of invisible glue the Declaration piece called the actual labor, and it is published standalone because the next person putting a document archive on the mesh should not have to rediscover any of it.
For Beacon, rns-wiki forced the architecture question every search engine eventually faces, what to do with a corpus too big to crawl. The encyclopedia is millions of dynamically rendered pages; crawling it over the mesh is not a plan. So Beacon federates instead. A query fans out to rns-wiki's own search over the mesh, the hits merge into the ranked results, and an article that users actually click and link graduates into the main index. Crawl what is small, federate what is vast, promote what is used. The big search engines landed on the same three moves, sitemaps, vertical search, and click feedback.
rns-news, full-text news
A search engine that cannot answer "what happened today" is an archive. rns-news re-transmits full-text news into the mesh. A poller watches 34 feeds, nonprofit newsrooms, investigative outlets, and local dailies across roughly 27 US regions, fetches each new story, extracts the full article body down to clean text small enough for radio, and renders every story as its own static micron page on an announced node. An off-grid reader gets the whole story, not a teaser pointing at an internet they do not have. By the aggregate numbers, it is already the most visited of my NomadNet nodes.
Every article page carries a MeshData head block, its type, region, topic category, publication date, and the canonical source URL, and that is where the pieces interlock. Beacon crawls each story as a first-class page, so "colorado news" returns actual Colorado reporting, a city story answers a statewide query, and a reader can filter the live index by region, by topic, or both. The stories rotate, newest few hundred retained, sorted by their own publish dates. The regional list skews toward nonprofit and independent outlets for the same reason The Mild Take's own sourcing does, they publish full text without hostility and their incentives point at readers.
rns-news is a gateway, like several services here. The stories originate on the internet and cross into the mesh at my node. The mesh delivers them onward without any further internet dependency, but the gateway itself needs a working connection. A mesh where every region has its own news gateway, or better, its own newsroom publishing mesh-first, is the version of this that no longer needs mine.
rns-weather, weather forecasts
rns-weather answers the single most common question a person asks a network. Type a US place name over the mesh, get the National Weather Service forecast back. The place name geocodes locally through the same Nominatim instance rns-geo fronts, the forecast comes from api.weather.gov, and the whole exchange is a couple of kilobytes, comfortable on a slow link. It is deliberately unexciting engineering, standard-library HTTP on one side, a mesh link on the other, and that is the argument it exists to make. A useful internet service is usually a thin, honest translation between a data source and a person, and the mesh version does not need to be harder than that.
It also earns its keep inside the ecosystem. Beacon's opted-in landing page greets a user with their local forecast next to their local time and their region's news, three services composed into the first screen, which is the moment the collection stops feeling like demos and starts feeling like an internet.
rns-alerts, emergency alerts
Everything above waits to be asked. rns-alerts speaks first. It watches the National Weather Service alert feed plus the emergency channels, AMBER alerts, civil emergencies, evacuations, shelter-in-place, and pushes matching alerts to subscribers over LXMF, the mesh's store-and-forward messaging layer, the same channel their chat runs on.
Subscribing is a message. Send "subscribe" and a city or ZIP code to the alert service's address, and it geocodes the place, watches the alert feeds for that point, and pushes what matters. Severity is tunable per subscription; the life-safety categories come through regardless of preference. There are no accounts and no phone numbers, the subscriber's LXMF address derives from the same identity their messages already use. Active alerts also render as MeshData-tagged pages on a browsable node, so Beacon indexes the current emergency picture like anything else.
The service is honest about its limits. Coverage is US-only because the sources are. The feed crosses the internet at the gateway, so the scenario where the gateway's own connection is down, which is often precisely the emergency, currently degrades to cached and operator-originated alerts, and closing that gap honestly is future work, not a claim. And LXMF delivery is best-effort store-and-forward, which is a true and repeatable statement about every alerting system ever built, but it means this is a civic service, not a certified life-safety system, and it does not pretend otherwise.
rns-shop, an e-commerce platform
Commerce is where a network stops being a library and starts being an economy. rns-shop is a generic, self-hostable e-commerce platform that any node operator can run. A merchant writes a plain catalog file, and the system produces a browsable micron storefront, carts, checkout, order history, and delivery, all over the mesh, with no processor, platform, or marketplace between the merchant and the buyer. The catalog does not have to be written by hand. rns-shop can read a store the merchant already runs, a Medusa backend or a Squarespace catalog, so an existing shop reaches the mesh without re-entering a single product. For a seller already on one of those platforms, getting onto NomadNet is a connector and a config file, not a second storefront to build and keep in sync.
The identity layer is the part that could not exist on the old internet. A buyer's Reticulum identity is the account. Carts, order history, saved shipping profiles, and digital entitlements all key on the identity the buyer already has, proven to the network itself, and the account page states the consequence plainly, no passwords exist to leak. Payment settles on whatever rails the merchant enables, a manually settled invoice, a link out to any web processor for buyers who also have internet, or Monero that the store watches for with a view-only wallet and a fresh subaddress per order, so a spend key never comes anywhere near the mesh, and the receipt and invoice arrive by LXMF message. Digital goods deliver over the link itself, straight to the buyer who paid, gated on their entitlement rather than an unlistable URL. For physical goods there are shipping estimates, country restrictions that fail closed, and buyer messaging. Every product page publishes a MeshData commerce block, and Beacon reads it two ways. An ordinary query for "zine" comes back with a price chip and "buy a shirt" with a product card. Beacon also has a dedicated shop section that pulls every product it has crawled into one browsable storefront, assembled across the whole mesh from the metadata alone, so a buyer can find merch from stores they have never heard of without any shop having to list itself there. Mesh commerce became searchable and shoppable in the same month it became possible.
The first order went through on August 16, a five-dollar zine, bought by a friend as an end-to-end test rather than an organic sale, ordered over the mesh by an identified buyer, confirmed by LXMF, delivered over the link. It proved the path works, not that a market exists yet. The services above give the mesh things to know. This one gives the people building those services a way to be paid, which is what turns an ecosystem of volunteers into an economy that sustains itself.
meshtunnel, unmodified software over the mesh
Most of the services above were written for the mesh, and that cannot be the requirement, or the mesh gets exactly as many services as there are people willing to write mesh-native software, which is close to nobody. rns-time already showed the way out, the plain UDP tunnel fronting its clock, and meshtunnel is that idea turned into a general tool. It is a generic UDP tunnel over Reticulum, two small programs and no modifications to anything. The egress runs next to an existing service and announces it on the mesh. The ingress runs on the user's machine and binds the service's ports on localhost. The application on top speaks plain UDP to what it believes is a local server, and the traffic actually crosses the mesh. Reticulum has no port numbers, so the tunnel carries the destination port in a two-byte tag, which covers hundreds of ports over one link for free.
The wire format also reserves a bit for compression that the current build does not yet set. The plan is to fill it the way Codec does, a zstd dictionary trained on each protocol's own traffic and loaded identically on both ends, because a game's tiny packets do not compress one at a time but do compress well against a shared dictionary of what that protocol always sends. That part is designed, not shipped.
The identity layer comes along too, and it is better than what IP offered. Over a tunnel every user would normally collapse into one address, so the ingress identifies on the link, and the egress can track, allow, or ban by Reticulum identity hash. The hash cannot be forged, so nobody can wear someone else's identity, but a fresh one is free to mint, so banning it is no harder to escape than an IP ban until the identity is expensive to abandon. What makes it expensive is what accrues to it, the reputation, the purchases, the standing across services, until walking away from it to dodge a ban finally costs the person something an IP never did. For legacy servers that insist on seeing distinct client addresses, the egress can assign each identity a stable synthetic IP, so the old software's own logging and banning keep working unchanged against clients that no longer have IPs at all.
meshtunnel-launcher finishes the job for the person on the other end. One profile file describes a service, the tunnel, the ports, an optional hosts-file redirect, optionally the client software itself, and one command brings the whole arrangement up, with an install mode that makes it survive reboots. The NTP profile is the hello-world, a stock operating system clock syncing over the mesh with zero mesh-aware software involved. Any UDP service, a game server, a voice server, a telemetry feed, is now a config file away from being shareable on the mesh. This is the piece that changes the ecosystem's growth rate, because it converts "write a mesh service" into "point a tunnel at a service you already run."
EverQuest over the mesh
meshtunnel did not start as infrastructure. It started because I wanted to know if a real game could survive the mesh, and the answer mattered for a reason that has nothing to do with games.
People do not adopt a new platform because it is righteous. They adopt it when the things they already love work there, and they refuse it, forever and politely, when those things do not. Desktop Linux spent twenty years proving it. For years nobody moved, because the games ran on Windows, and it only started gaining ground the year Proton made the Windows game library run unmodified. A mesh that offers only new, mesh-native experiences is making the same twenty-year mistake. The test of the on-ramp is not a demo app. It is the most demanding, least portable, most beloved kind of legacy software there is, a real-time online game whose netcode predates the idea that the internet could be optional.
So the test was EverQuest, a 1999 MMO running against an EQEmu server, tunneled through meshtunnel with the client untouched and the server untouched. Login, world, chat, and zone traffic all crossed the mesh, and the session was not a ping test, it was an evening of actually playing, at 24 milliseconds over the TCP-carried mesh path, indistinguishable from playing over the internet. The per-player identity layer above came out of this too, because a game server needs to ban people. Banning the identity instead of the forgeable address closes the easy escape of reconnecting from a new IP, the way every IP ban in that game got slipped. It does not close the other one. A fresh identity is free to mint, so the ban bites only as far as the player's character and progress are bound to the identity being banned.
The boundary work is under way and I will put numbers on it when there are numbers. Over the internet-carried mesh, full play is proven. Over I2P and over LoRa radio, the honest expectation is a gradient, playable, then degraded, then chat-and-trade only, and measuring where those lines fall is the current experiment, with purpose-built probes and radio hardware on the bench. What is already proven is the claim that matters for the migration argument. The software people refuse to leave behind does not have to be left behind.
Beacon's opt-in personalization
Beacon's personalization stays on the mesh's terms. Accounts are opt-in and keyed to a one-way hash of the user's own mesh identity, so there is no password, no email, and no name anywhere in the system. A user who shares a ZIP code gets a personalized landing, their forecast from rns-weather, their local time, their region's news from rns-news, real businesses near them from rns-geo, and one-tap emergency alert subscriptions through rns-alerts. A user who shares nothing gets a page that is byte-identical for everyone. You can read the code and confirm that for yourself. The analytics that tune ranking are aggregate page views and search counts with hashed visitor identities, and the architecture is published with no raw identity ever stored. You can have the conveniences the surveillance internet claims require surveillance. The mesh version costs a ZIP code, given voluntarily and revocable at any time.
rns-resolve, names without an owner
The hash problem has a partial answer now. rns-resolve turns a human name into a mesh address. It is not a registrar that can repossess a name. It is not a blockchain that turns names into property. A resolver is just an ordinary Reticulum destination that answers a question, and a few hard rules keep it from becoming an authority.
A valid 32-character hash goes straight to the client and is never sent out. A resolver can never swap an answer for a destination you already have.
You can only register a name for a destination your own identity derives. The service computes the target from your identity rather than trusting one you hand it. Stamping a name onto someone else's address is impossible.
Records are self-certifying. You sign a record on your own machine, and every resolver that gossips it re-verifies the signature. Records spread peer to peer with no central copy to seize.
An answer is a ranked list of candidates with their evidence. It is not a verdict. The client pins the one it picks, and it complains loudly if a pinned name ever resolves somewhere new.
A clean slate let rns-resolve do something the internet never could. DNS carries a list of known problems that are almost impossible to fix now, because too much of the world already runs on them exactly as they are. Names had no cryptographic authentication until DNSSEC, which decades on is still not the norm. The root is one administrative point under one organization. A registrar holds your name and can be compelled to hand it over. rns-resolve answers all three by default, because there is no installed base to break. Records authenticate themselves. Every name begins from a root the user chose, so there is no central one. No registrar owns anything, because there are none. These were good proposals the internet could not adopt, blocked by its own installed base. Here there is no legacy to veto a good idea, so it simply gets built.
Search gets a reader around a nameless network, but it is not the same as being able to hand someone a name. Two independent resolvers already replicate signed records across the Quasarke mesh. The client side is a smaller change than it sounds, because clients already carry a petname system, a local table that maps a friendly name to an address. rns-resolve just teaches that table to ask a resolver when it does not already know a name. The patch that does it is written and already submitted upstream, and our fork of MeshChatX runs it today. What is not done is the part that makes it disappear into the network. The resolver has to ship in the clients people already run by default, not as a fork, and enough names have to be registered that the first one a newcomer tries is already taken. The mechanism is proven. The distribution is the frontier.
The limits
The job is not done.
One operator is not an internet. Nearly everything above currently runs on my nodes, which makes it a proof, not a civilization. Every service here is open source and self-hostable precisely because the success condition is other people running their own, and the gateway services in particular, news, weather, alerts, are only as resilient as the number of independent gateways.
The gateways still face the internet. News, weather, and alerts source from internet feeds and cross over at my node. Mesh-first publication exists, The Mild Take itself publishes a native mesh edition, but a mesh that only relays the internet's content has not yet replaced anything, it has mirrored it. The direction is more origination on the mesh side of the line. I can already originate some of this without the internet. My weather station and a satellite antenna give me the weather, and National Weather Service reports come in over ham radio, so the data enters the mesh straight off the air. What that buys is local by nature. The weather station reads my weather, not yours, and the ham reports reach only what is nearby. A mesh-native weather or news service is therefore not something one node can host for everyone. It exists only if many people each originate their own local slice and those slices peer together. The replacement for the internet's weather feed is not a better gateway, it is a network of local stations sharing what each can see.
The mesh is young and it drops. The crawler knows about roughly 4,700 nodes, and on a given day only a few hundred answer.
Discovery rides on announces, and announces do not scale forever. Everything that finds anything on the mesh today is built from announces, the messages a node broadcasts to say it exists. Beacon's node registry comes from them. So does the path a packet takes, and so does rns-resolve's list of candidate names. It works well at the scale of a few thousand nodes. It is still a broadcast, though, and its cost grows with the network. A world of millions of nodes repeating everyone's announcements to everyone is not the design that gets there, and the discovery and naming layers will need something quieter before the mesh is that big.
No human-readable names yet. The absence of DNS is real sovereignty and a real usability toll, and both halves are true at once. Today a person finds a mesh service through a node's announced human-readable name, a directory page, or Beacon, and rns-resolve above is the first running attempt to turn a typed name into an address without recreating the registrar, built from the network designer's own sketch of a resolver where every name begins from a root you personally chose rather than a global authority. It works in prototype on two resolvers and is not yet shipped in the clients people actually run, so the newcomer's first experience is still, for now, pasting a 32-character hash, which remains the single biggest usability gap between this network and one the general public could pick up.
The directory, if you want to walk it
Everything below is live on the mesh now. The public entry point is rns.quasarke.net on port 4965, and the web-side directory with current addresses is at rns.quasarke.net. Addresses on the mesh are hashes no registrar can take back and, as the limits above say plainly, hashes no newcomer can remember either, which is exactly what a directory page is for.
| Service | What it does | Where |
|---|---|---|
| Beacon | mesh search engine | github.com/wdunn001/beacon |
| MeshData | page metadata standard | github.com/wdunn001/meshdata |
| MeshAPI | service description standard | github.com/wdunn001/meshapi |
| rns-resolve | human names to mesh addresses | github.com/wdunn001/rns-resolve |
| rns-time | authenticated GPS time | github.com/wdunn001/rns-time |
| rns-geo | geocoding, directions, places | github.com/wdunn001/rns-geo |
| rns-wiki | offline encyclopedia | github.com/wdunn001/rns-wiki |
| rns-weather | US forecasts | github.com/wdunn001/rns-weather |
| rns-news | full-text regional news | on the mesh via the directory |
| rns-alerts | emergency push over LXMF | github.com/wdunn001/rns-alerts |
| rns-shop | mesh commerce | github.com/wdunn001/rns-shop |
| meshtunnel | UDP services over the mesh | github.com/wdunn001/meshtunnel |
| meshtunnel-launcher | one-command client profiles | github.com/wdunn001/meshtunnel-launcher |
| html2micron | HTML to micron rendering | github.com/wdunn001/html2micron |
The internet's second draft
The internet's application layer took a decade and a speculative fortune to grow the first time, and it grew in a particular order, search, then content, then commerce, then everything else, because search is where a network discovers what it lacks. The mesh is running the same sequence, except this time the accounts are identities their owners hold rather than rows in a company's database, the analytics are aggregate by construction, and the store cannot leak passwords it never collected. Getting to rebuild a layer from scratch means getting to decline, one decision at a time, every bad default the first internet accumulated, and the record of those declinations is scattered through every service above.
The fastest way to believe any of this is to go stand in it. Add rns.quasarke.net as a transport in a Reticulum client, open a mesh browser, and search for something. The web-side directory at rns.quasarke.net lists the current addresses. It is a small internet, and it is already there to walk around in.
William Dunn is the founder of Quasarke, a software development consultancy. Beacon, MeshData, MeshAPI, meshtunnel, and every rns service above are open source under the MIT license. Reticulum is the work of Mark Qvist and the Reticulum community.