A Wall, Some Birds, and The Internet Protocols We Aren’t Looking At.

It was a cool Berlin morning, the kind where coffee is more motivation than ritual. From my patio I stared at the usual graffiti-free stucco wall, a plain stretch capped by red brick. A blur of wings caught my eye. A small bird veered into a drain hole near the roofline and vanished. Another head appeared from a different hole, chirping.

Five drain holes, five nests. The gutters were meant to move water, not host families, yet the birds had found shelter, cover, and easy access. I had never noticed because I had never bothered to look.

Life doesn’t ask for permission. It finds a way.

While I was watching these little families do their thing far above my head, I had that annoying kind of realization that doesn’t go away. The kind that nags at you until you build something or lose your mind.

That’s when it hit me: Our digital infrastructure is full of holes like those drainpipes. We built the internet like utility tunnels and plumbing, where form follows function. Most protocols, like DNS (which translates domain names to IP addresses) or MQTT (a messaging system for IoT devices), were made to transmit data and vanish, not to hold it. Yet they’re wide open, with few guardrails and little scrutiny. Decades-old, they still route, respond, and hum along, ripe for new uses. Because of all of that I started work on a Proof of Concept called PICARD: the Protocol-Introspecting Chunk Adapter for Resilient Data.

TLDR: It tries to turn any protocol into useable storage

PICARD doesn’t care if it’s DNS, MQTT, ICMP (network diagnostics), or social media posts. Picard makes it so regardless the means. If it can carry a message, PICARD hides encrypted data in it, scatters it into the protocol like birds taking to the wing, and pulls that data back out on demand. Like birds nesting in drainpipes, it’s not elegant, but it’s adaptive. For example, activists might stash messages in social media posts to evade censors, or researchers could store data across protocols to survive outages.

PICARD’s goal is to encrypt data, slice it into protocol-friendly chunks, and quietly hide those chunks across whichever protocols are currently available to it. Some chunks go into DNS TXT records, as posts in Social Media or several at once in parallel.

Each chunk is labeled just enough to be reassembled and decrypted. No leaks, no clear-text. Just enciphered data and metadata stuffed into protocol statements that can be verified but not abused. If one adapter fails, another fills in. If they all fail, the data is gone. Just like the birds in winter; but hey if you’re lucky the birds or your data will return when conditions are better…

The neat thing about it is it doesn’t brute-force anything, nor does it actually exploit any code. It very smartly takes up space in protocols previously seen as useless, unused, or that have been repurposed.

PICARD presents a user experience as a File System User Space (FUSE) mount point, serving a locally mounted file system that just lives in between the gaps of our digital infrastructure but visible from a folder on your computer.

What we used to think of as protocol noise, waste, and trash is now viable space for persistence. Just like those birds figured out that a 5 cm concrete hole was enough to raise their family.

We treat protocols as open plumbing.

In the wild, anything left open long enough becomes habitat.

How it Actually Works

Think of PICARD as a flock of clever little birds of different types all working together. You give it a bag of seeds representing your data, and it doesn’t squirrel it away, instead it opens the bag, uses cracks in the digital infrastructure, to fit chunks of seeds into those cracks, tucking that data into the protocol it like a nest built out of twigs and trash in a drainpipe.

Functional overview

PICARD
├── Orchestrator
│ ├── Encryption Layer (AES-GCM)
│ ├── Chunking Engine
│ ├── Metadata Tagger/Local Index
│ ├── Adapter Manager
│ │ ├── Availability Checker
│ │ └── Retry / Fallback Logic
│ └── FUSE Mount Interface
│ └── Presents as Local Filesystem
│
├── Adapters/
│ ├── DNS Adapter
│ │ ├── TXT Record Writer
│ │ └── TXT Record Reader
│ ├── MQTT Adapter
│ │ ├── Retained Message Writer
│ │ └── Topic Reader
│ ├── ATProto Adapter
│ │ ├── Post Uploader
│ │ └── Feed Scanner
│ ├── ICMP Adapter
│ │ ├── Covert Payload Embedder
│ │ └── Response Parser
│ └── Custom/Niche Adapter(s)
│ ├── write_chunk()
│ └── read_chunks()
│
├── Data Flow
│ ├── write_block(path, block_index, data)
│ │ └── Encrypted → Chunked → Tagged → Distributed
│ └── read_block(path, block_index)
│ └── Retrieved → Verified → Assembled → Decrypted
│
└── Environment

Adapters: Nesting Modules

Adapters are simple creatures. They don’t know what they’re hosting. They don’t care. Each one handles a specific protocol and knows two things:

• How to wedge a chunk of data in to the protocol
• How to pull a chunk back out

They don’t manage encryption or track state. They don’t preserve intent. They just offer shelter.

Every adapter has a profile that tells it what size chunk it can carry, whether the nest is temporary or permanent, whether it keeps things in order or flings them into the wind.

