I’ve just spent some time in the hills between eastern Tuscany and north-western Umbria, and I kept running the same small experiment without meaning to. Walk into an ordinary osteria in a town nobody outside the province has heard of. Ask for the house wine. Ask where the oil on the table came from, and the cheese, and the meat in the ragù. The answer, almost every time, is a place you can see from the window.

In 2018, IBM and Maersk launched TradeLens: a blockchain platform meant to digitise global shipping, replacing the paper trail that follows a container from a Vietnamese factory to a Rotterdam warehouse with a single, shared, tamper-proof ledger. It had the backing of two of the largest logistics operators on earth. By 2023, it was dead.

I’ve spent a fair amount of ink on this site comparing LoRaWAN, LoRa mesh, and Wi-Fi HaLow: LPWAN and radio protocols shaped mostly by hobbyists, network operators, and the odd telco. There’s a fourth contender I’ve been putting off writing about, largely because it comes from a different world entirely. MIOTY didn’t grow out of a maker community or an open-source project. It grew out of Fraunhofer IIS research labs and the boardrooms of German industrial automation, and it arrived at the LPWAN table years after LoRaWAN had already set out the cutlery.

In the last post I left a sentence hanging on purpose: durability is a design question, and it matters who’s actually asking it. Here’s the honest version of why, and here’s where this whole run of posts actually lands.

In the last post I ended on a line I’d been putting off: the story has to go somewhere durable enough to survive the person who told it. I meant that more literally than it let on, and at two different scales: one person’s archive, and then something much bigger.

In the last post I named who FediFlick Archive is actually for: people using a photograph to hold onto memory, family, and place, not to make it look better. I ended by promising to explain why the phone, not the desktop, is where this actually starts, and why that’s not the whole story. Here’s that promise kept.

Last time I wrote here about stepping back from Flickr, I said the part worth carrying forward wasn’t the app, it was a practice: license generously, credit properly, treat a photo as something meant to be shared rather than hoarded. I left an obvious question sitting there, unanswered on purpose: shared with whom, and for what. “Everyone who takes photos” isn’t a real audience, and I don’t want to spend a small, community-funded project’s limited attention building for one that doesn’t exist.

So here’s an honest attempt at an answer, and it starts by naming who I’m deliberately not building for.

I’ve had a Flickr account since 2008. My own photostream sits past 4,800 photos now, and for a long stretch of that history it wasn’t just a place I put my own pictures. In February 2009 I wrote a HOWTO on this blog about posting straight from a Nokia S60 phone to Flickr, because, as I put it at the time, “a lot of my clients in the educational sector are starting to use Flickr as part of their online teaching.” I wasn’t a bystander watching open education discover Flickr. I was helping build the on-ramp for it, in a professional life spent almost entirely in EdTech, first at DETAFE, then building learning management systems at Brightcookie for over a decade.

Then, in 2011, I wrote a different kind of post on this blog, “Facebook - good riddance!”, deleting my account and declaring myself done with a company I’d never trusted. I illustrated it with a Creative Commons photo pulled straight off Flickr, credited to a photographer going by cogdogblog. That habit, reaching for a CC-licensed Flickr image whenever this blog needs one, has held for 15 years since, and it’s still the workflow described in this site’s own editorial instructions today.

This isn’t that kind of post. I’m not celebrating anything.

Every few years a piece of infrastructure I care about gets a new licence, and the reason given is some version of the same sentence: we need to stop the big players strip-mining this. I have written that sentence myself, more than once. The instinct is sound. A digital commons that nobody defends gets enclosed, and the people doing the enclosing rarely announce themselves.

So when Mark Qvist, the person behind the Reticulum mesh networking stack, replaced its MIT licence with a custom one built to keep the project out of corporate AI training sets and out of weapons systems, I understood the motivation completely. I just think it was the wrong move, and that the tool he actually needed was already on the shelf, tested, and free.

When I wrote LPWAN Meshes: Reticulum, Where I Landed earlier this year, I covered Reticulum as Mark Qvist’s reference Python implementation: rnsd, Sideband, NomadNet, all built on RNS. That was accurate at the time, and it undersold what was already starting to happen underneath it. Reticulum was never meant to be a Python project. It is a protocol, and a protocol with only one implementation isn’t decentralised yet, it’s just a single point of failure with good branding.

Part one and part two of this series covered how Reticulum and MeshCore actually move a sensor reading: LXMF’s delivery methods and Propagation Nodes on one side, a purpose-built sensor role and CayenneLPP encoding on the other. Both are genuinely decentralised, no shared infrastructure required beyond the nodes themselves. This closing part asks the question that decides whether that matters for a given deployment: what does the alternative, LoRaWAN, actually require to do the same job?

Part one of this series looked at sensor telemetry over Reticulum, and landed on a specific trade-off: Reticulum gives you cryptographic primitives (Destinations, Links, LXMF’s delivery methods) and leaves the shape of a telemetry deployment up to you. MeshCore takes the opposite approach. It has an actual sensor node role, a standard payload encoding, and a query model built around telemetry specifically, not general-purpose messaging repurposed for it.