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.

LPWAN Meshes: Reticulum, Where I Landed covered Reticulum as a communications stack: transport-agnostic, cryptographically addressed, built for chat and file transfer over LoRa, packet radio, or whatever medium is available. This post is narrower on purpose: it breaks down the specific mechanics of moving a sensor reading, not a conversation, through Reticulum: which delivery method to pick, what a reading actually costs in packets and bits per second, and what already exists in the open-source community to build on rather than reinvent.

Earlier this year, in The Hidden World of Corporate IoT Spying, I looked at how consumer gadgets quietly turn personal spaces into corporate data collection nodes: robot vacuums mapping living rooms for foreign servers, smart TVs cataloguing every frame you watch, and Eufy security cameras quietly beaming unencrypted thumbnails and facial identifiers to the cloud despite marketing slogans promising “local storage for your eyes only.”

Seven months later, that trajectory has only accelerated. The news cycle around domestic cameras and automated surveillance has moved from occasional security quirks to systemic betrayal.

Starting 24 August, a popup village of builders, programmers, and ecological economists is settling into the Austrian mountains south of Vienna for a month. They are meeting in the Höllental, a valley of steep limestone cliffs and cold rivers, to run the Valley of the Commons: four consecutive weeks, each built around a different theme, commons economics, cosmo-local production, community living, governance and funding, tested against each other in the same physical place rather than argued about in the abstract.