Some are solid like DNS. Others are ephemeral like ICMP. PICARD doesn’t judge, it adapts.

Adapters: Writing Data

Writing Data (`write_block(path, block_index, data)`)

1. The data block is encrypted by the orchestrator with quantum safe encryption, camouflaged, disguised, so it doesn’t advertise itself and difficult to decipher if it ever is discovered.
2. That encrypted data block is then split into chunk-sized bits by the adapter to match whatever the storage environment can handle; DNS TXT records, MQTT payloads, Social Media post size limits. Each one small enough to slip in and roost.
3. A lightweight tag is added to each: just enough metadata so the pieces know who they belong to and where they go.
4. These chunks are then scattered across every available nesting site in every protocol that’s open and willing, or at least those that the orchestrator knows of. If one adaptor can’t take it, PICARD flies to the next.

Adapters: Reading Data

Reading Data (`read_block(path, block_index)`)

1. PICARD fans out again, checking every place it might’ve nested.
2. Any valid fragments it finds are collected. A small central metadata map, memory and pattern-matching are the key to its persistence.
3. If all the pieces come home, they’re validated, reassembled and decrypted into the original block.
4. If some are missing, PICARD checks the next branch, the next gutter, the next forgotten ledge and collects them all.

It’s not elegant. It’s adaptive.

The Orchestrator: Migratory Instinct

The orchestrator is the flock’s shared instinct. It decides where to fly, when to scatter, how to rebuild the original from whatever’s left.

• Encrypts and splits data
• Assigns metadata like nesting tags
• Tracks which protocols are usable
• Directs piece transport to adapters
• Collects, validates, and reassembles when needed

[Data] → [Encrypt → Chunk → Tag] → [Adapters: DNS, MQTT, etc.] → [Stored]
[Retrieve] ← [Adapters fetch chunks] ← [Assemble → Decrypt] ← [Data]

On the user side, it’s mounted like a regular filesystem through FUSE. Files show up where they’re supposed to. Underneath, everything is happening slowly in back channels, hidden cracks, and forgotten protocols.

There’s no index server. No headquarters. No monthly storage fees, No public registry. There is also no speed or warranties. Everything is decentralized, opportunistic, and persistent only as long as the environment allows. Just like the birds in that wall. No one’s watching them. No one’s in charge, but the birds are still there.

Downsides

PICARD isn’t magic, perhaps it is poetic. It certainly is not efficient, will not be fast, and offers zero guarantees. Reads, if they’re even possible will be slow, writes might partially fail, and if too many chunks go missing, your data is just gone. There’s no index, no global view, no versioning unless you build it yourself. Feel free to contrib! (GITHUB)

PICARD works best for small, critical datasets (e.g., a few MB), as larger files increase risk of chunk loss and increases already slow retrieval times.

As protocols evolve or get patched, PICARD’s adapters may need updates, much like birds adapting to new environments.

PICARD skirts the edges of what many protocols were ever meant to do. CISOs and sysadmins won’t love that. While it doesn’t exploit anything directly, it inhabits assumptions. Those assumptions weren’t built with this kind of activity in mind. If you need guarantees, if uptime matters more than resilience, or if you expect everything to behave or even work without some hacking, then this probably isn’t for you.

Practical Use cases

Censorship Resistance: Activists in restrictive regimes could use PICARD to hide encrypted messages in social media posts or DNS records, making it hard for censors to detect or block.

Disaster Recovery: Researchers in remote areas could store critical data across MQTT and DNS, ensuring it is deliverable in emergency situations.

Why?

Why bother building this at all? Part curiosity, part fun, good-mischief, and part reminder that every boost in bandwidth invites new, uninvited tenants. Sparrows never filed building permits, they spotted gaps in concrete and built nests. PICARD follows that playbook. It is not a product, platform, or grand solution. It’s only a working hypothesis that data, like wildlife, will colonize whichever crevice protocols leave open. As networks grow wider and faster, the vacant spaces multiply; something will move in. Consider PICARD an early field guide to those roosts. A proof that if the world’s plumbing forgets to seal a joint, life, digital or otherwise, will slip through and thrive.

A Final Word on Ethics

Ethics in this context is the mortar between the bricks, not an optional coat of paint, but what holds this up. If we decide the gutter is fair game simply because no one bolted a lock over the drain hole, we become the pigeons that foul every ledge and wonder why the neighbors hate us. Exploration is fine, even necessary, but it comes with the obligation to think through collateral damage, disclose what we find, and leave enough breadcrumbs for defenders to patch the holes if they choose. If PICARD is a flashlight into forgotten corners, then running it responsibly means logging the cracks we illuminate, resisting the urge to turn every gap into personal leverage, and being ready to shut it down when the experiment tips from curiosity to exploitation. So if you’re reading this, tread ethically in these explorations.

Give PICARD a try and explore the cracks in your own environments and share what you find, ethically.