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.

Farmers are accustomed to operating under pressure from both ends of their business. Upstream, four companies, Bayer, Corteva, Syngenta, and BASF, collectively control more than half of global commercial seed sales. Downstream, in Australia, Coles and Woolworths alone account for around 67% of grocery retail volume. The farmer sits in the middle, bearing the operational and climatic risks while having almost zero bargaining power at either end of the transaction. The Treadmill Nobody Chose covered this squeeze in detail. This piece is about the third pressure point layered on top of it.

Ask most people when farmers started cooperating and they will picture the grain co-op down the road, or a barn raising in a period drama: something quaint, something that grew up alongside the tractor and the telephone. The real answer is older than writing. For most of the roughly nine thousand years since people first settled down to grow food, cooperation was not a value farmers held. It was the machinery. A shared irrigation channel, a shared plough team, a shared calendar for who grazes which pasture and when: none of it worked without a standing agreement among neighbours about who did what, when, and what happened if someone broke the rule. Take the agreement away and the technology stops functioning, not because anyone lacked the tools, but because nobody had a way to run them past the scale of a single household.

I upgraded to Ubuntu 26.04 LTS recently, the first jump I’d made since 24.04, sticking to LTS releases the way I always have. Within days I was fighting AppArmor denials in my logs, snaps behaving differently to their .deb equivalents for no obvious reason, and the general low-grade friction of debugging the packaging layer instead of the software I actually wanted to run. I’d already documented one of these fights in public: getting Zoom’s camera working again on Wayland meant ripping the Snap out entirely and installing Mozilla’s own .deb instead, because the sandbox was standing between the app and the hardware and no amount of granted permissions fixed it.