Voboda

Tough Puzzles at the Community Privacy Residency

Tue, 13 Oct 2026 16:06:00 GMT

"As soon as you're caught in the room, cryptography won't help you."

Most cryptographers are trained on that separation of concerns. If you're locked in a room, someone can coerce you into handing over your password and cryptographic keys, so that part is "out of scope".

During three weeks at the Community Privacy Residency, I met a journalist from an occupied territory, and his reality threw the whole distinction out.

There were daily roadblocks, with military police doing phone inspections. If you didn't unlock your phone, you were detained and your phone confiscated. If there was an encrypted chat app on your phone, you were detained and investigated. If there was a number from the wrong area code in your call log, you could be arrested on terrorism charges. If you were a regular suspect or a journalist, they had no problem leaning on your family with threats of detention. Detention without charge, potentially for years.

So if you need to go to the shop, you can't go with Signal on your phone. Not if you want to make it back home.

It's based on perception, not reality. WhatsApp is end-to-end encrypted, and nobody looks twice. Telegram isn't (by default), and it's treated as a cause for suspicion.

Anything that looks like encryption - an app with "secure" in the name, a blob of encoded text in a message, is like "waving a flag and saying, come take me."

Plausible deniability, one of cryptography's favourite answers to coercion, made it worse. A soldier at a roadblock who knows hidden profiles might exist on a phone can never know they've seen all of them. That obliges them to keep turning up the pressure. And the more uncomfortable part that took a while to say out loud: think about what this does to someone being interrogated or tortured.

That was one puzzle. There were plenty more.

The short train

Before we arrived, everyone was pinging each other on Signal, working out who could ride together from Berlin to the house in Brandenburg. That's how I met the journalist, on the train platform, and it was an embarrassing start. I’d found a free bench at the far end of the platform, but didn't realise it was a short train. After an hour of waiting, we only saw the train as it pulled out, and we had three hours until the next one.

The village called our old farmhouse "the bunker" because after WWII its facade was redone in typical socialist concrete. About fifteen years before we arrived, a couple bought it, took the concrete off, and started restoring it. They had an ethos, and saw themselves as restoring an environment that had been designed to be adaptive and let people thrive.

High ceilings, big windows and creaky wooden floors. Downstairs, the huge kitchen opened into an even bigger common room, with a modular table long enough for thirty people. Couches ran along the walls. Thirteen bedrooms across two floors. A few tents in the big garden outside, surrounded by farms. The closest shop was in a town eight kilometres away.

We were about thirty people once you counted the mentors and guests staying overnight, and the organisers were putting final touches on the first puzzle: who slept where. A list of special requests, matched against the rooms of an old house.

Then we went round the table and introduced ourselves. I'd seen last year's projects, so I knew the people would be smart. I didn't expect to feel this out of my league. A Brazilian resident protecting activists and journalists who report on cartels. A digital rights lawyer from India, working on internet shutdowns and gender-based violence. New York protest organisers. Prisoners' rights researchers. Legal counsel for massive human rights orgs. A security director for a journalism protection association. A mathematician researching an emerging category in post-quantum cryptography. And someone who popped in a few times to help make lunch, modest but happy to talk shop, turned out to be the Mr. Wolf of TEE architecture.

A world-class cryptographer sat next to someone on the front lines of a freedom movement, and you could feel it both ways: everyone was accomplished, and everyone was a little intimidated. The game was "draw your life in 2 minutes" which was loads of fun, and let us glimpses of what really made us who we are beyond our credentials. But we still introduced ourselves through the institutions we'd passed through, the names that carry clout.

Picking your teachers

On the day people settled on projects, I was tired and behind, and needed more time to read all the poster sessions taped up around the main room.

I'd brought a question with me: which problems really matter now, out in the world? And we'd spent a few days naming real problems from real communities, circulating them, and leaving them for other people to pick up. The idea was to team up around real needs rather than our pet projects. The project I applied with was a way to deliver apps without depending on centralised app stores. In one group session I asked, "Has anyone heard about the F-Droid problem with Google's developer ID policy?" Most of the room put their hands up, but it didn't get anyone excited.

The guy doing operational security for researchers in South America was standing on his own, and I went over, thinking I'd love to learn from him. Like at university: pick the teacher, not the subject. I could just work on whatever he picked. But he was still undecided. Right beside was an abandoned poster: help journalists working in occupations with phone and device inspection/confiscation. If a journalist teamed up on this, would he be interested? I knew one from the train ride. I walked over and asked. He was in too. So it started with the three of us.

There was also a question on the wall I hadn't noticed.

How do you get better forms of identity in chat apps, to keep out imposters?

I wrote a note back, half-joking:

ZK. Who are you?

That note kicked off a collab: a chat app she later named Little Homes. What if the answer wasn't better identity, in the cryptographically verifiable sense, but accepting we can't rely on it, and working from there? Ink & Switch had built something like this, Backchannel: no global key directory. Two people swap a short one-time code, their devices derive a shared key, and that key is the relationship. No global key, no global identifier. I'd been toying with the idea for Infinite Build, where I wanted everybody to have full agency over their group learning experiences. She was circling the same questions for direct action groups.

We kept meeting each other like quarks all over the house. Conversations in stairwells, over the kitchen sink, people exploring the grounds. I met a friend of a resident in the garden when she arrived. She introduced herself as being short but not too short to need children's shoes. Her friend introduced her as working for the UN. I kidded her about how all our modern organisations are built the same way, with the same hierarchies, then fail under the same pressures, in the same directions. And somehow we're surprised every time. She said, "we're going to be friends." We got on to talking about our parents who were displaced by political shifts, and what that means to our identities and responsibilities.

At the end of the week, we had an event in Berlin at the Casino for Social Medicine. It was packed, with people standing outside on the street looking in. From the shows-of-hands in different presentations, I picked up maybe a quarter of the room were cryptographers or deep in opsec. A huge number had made sure there was no online record of the events they go to. One of us started their presentation with a question, "If I say The Hegemonic Internet, do you know what I mean?" and the place erupted in snaps and laughter.

The barn studio

Back at the farmhouse, some people could put on headphones and work right through the noise of the main room, with the kitchen next door. Some of us needed quiet. So the hosts let us use a studio above the barn.

That's where we worked out Little Homes, on a whiteboard. Arisu, Karoi, Satoshi and Taka stood in for Alice and Bob, and every step had the cryptographic protocol, the UI and the social graph drawn side by side, to keep them congruent. We broke direct action groups down into roles: leadership, staff, super volunteers, and the general community. The horde!

My collaborator advises direct action groups, and she could tell the security needs they have from the ones they feel. They worry about infiltrators, and about adding the wrong person to a group or posting in the wrong place. Hegsething themselves. Their more immediate risks are around operational security, data hanging around on insecure devices and that type of thing, but that's not something they tend to see until it's too late. Also chat group membership itself is becoming legal exposure: being in a group where others planned something is used in court to argue you were part of it. We wanted to address all of this.

For high-risk scenarios, we designed NFC check-ins as a countermeasure to group members being captured, coerced or losing their phones: check in with another member regularly, or you get kicked from the group and the phone auto-deletes message history.

Then started with the question she'd written on the wall. Identity and impersonation. Almost every chat app gives you one username and one public key that follows you everywhere. Say you've joined your local Alcoholics Anonymous group on Signal. Then you meet someone in a professional context and join their group too. Now they can see you're in AA. On Signal, seeing common groups is a feature. For these groups, it's doxxing. And the central user list gives rise to accidentally adding the wrong person, not to mention a place for people to create look-alike accounts.

So in Little Homes, if you and I are both in rooms A and B, we hold different keys for each other in each. Nothing in room B tells me you're the person I know from room A. No common username, IDs or keys at the protocol level. Only you can disclose this. This means every pair of people in a room needs to introduce themselves with a specific name and a unique signing key for that group.

It doesn't scale, but it doesn't have to: the groups we were designing for maxed out at twenty or thirty people.

Under this system, some things broke right away, like @mentions. The name I use for you, a petname, is mine alone, and can be meaningless (or revealing) to others in the room. What if an @mention was stripped out and turned into a private notification for that message? But then nobody else knows who the message was for, so it's really more like a DM nudge for a public message. And also, one typo can leak your name for someone.

Backchannel syncs through Automerge, a CRDT that keeps its full history forever. That's the right thing for messages and the wrong thing for room keys that are meant to be rotated and destroyed. A rotated key stored there would never really be gone. So room keys live outside it, on the device, where deleting them actually deletes them.

I brought in a problem I keep seeing in online communities. Every online group has an admin who holds the control. But in real communities, the people actually leading often aren't the admins or the staff. They get frustrated and leave, and the admins go looking for new moderators. It turns out this happens a lot in larger US direct action groups too.

So in Little Homes, rooms have no admins. A room's policy is fixed when it's created. To change it, you fork: you start a new room with the new policy, and members of the old room prove their way in. In the app interface, that can still feel like changing the room's settings and pressing Save.

As we worked through each step, my collaborator and I sometimes pulled in different directions. She wanted to protect anonymity across groups more than I did, because accidental doxxing is how these groups get hurt. This design was already way safer for them and I didn't want to lose users to annoying security steps. My proposal: when joining a room, just announce the name you'd like to go by. If you'd rather stay anonymous, you can, and tell your name only to specific people. She wanted anonymity by default, with no announcing. But then every time a room split off, you'd have to swap names with each member again...

Whenever we got to an issue like this, we'd stop and ask what assumptions we weren't putting on the whiteboard. Sometimes we couldn't name the use case that called for a specific privacy property, it was more an instinct. Then a scenario would pop up later. There! That's why! It went both ways. We trusted each other's intuition and gave the other room to explore. We kept those options open.

She explored an "are you this person?" protocol. Say I'm in a new room and think I recognise you. Can I ask, "Are you Arisu?" The catch: just asking tells a possible stranger there might be an Arisu around, which is a doxxing problem. So we dropped it, but it got us somewhere I didn't expect. Members of a new room already had private one-to-one channels from the old room, so they could use those to share the new room's keys, without swapping codes from scratch. And each person joining could choose whether to introduce themselves, and to whom. Nothing was announced by default.

Couch City

Riley, one of the organisers, grabbed a bunch of us and cut out half of the big table. What was left of it became a coworking table, where people worked with headphones on. We filled the other half of the room with unused couches, carrying them from the barn across the garden. Someone called it Couch City and the name stuck.

Couch City did a lot. Small teams worked there, and you could overhear and jump in. People were more willing to host a workshop, because the couches made it feel easy-going and less official. Around eleven every night there was an NYT crossword ritual on the projector, everyone shouting answers while one person typed madly. It's insane to watch someone finish the NYT crossword in a couple of minutes.

After dinner, people drifted out to the patio. More than once I passed conversations about old jams: you like that too? Then the stories went deeper. Our parents: the Nigerians would imitate theirs, full accents and body language, and argue with each other in character. The Indians would talk about theirs, and about dealing with their approval. All the coming-out experiences too. Poetry readings. Poetry divinings. A chess board appeared with a label you could flip: black turn / white turn. I'd catch up on games when I walked by, and played a few turns. There was always something to connect on.

Early in week two, we had our first big meeting since forming teams. Laptops open, people half-listening to each other's updates. I felt it was a bit corporate but didn't know how to say that nicely. Our UN friend was sat on a couch in the corner. She was asked if she'd like to share an update alongside our projects. Instead she said, "Thanks for offering me this space. I'm going to use it to share how I'm feeling." Looking around the table, she said, "Disconnected." Everyone in the room had been talking about their anti-colonial work, and she invited us to reflect on whether a boardroom table and status updates were the format we really wanted. It was a question for all of us, about habits we'd carried in from our academic and corporate lives. She knew the irony, and deals with it all the time: her own organisation still calls its work "missions".

Our journalism team had grown to six or seven of us, and I was struggling to organise and facilitate. A UX designer offered to run Cade Diehm's Anxiety Mapping workshop for us one evening: we individually brainstormed every troubling scenario we could think of. One stage of Anxiety Mapping combined our separate scenarios into one, literally using dice rolls:

You've been arrested at a roadblock, with sensitive evidence on your phone, during an internet shutdown. Also there's a flood.

Oh come on, does this really happen? And the journalist said, actually, yeah it did. And later he pushed back even more:

"[Security experts] are always thinking about the threat modeling top-down, like the state does. You're not looking at the human being who's actually fighting something."

My first thought was: that's a great line for the presentation. Then it hit me: I'd come to the residency partly to learn threat modeling from professionals, and here was the person I wanted to do it for, commenting on ten years of threat modeling done for him. But I've seen what good stuff comes out of just trying to see through the eyes of the individual people you're trying to help. It struck me that I might have something to offer here.

From there we split off, each of us researching one of the areas he'd identified.

The same designer helped with Little Homes. (She was everywhere - helping almost all the teams!) She sat with us for an hour, then the next day, in about twenty minutes, she speedran ten or fifteen flows. She'd taken our group relationship map, which was never meant for the interface, and told us that was the right mental model, but too complex for a small phone screen. So we jammed on it. What about skewing it into a grid-like space? Swipe sideways between separate social groups, scroll down to the rooms connected within one.

The harder part was telling rooms apart. We'd been debating whether rooms should have petnames too, a name each member sets, or one shared name to anchor some common purpose, like regular chat apps. We never settled it. But when we got to the descriptor text on each room's card, what distinguished a room was its size, the members you know, and most of all the policy for getting in: people in this room are admitted by being in rooms D, F or J, or by invitation from these specific people. The rule for who gets in, written in social terms, turned out to be more meaningful and orienting than a name alone.

The house

Mentors and guests kept arriving. On Fridays, the organisers ran a happy hour at the house, and people they'd invited arrived from Berlin in waves by train.

Some of the visitors were last year's residents. They did a lot of weaving between us, and took care of people's human needs: inviting us to open up to each other, or to look after ourselves when we were pushing too hard.

The house had never hosted a group this big, for this long. It had one fridge, and one standard oven.

From the start, someone found masking tape lying around and labelled every kitchen cupboard, so nobody had to open each one to find a pan. Within hours, other labels appeared: "frozen assets" (on the freezer), "skeletons" (on the closet), "killer robots". Nobody could ever find the recycling box, until it got a huge label: "the future hope of humanity".

Groceries could only be delivered twice a week and overflowed the fridge and cupboards, onto windowsills. One of us had set up a shelf for special-diet food, but if one or two people didn't read the label, food ended up anywhere anyway. Not everyone signed up to the cleaning/cooking rota, which strained the people who did, so someone moved it off a spreadsheet and onto a whiteboard in the kitchen, to help make it easy. But people got confused. The cooking schedule lived in two places, and one day one of our best cooks turned up to find it had changed. Each fix was partial, and the people who broke something weren't doing it on purpose. Different ideas of what's normal, how things should work, what's intuitive, colliding constantly.

The house owners wanted to design an environment where people do good work. We were all designers of digital spaces that other people live in. And here we were tripping over each other on a cleaning rota. It felt a bit like a reality TV show.

One resident had a line for it: solidarity works until someone has to do the dishes. But someone was always in the kitchen, cleaning, loading or unloading the dishwasher, whether asked or not. In the first week, he and a few others took on an evening cleaning shift that wasn't even on the rota.

I took the first cooking shift, the stress test, and when not all the ingredients arrived, an Italian mentor helped me improvise a pasta Parmigiana on barbeques on the patio. I’ve run residencies like this before, and I couldn’t switch that part of my brain off. I kept pitching in, and some people started assuming I was one of the organisers when I wasn’t.

By the second week, some strain was showing. One evening, around the big patio table, the organisers offered an open space for feedback. We'd arrived with different expectations, some of us for the projects and some for the people. Some were juggling day jobs. Everyone spoke with understanding and gratitude, but some of the notes were sharp: hire a facilitator, hire ops people.

Mine was about the fridge. I'd been looking at the house as a system, and it seemed to me a lot of seemingly unrelated problems traced back to that one fridge. Only two deliveries a week meant the fridge was in constant 3D Tetris. Ingredients were always lost, making it hard to cook big lunches. Then we needed cooking schedules, and that took people away from other things... Really the venue should have provided this, knowing how many people they were hosting. Buying a big fridge for someone else's house seems crazy, but 500 euros would have easily saved a hundred hours across the 20 residents.

Tbh I thought a lot of the feedback was a bit unfair but the organisers just listened. They didn't defend themselves, not once, even for things that weren't on them. When we asked about budget, it came out that they had hired help, on a tight budget, and had been paying for a lot of things out of their own pockets.

It was their second residency. I'd asked Riley how they chose the residents, because twenty people who'd never met clicked within days. That's really hard to do so well. They told me they spent weeks imagining different combinations of us together in a house. What would we talk about? They know it's about people, not rubrics. And they just put in the time to get that right.

To me, the thing about residencies is that if you get the people mix right, they don't need much structure. Everyone finds who they need and makes use of the proximity and time together.

In the kitchen one day, I asked Janabel, a mathematician and one of the organisers, if she could express her goals for the residency in terms of group theory: what's the transformation you want here? She thought about it and said, "Our relationship graph goes to diameter 1." Everyone in direct relationship with everyone else.

They'd done this all without a big funder, because they wanted something like this to exist in the world: a place for journalists' needs to be met, for protesters to find protection, and for fabulous queer technologies to find their roots.

The cucumbers

In the evenings people went for walks. The work came along on the walks too, but more in the way you could ask about the person behind a project. One path out of the village led to an industrial cucumber farm, fifty acres under the windmills. Most of the cucumbers had overgrown to three or four kilos.

There was a whole thing between the people from agricultural places and the people from supermarket places. A lot of us, me included, were nerds about agriculture without having lived it. So there were debates. I thought, those have to be zucchinis. Others said cucumbers, just not edible now. It became a game for me. I’d steer people with opposite takes toward each other and let them argue it out. It was nice to see such smart people let themselves be caught out on something trivial.

By the end, newcomers were walking out to see the giant cucumbers they'd heard about, and bringing them back for a big salad for everyone.

What people carried

We were all drawn into these causes for different reasons. Look back at that round of introductions: cartels, internet shutdowns, gender-based violence, prisoners, protests. If you work on the front lines of something like that, you've been around trauma. You shoulder the pain of real people you've watched suffer, and have probably been through some shit yourself.

A trans resident talked about driver's licences being revoked, and valid documents with an X gender marker suddenly not being accepted. And about cities and towns where the likelihood of hate crime was enough to plan your day around.

One morning over breakfast, I realised the person I was talking with had been an international athlete, and mentioned that someone else in the house was too. He explained: if you look like me, you have to be the best before anyone will treat you with respect.

There was another resident I'd been looking forward to meeting, and I didn't meet her until three or four days in. She told me about a health project she did in The Gambia, where the local team asked her to get off a bus to make room for the white people, assuming they were the only donors and the doctors. She cried while she told it, the emotion still so present.

A lot of people talked about systemic privilege but her story made it hit home. She gets recruited by companies most people would work years just to interview with, and has turned them down because the reception desk, seeing her skin colour, assumed she was there to deliver something. Taken for a gig worker once, it's a story. When it happens everywhere you go, it's a drag you carry. When it happens in the lobby of a company that wants to hire you, it's a tell about what working there would be like. And there aren't many companies at that level to choose from, so standing your ground costs you. I've read Biko, I've watched Atlanta, and I still have no idea.

She always found the good and made a point of sharing it. When her flight was cancelled, a customer service agent got her onto another one, and she told the whole residency Signal group about it, by name. Thirty of us spent the evening cheering on Julie, in a call center somewhere, who will never know any of us were beaming our appreciation to her.

The protest organisers live with police violence as part of the work. You're trained to avoid a knee on your neck when you get arrested, but you also pick a great outfit for your arrest photo.

Everyone here was carrying pain, but still bringing light.

The greenhouse

By the end of week two, a few of us took a conversation outside, to a table by the greenhouse. The others shared their stories first, and then I shared mine. It was the only time I did.

If I dress a certain way, I look white. If I dress according to my ancestry, I don’t. For that trip I’d only packed t-shirts and a baseball hat, so the first way was the only way people there saw me. Someone at the residency named it for me: white-passing.

My passport doesn’t pass. I know how border cops look at it, pointing at something they purposefully mispronounce. I’ve been down those hallways, to the small rooms with bad ventilation. People sat on rows of metal chairs facing a wall painted with a comically oversized government logo. Stone-faced mothers with toddlers playing on the floor.

On the street, I’ve been attacked by skinheads and had to fight for my life.

The mixed-race people in the house had a conversation of their own, about fractured roots: looking for your heritage and never finding it in one place. Our friend from the UN, whose parents had been displaced like mine, knew what was doing it. Whiteness.

She didn’t mean skin colour. She meant whiteness as erasure: corporate norms and consumerist culture spreading around the world and washing out what’s specific about anywhere, and anyone.

The search for roots is universal. I finally realised why my white friends do DNA tests and proudly tell me they’re 2.8% Irish or 1.9% Nordic. They’re feeling something that was washed out too.

This erasure is a Stephen King plot: something spreading through a town, cutting everyone off from each other and where they come from.

Stephen King's been writing about colonialism this whole time.

Not everything

In week three, the journalist and I settled into a loop. I'd wake up with an idea, spend the morning researching and expanding it, then find him at some point during the day and see if it held water. Phone profiles died first: work profiles get checked, they're easy to spot, and they cause suspicion. What about a real sneakernet? A slow internet of USB drives moving around the region by car, with slow routing like Fidonet? It had been tried, and now police look for USB keys specifically at the checkpoints they use to control movement. They plug them in and if there's anything encrypted, the bus leaves without you. What about encrypted blobs, something PGP-like but not over email? Forget it. Something like that gets terrorism charges thrown at you. Most ideas ended there: been-there-done-that, or not worth it. But some of our ideas had a shred of something useful, and those became approaches worth a try, strategies that survive all the constraints at once, from network analysis to being detained and coerced into unlocking your phone. Even floods.

This whole time, a lawyer in the group had been deep in research. With us, they'd do that lawyer thing where they try to keep you out of trouble. The best defense is not to end up in court. That kinda thing. For fun, I kept bringing up Hunter S. Thompson's activist lawyer, someone who gets into trouble with you so they can get you out. But they were right. When the research was done, the lay of the land was clear. There are things governments and police do that wouldn’t stand up in court, but they know that doesn’t matter until your court date comes. Meanwhile, there are entire categories of ways to help journalists that steer far away from the state's ability to harass or coerce.

I couldn't stop thinking about another resident's project too. He'd applied with it but hadn't put it into the team formation exercise.

The morning after our group introductions, he'd started a conversation with me about where we were from, and put me onto Langston Hughes' "Who's Passing For Who?"

So it was kinda fun that his pet project was helping workers form unions without disclosing to anyone, including each other, that they were doing it. He'd asked a few people, and they'd said the general version of the problem is considered impossible: the employer controls all the communication systems and all the records.

He wasn't a cryptographer but had come up with one of my favourite parts early on: make it a petition, not a vote. In a vote, an employer faking submissions fakes opposition and wins. In a petition, every fake signature works against whoever faked it.

If you know me, you won't be surprised to learn I thought ZK would solve it. Public and private inputs, a prover, a verifier. A Semaphore Merkle-tree could handle membership proofs. What I hadn't spotted: Semaphore gives you anonymity within a group, but the employer holds all of the employee's information, so it can act as any employee.

I kept thinking, there must be something that made this case different from the general one, one little hook that made this not impossible in this specific case. The employer controls the mail servers, the directory, the devices. Not everything though: not personal phones, not the organisers' own Signal groups, not two people meeting in person.

That was enough to build on. The petition needs every employee to have one stable identifier, so nobody can sign twice. Normally you could hash something unique like an email address. But the employer just hashes the whole staff list, runs each one on the petition system, and knows who signed (and therefore who to fire). When this came up, we paraded over to Ying Tong, one of the organisers. She was in the kitchen, in the middle of cooking us all lunch. "We have this problem. Can I get you for five minutes?" She came over, sat down, drew us a little diagram, and explained VOPRFs. A VOPRF folds in a secret the employer doesn't have, and the server holding that secret never sees the email. I thought the name was hilarious, and that the idea deserved a pronounceable acronym, so I called them "VORPs". She kept correcting me so kindly and patiently it melted my heart a little each time. So I kept calling them VORPs.

Our first version was the standard pattern: publish the list of anonymised identifiers, so anyone can verify the count. Then a cryptographer pointed at the public list. The employer controls every mailbox, so it can submit as any employee and watch the list or the response. If it grows, that person hadn't signed. If it doesn't, they had. So an employer, with an idea of who signed, could verify their suspicion and deanonymise people.

Another problem was proving the results were valid, to third parties like courts. Someone suggested a blockchain, for immutability and proof, recording encrypted records as they were added, then revealing them all at the end. I suggested a massive zero-knowledge proof instead, over the tally itself: every signature valid, nobody counted twice, the total is N. And the list never leaves our hands.

For unionising, the NFC check-in from Little Homes turned out useful: a way for organisers to attest, in person, that someone was a real colleague, folded privately into their signature. It gave us another cryptographically provable path that the employer couldn't see or control.

Encryption considered harmful

The last few days, we were all stressing about our presentations for Demo Day.

Then we got to Offline Place in Berlin, and Ying Tong and crew had made a huge effort to cook home-made food for everyone. The crowd that joined us were people from the Friday happy hours and the Casino, but now familiar faces instead of strangers. It was packed again, the front rows were people sat on the floor.

The journalist team presented "Encryption considered harmful". The main thread was simple. When you design cryptographic systems for these cases, the person in the room is exactly who you design for, which means key compromise, device compromise, network observation and metadata all matter. The person caught "in the room" isn't out of scope, they're in the crosshairs. As far as an interrogator is concerned, the more plausible your deniability, the more plausible your guilt.

Another team, Garfield-Naruto, had come at it from the opposite direction. They hide messages in LLM slop: text that looks like nothing, instead of an encrypted blob that looks like something. They're candid that the prototype isn't ready for the most security-critical uses yet. I loved watching how much fun that team had the whole time, and this was the first time I saw a working demo.

I could finally see the other projects I hadn't had time to catch up on. A friend had come in with a great idea: a Gini Index but for privacy access. I wanted to be part of it, and tried to nudge it along but never managed more than cheering it on. By the end I could see how much had developed in his conversations with everyone. He explained how people on low incomes in some countries can only afford old Androids that won't get security updates. He talked about the cost of privacy beyond money, like time required and language barriers. It had really galvanised.

Another project was policy work on age verification, and how easily kids get around it. Seeing it presented in research photos and findings after all our little breakfast conversations, it was suddenly tangible. And a security project for national trains: "You were really working on this the whole time?" I asked her. "Yeah, that's why you didn't see me in the mornings. I was working in my room."

I was so tired, and still, I wanted to take this all in. Everything we'd done in this short time.

Trading notes

My favourite moments were one-on-one conversations in some quiet corner of the house or the garden, lasting hours. Life, why we do what we do, the big problems. There's a melancholy in these friendships. What brought us together was our battles, and apart from those in the same cities or conference circles, we won't see each other again without real effort.

That closeness is what drove us to trade notes as travellers do: what's good, what's bad, what to avoid, what signposts to look out for.

When I got back home, that first show of hands stayed with me. About F-Droid. I'd arrived with a very technical, philosophical, and anti-Google view of my project. The open letters on this make the case top-down, in the abstract. So I started asking about the humanitarian impact of Google's developer verification by looking for real people with real stories. That pointed me to evidence about bigger numbers. Hundreds of thousands of people. Then millions. Then billions. I spent weeks on it, constantly pulled deeper as new questions opened up. And wrote it up here: Google is taking what keeps them alive.

Engineering problems are objective: physics and math. That's what I'm used to. Most people I met at the residency are working against adversaries. Against other people. That's messier, and it brings an angry energy. Anger's useful though: with a constructive environment to direct it, it clears a path towards something better.

I'd never thought of myself as a policy person, but some residents encouraged me to dip into that world. I'm surprised how rare it is for the people designing policy to go and find the specific cases of who's affected. I applied for a few research grants, long shots for me, but one was accepted because of that approach.

I came looking for a way back to real people and real problems. I got here thanks to a house full of wonderful strangers, and the three organisers who bet their own time and money on us.

Google is taking what keeps them alive

Tue, 08 Sep 2026 17:32:00 GMT

Millions of people living under authoritarian governments, military occupation and drug cartels depend on apps built by people who can't send Google a passport. This month Google starts blocking them.

Google's new "developer verification": all Android developers, not just Play Store listings, have to send it a legal name, a home address, a government ID and proof they hold their app's signing key, plus twenty-five dollars for an account that allows normal installation. It starts in Brazil, Indonesia, Singapore and Thailand in a few weeks, and the rest of the world follows in 2027.

Here is one app that has to comply.

Azmeh is a checkpoint map for the West Bank. It was written in 2015 by Basel Sader, twenty, a law student at the Hebrew University who had been crossing those checkpoints since childhood, almost daily. His cousins were in Ramallah, his aunt and uncle in Bethlehem, and he played in the Palestinian basketball league, so the games were always in Ramallah or Bethlehem. And the kid learned to code at summer camp.

"I'm only a law student. I saw this particular problem though."

He said the app couldn't give anyone freedom of movement, but it could make things easier. It launched with two checkpoints on it. By February 2016 it had forty-seven checkpoints, an English version, a colour scale instead of open-or-closed, and eleven thousand downloads.

Then Israeli military personnel treated mapping checkpoints as a security matter. Sader was harassed and threatened with lawsuits until he shut the app down himself, and it stayed dark for seven years. A new version came online in March 2023 under a Palestinian organisation in Jerusalem. Rest of World reported in 2025 that it tracked more than eight hundred checkpoints for about seventy thousand people. Its developers would not give their names, for fear of what Israel would do if it worked out who they were. They said they were there because they had to be, not because they wanted to be.

One review explains it:

"I used to always get extremely frustrated when I reach the checkpoint and I find heavy traffic, some clashes, or worst of all, the checkpiint is closed. "

Rakan Said has driven a minibus for twenty years. He told Rest of World:

"We are stranded for hours, sometimes from sunrise to sunset. Passengers can't reach jobs, and drivers lose their entire day's wages waiting at checkpoints."

This isn't Waze telling you there's traffic on the 101. The stretch of Route 60 that connects Ramallah and Nablus in the West Bank is fifty kilometres, and part of daily commutes. Since Azmeh went offline, this road has seen countless encounters with violence. Between six and nine the army closes gates so settlers can do the school run. So Palestinian traffic tends to move in waves. Another driver, twenty-seven years on that road, told France 24:

"It's forbidden to stop at gas stations. If you stop, they can shoot at you, and if you get a flat tyre, you have to keep driving until you get to a Palestinian village. If you stop for just five minutes you'll see the settlers coming."

So Palestinians needing Route 60 have to leave at half past five to be there by half past eight.

Fifteen kilometres out of Ramallah that road passes Sinjil, where a woman died of cardiac arrest after being delayed at a closed military gate. The same report describes fifty delays to medical care, including an infant who died at Deir 'Ammar. The ambulance was allowed to pass without its passengers, and waiting on the other side of the gate the whole time. They carried the four-month-old to it on foot. The UN counted almost a thousand checkpoints, roadblocks and other military-installed blocks across the West Bank at the start of the year. Knowing which gate is open makes the difference between getting to work at all, or getting to the hospital on time. Or not.

Google's policy isn't aimed at Azmeh specifically. The same rule catches AmSprung, an app that tells you when the next tram leaves in Vienna, named after a Viennese phrase for being about to leave. It's made by someone who goes by uniqx. It has never been in the Play Store, but Google is still demanding the developer's name, ID, and money.

Let's not even ask why that's theirs to ask for. It's not the big problem.

Entire populations have no government willing to give them ID. Billions have no payment method Google will accept. Plenty have both and still won't connect their identity to their app, because they know what their government will do to them.

Verification is not about being listed in the Play Store. It is the condition for an app installing on a phone at all, and that affects places like this, that rely heavily on mirrors and sharing apps from person to person.

Google says they're doing this to stop fraud. I will show you that it doesn't, and that they know it. I'll even show you they have better alternatives they're not using.

Google makes its decisions with data, and nearly all the data it holds about apps comes from its own store. That's part of the problem. The store is the map Google works from, but it's far from a complete picture of the world of Android apps.

This policy will break things that aren't on this map, so let's look at more of those places.

Health apps

AndroidAPS is an open-source artificial pancreas: it reads a continuous glucose monitor, drives an insulin pump, and lets type 1 diabetics sleep through the night. It has never been on Google Play and never can be, for legal reasons its own documentation spells out. It exists because in 2013 John Costik, a software engineer at a supermarket company in upstate New York, worked out how to read the glucose monitor attached to his four-year-old son Evan, so he could watch the numbers from home while Evan was at daycare, and then posted the code publicly. A woman called Dana Lewis saw it. She'd been diagnosed with type 1 diabetes at fourteen and was frightened of going to sleep, because the alarm on her monitor was too quiet to wake her. She and Scott Leibrand built a louder one, then kept going, and ended up with an artificial pancreas. In her words:

Having a computer make adjustments while I sleep is far safer than trying groggily to make decisions in the early hours.

By 2018, more than 700 people were running one. If Google's rule had existed in 2013, Costik would have been limited to his own handful of devices. Registering his passport and paying a fee wouldn't have made sense for something that wasn't a product yet. So he'd have had no reason to publish the code at all, and Dana wouldn't have discovered it.

There are more out there, like OpenSeizureDetector, which was also written by a parent to keep his epileptic child safe through the night. Actually, self-made health apps are now a standard area of study in health care; it's a normal way for companies and universities to understand what's possible and what works.

They all start with a stranger publishing some code, asking nobody's permission, and it reaching somebody who was going to die without it.

Money apps

In Argentina, after years of triple-digit inflation, knowing today's black-market dollar rate is the difference between spending your pesos now or losing value by tomorrow. Nobody big built that. It's a scattering of solo developers: Dólar App Argentina since 2019, by someone who goes by 2nomadev, and Ámbito Dólar, built and still maintained by Ariel Falduto. They just built the thing their people needed. They got on Google Play years ago, when twenty-five dollars and a working card was all you needed. No government ID.

Everyday apps

Not all of it is life and death. whoBIRD listens and tells you which bird is singing, offline, from a little AI model that knows six thousand species. hEARtest turns a phone and a pair of headphones into a hearing test, for people a long way from an audiologist. LavSeeker shows you where the nearest public toilet is. That sounds like a joke until you have Crohn's disease in an unfamiliar city. One person makes all three, and signs the work woheller69.

Boky Fivavahana Anglikana is the complete Anglican prayer book for Madagascar, in Malagasy only, maintained by one person: Tsiory Rajaonirina.

Kiwix puts the whole of Wikipedia on a phone for people where the Internet, or Wikipedia itself, is blocked. It's one enormous file: about sixty gigabytes without pictures, and usually gets shared on SD cards. Play restricts the SD card reading permission so the Google Play version makes people download Wikipedia into dedicated app storage. Since it serves people who can't access Wikipedia, but requires downloading Wikipedia, it kind of defeats the whole point. But that's the best they could do under the Google Play rules. So the people who need offline Wikipedia because they can't download it where they are? They find it, and all of these apps, on the F-Droid Store.

F-Droid holds four thousand apps like the five we've just seen, and it cannot survive under Google's new policy. The ones that are only on F-Droid, and the ones like Kiwix where the F-Droid build is the one that works, are what this policy hurts first.

F-Droid catches fraudulent apps through code reviews, without asking a single developer's ID, because it builds the app itself, and signs the result with its own key. That's a stronger security model than Play's, because everyone sees every line of code rather than the name on some paperwork someone uploaded.

Google's new policy requires whoever holds the signing key to register each app. F-Droid can't force thousands of upstream authors to send documents to Google, and many of its contributors are pseudonymous on principle because being named for the software you write is dangerous where they live.

Their position hasn't changed since long before any of this was contentious: software you can't inspect isn't really yours, it makes you the one being used, not the user. F-Droid built the answer, and it's worked fine for fifteen years.

Internet access from blocked countries

In June 2025, users of a popular app called v2rayNG noticed it had vanished from Google Play.

v2rayNG is a proxy client. It's one of the tools people in Iran, China and Russia use to reach the internet their governments have decided they shouldn't see. Its repository has over sixty thousand stars. It's made by somebody who signs their work 2dust and has never published a legal name.

Asked what had happened, 2dust answered in one sentence:

本应用无法完成认证，被 GooglePlay 下架了。

This app cannot complete the verification, so it was removed from Google Play.

It wasn't a policy violation and it wasn't malware. The developer, writing in Chinese, simply refused to identify themselves to Google.

A user in that same thread asked: when verification comes for direct installs too, what then? 2dust didn't say they would register. Mainland China had never depended on Google Play anyway; they'd see what actually arrived and deal with it then. 总是有办法的. There is always a way.

The way is a much harder way.

v2rayNG users now need three pieces of developer infrastructure. GitHub Releases, where the current build lists twenty-three separate files and the project has to link a document explaining which one you want. GPG, to check the signature and know the file wasn't swapped in transit by a mirror, an ISP or the state doing the censoring. And Obtainium, a third app that watches the release feed. Plenty of professional programmers have never set up GPG. And it's now the only route for a school teacher in Jammu or a cook in Shanghai.

In Turkmenistan, the criminal code allows up to seven years in prison for installing circumvention software on somebody else's device. Seven years. For helping a neighbour talk to their daughter in London.

Meanwhile the state department that runs the blocking quietly sells access back, reportedly at fifty dollars a month for the basic tier or two thousand to remove the filtering entirely. Here, a minimum-wage worker already needs something like a fifth of their income on the official, censored connection.

Turkmenistan isn't alone. Iran, Russia, China, Myanmar, Belarus, Turkey, Pakistan and India all punish circumvention software with prison, one way or another, which is why v2rayNG has cousin apps everywhere.

Organising against state oppression

Way Way Nay lists Myanmar businesses owned by the military so people can avoid buying from them. It passed 100,000 installs within ten days of launching after the coup, and its creator speaks to journalists only on condition of anonymity.

Journalists and their sources

Briar passes messages phone to phone over Bluetooth and wifi when the network has been cut, which is the moment a government most wants you unable to talk. ProofMode, from the Guardian Project, signs a photograph as it's taken so it can later be shown not to have been altered, for the person filming something that will be denied. These are tools used by journalists and their sources. They know they need to publish on Google Play and F-Droid and a plain APK, because they can't depend on any single gatekeeper.

Except Google's verification policy makes it the gatekeeper in all these places.

Half the world is cut out

Google's head office is in Mountain View, California. If you live there, asking for ID and a couple bucks doesn't seem like much.

Nico Mexis is a case in point. He maintains StudiPassau, an app covering a university in Bavaria: what the canteen is serving, which room your seminar is in, the campus news. He's not a student there anymore, but he still keeps it updated. It's on F-Droid, and has been on Google Play since 2019. He had the card, and the passport was in a drawer.

But actually, this policy cuts out half the world from registering their apps, and that means stopping half the world installing the specific community apps they need, on a phone they bought with their hard-earned money.

It's easy to assume the world's poorest people aren't technical enough to be app developers, but that's just not true if you go look. In Mumbai's Dharavi, girls built apps for communal water queues, rubbish collection and women's safety; in Havana, volunteers ran servers and modified software to keep a vast homemade network alive on improvised hardware; and in Nairobi's Mathare, residents who could not afford college learned development and began building websites and teaching coding inside the settlement. These are not exceptional people somehow escaping their surroundings; they are communities using software the same way people everywhere do: people learn to code, and write software to solve their problems.

No bank card

Half the world's adults do not have the payment instrument Google requires.

The twenty-five dollars goes through Google Pay, which only takes bank-linked cards. It even states plainly that prepaid cards are not accepted. The exclusion they don't mention is worse. Across a lot of Africa and Asia, banks are not the standard. These places run on mobile money. The World Bank's 2025 Findex counts about 6 billion adults worldwide, of whom roughly only 3.3 billion own an account-linked debit card. Half.

This isn't about poverty or financial system access. Kenya has one of the highest account-ownership rates in the world, close to nine adults in ten, and mobile money runs nearly all of it. Google knows that: in Kenya it will take a mobile wallet when you're buying an app. They just won't accept it when a developer is paying their registration fee.

So for Kenya and half the world, a developer's software can't be sent or installed normally now. And Androids are the only phones most people there can afford.

No ID

The World Bank counts about 850 million people with no ID any government will recognise, concentrated where a cheap Android phone is the only computer anyone owns. In the United States, a survey found 20 million citizens of voting age can't readily produce any citizenship document.

And documents now get stripped away as a political technique. India's National Register of Citizens excluded 1.9 million people in Assam state alone, with Human Rights Watch documenting that tribunals declared disproportionately more Muslims foreign and struck people off over spelling differences between documents. The Dominican Republic's Constitutional Court retroactively stripped nationality in 2013 from tens of thousands of people, mostly of Haitian descent, who had held Dominican papers their whole lives. At least a dozen more countries have done this recently, and it's becoming more common.

If you make a government ID the condition, you've made every one of those decisions yours too.

The institutional trick

This ID policy on Google Play has created a common workaround. If you can't register as an individual or a company, you find an organisation to do it on your behalf.

Look up Azmeh on Google Play today. The developer isn't Basel Sader and hasn't been for a decade. It's Burj Al-Luqluq, a sports centre for kids in Jerusalem.

It ran football, basketball and taekwondo, kindergartens, summer camps, art rooms and psychosocial support, for around 6,500 people a year. It's a Palestinian community centre in the Bab Hutta quarter of the Old City of Jerusalem, founded in 1991 on land the neighbourhood fought to keep from a planned settlement, and its buildings have faced demolition orders.

So the arrangement that keeps a map of Israeli roadblocks installable on Palestinian phones is that a children's community centre, registered with the municipality of the occupying power, signs for it.

Burj Al-Luqluq has long been a target. In 1989 the land was marked for a settlement, and the families of the Old City set it up as a sports and social club to stop it. In 1998 the first Palestinian Legislative Council met there.

On 12 February 2026 the national security minister signed an order closing the society's sports, educational and social activities, on police claims of funding from organisations linked to terrorism and incitement against the state. Five days later, the day before Ramadan began, police and intelligence agents in civilian clothes walked in, ordered everyone out, and welded the doors and entrance gates shut.

"The order claims the association operates with funding from the Palestinian Authority. This is completely false and has no basis whatsoever."

Montaser Idkedek, the centre's director, to Anadolu

Later he told Jerusalem Story that Jerusalem's institutions were all waiting to see what would be done to them next.

"This closure is the start of something bigger and more significant."

Azmeh's author was threatened into silence once already, in 2015, and the app's way back under Google's policy was an institutional host.

This tells us a lot about Google's policy.

First, that it pushes risk onto others. An organisation running taekwondo for six thousand children is now the name Google holds, the name that answers a subpoena, and the name a state reads when it wants to know who to pressure about a checkpoint map. An app it probably didn't even make.

The second thing it tells us is who can do this at all. You need an institution willing to sign, which means the app has to be big enough or known enough to be worth the risk to them.

The ones that clear that bar are the ones you might have heard of. Fogo Cruzado sends real-time gunfire alerts that reach over 400,000 people across Brazil; it started as a Google Docs spreadsheet kept by a journalist who couldn't find the stray-bullet statistics she needed for a story, and it now has a board and Amnesty behind it. Gershad crowdsources morality police checkpoints in Iran so a woman can walk a different street; the government blocked it within a day of launch, it spread to 100,000 people by sharing the app file anyway, and it has now reclaimed its Play Store listing by a nonprofit outside the country. And we saw Azmeh found a youth centre.

But these are exceptions. East Jerusalem happens to carry an unusually dense layer of foreign-funded civil society, built up over decades precisely because of the political situation there. Myanmar's Sagaing region has nothing like it. Neither do the border cities of northern Mexico, or the neighbourhoods where those Argentine dollar-rate apps get made, or the island of Madagascar, where that Christian prayer book needs it.

The third thing this tells us is that the workaround defeats the stated purpose completely. Verification supposedly exists so that Google knows who built and controls an app, but it accepts an organisation that does neither. Cut off that account and the app finds another host. The problem doesn't get stopped. It gets laundered.

The sorting isn't between honest developers and fraudsters. It's between people who can find a legal name to stand in front of them and people who cannot. For criminals, legal registration of an anonymous Swiss charity is easy, but here where it means something, the institution is a building that somebody else welded shut.

And more to the point, the long tail of useful apps made for small communities won't find one, and until now it didn't have to. People could still install directly or use a niche app store.

When Google Play made a rule about its own shelves, everyone who couldn't live with it used another channel. That was a change to their listing policy.

Now Google is insisting its rules apply everywhere else. It's a change to what you're allowed to do with a phone you own.

What your name costs you

In October last year Google removed an app called Red Dot from the Play Store. Red Dot let people report sightings of US immigration agents in their neighbourhood, anonymously, with reports expiring after five hours. The decision was Google's own, not the government's: it told 404 Media it had not been contacted by the Department of Justice, and that it bans apps with a high risk of abuse and apps sharing the location of a vulnerable group. The vulnerable group they were talking about was ICE agents.

Google decides who is dangerous, too. Waze is Google's traffic app, and it assumes Palestinians are Israelis. The moment they cross back home it starts warning them they are entering a dangerous area, so the drivers use WhatsApp groups instead. In Rakan Said's own neighbourhood, Google calls him a hazard.

Red Dot found a way to stay running. If you go to its website it tells Android users to download the APK and install it themselves, because that's the only channel left. From next year, that channel closes. The party deciding whether Red Dot's developer may register is the same party that already decided the app shouldn't exist. Google.

ICEBlock is the iPhone version of the same idea. Its developer put his own name to his app. He was threatened with federal prosecution, the Attorney General named the app from a podium, and it was gone from Apple's App Store the same week. He is suing.

That's what happens in a country with courts, an appeals process and a still-functioning press.

Elsewhere the sequence is shorter. 3,198 Palestinians are currently held under administrative detention: no charge, no trial, six-month orders renewed indefinitely, on evidence the detainee's own lawyer never sees, and with the renewal often delivered on the day they thought they would be released. The UN report shows how commonly relatives are detained to force a wanted person to come in. In Iran it means the Revolutionary Guard's intelligence organisation, which detains people over social media accounts and threatens relatives inside the country to silence people outside it. In Myanmar, since the cybersecurity law took effect last July, soldiers run street phone checks for VPNs and social apps. In Kashmir, they do that too, and administering a WhatsApp group has been charged under a law carrying seven years.

The sequence from "register" to "target list" is well documented. In December 2016 Iran ordered every Telegram channel administrator with more than 5,000 members to register with the Ministry of Culture. Over 700 complied. Three months later twelve of them were arrested and their channels deleted.

Turkey prosecuted people for terrorism because they had a specific messaging app on their phone: ByLock. After the failed coup in 2016, Turkish intelligence declared all of its users members of a terrorist organisation: the interior ministry charged 95,310 just for installing a chat app. Its own intelligence report, the one the courts used, said a third of them had never sent a single message with it, and 11,480 on the list hadn't even installed ByLock, but had been added by a misreading of the ISP logs that in fact proved they didn't use ByLock. Their read of the ISP logs picked up more than 10 other unrelated apps, like some music apps, dictionaries, a used car listing and a Muslim prayer times app.

Charges against those 11,480 were eventually dropped, but not before they were jailed. Mustafa Yaman spent six months in prison and missed his son's wedding and the birth of his first grandchild. A primary school teacher who would give Middle East Eye only the name Ahmet spent eighty-seven days in one, for a call-to-prayer app he had installed during his military service because his posting was too remote to hear it.

"But I will never forgive the government for what it did to me. I had absolutely nothing to do with FETO and they destroyed my life."

The prosecutions continue today.

Once a list of names attached to an app exists, hostile governments gain access, and being on it becomes all the evidence they need.

And when you live in places where organised crime is effectively the government, the people who can legally require Google to send a developer's name and address are the same people the app was built to keep you away from.

Mexico's Secretary of Public Security, the man who ran the federal police, was convicted in a New York court of taking millions from the Sinaloa cartel. The former president of Honduras was sentenced to forty-five years for protecting cocaine shipments while running the country. He recently got a US presidential pardon and was freed to go home. Nobody has tried the ones who weren't extradited, and they still hold their police commands and their ministries.

Google's list already exists, and you can see what's on it. Open Azmeh's page on Google Play, click through to "App support" and look down to "About the developer", and there is a person's name, an email address and a street address in Jerusalem. Google requires a developer to publish them.

When it's ICE agents, their location is protected because they are a "vulnerable group". When it's an anonymous app developer helping people in a military occupation, then their name and physical address are public information.

Should developers be expected to trust Google?

That was the Play Store. Google says this registry will be private. But private to who? When it comes to working with governments, Google's track record is worrying.

On the day of Russia's parliamentary elections, it removed Alexei Navalny's tactical voting app. It spent two years building Dragonfly, a search engine for China that blacklisted terms about human rights and peaceful protest, and abandoned it only after its own staff revolted.

Mostly, though, according to Google's transparency report, it just answers lawful orders, and it is set up to do that at scale.

The term "lawful" used here is misleading. Being lawful is not the same as being required by law. Administrative detention without charge is lawful in the West Bank. The Ministry of Culture's register was lawful in Iran. Turkey's prosecutions of ByLock users as terrorists went through its courts. Google says so itself: many of the court orders it receives do not require it to act at all, and it weighs each request and decides for itself, lawful or not.

The report sorts the government requests it receives into ten kinds of requester. Police is one. Military is another. So are suppression orders, which Google describes as court orders that "prohibit any discussion of the order", sometimes including the fact that it exists.

Through all this, developers are now being required to trust that Google won't hand over their identity. And we've seen how they decide.

So Google forces a choice. Hand over your name and accept if Google shares it, or let Google choke the app you made that people depend on.

The ones that are already disappearing

We can see the trend.

Way Way Nay has nowhere to go. Its creator talks to journalists only on condition of anonymity, in a country whose military the United States has formally determined committed genocide. Registering means putting a legal name and a home address into a system that answers lawful orders at scale.

Briar and ProofMode publish on Play, on F-Droid and as a plain APK, and they do it deliberately. Tools for journalists get shut off one channel at a time, so the answer is never to depend on only one. Verification puts a single, blockable check on all three.

whoBIRD, LavSeeker, hEARtest and AmSprung never got onto Play at all. Kiwix is broken by Play. Shelter and Island, which box an untrusted app off from the rest of your phone, Google removed outright, and there is a longer list for anyone who goes looking. Google cut off Red Dot in October last year. And v2rayNG came off in June 2025 for who made it: sixty thousand stars, no policy violation, no malware. Just a developer who probably couldn't give their name because of where they lived.

Does it actually help the fraud victim?

The reason Google gives for doing all this is to stop fraud: a grandmother somewhere, talked into installing something that empties her bank account. That happens. And when its with apps, it basically comes down to two ways.

The Dropper

Publish a simple, normal app to the Play Store and leave it there for months. A pink rabbit-themed calculator, a PDF reader. The app works, it gets reviewed, it gets good ratings, thousands of people install it. Then push a clean update that doesn't show up in scans, and later flip a switch on your own server, and the app fetches the code that does the stealing.

The whole scam is based on app store reputation. The store isn't the thing that stops it. The store is the thing that makes it work.

Play has required identity verification since 2023: government ID for an individual, or a D-U-N-S number for an organisation, with the legal name and address printed on the listing.

The Dropper recipe survives all of it intact. One dropper reached the top three of the US Play Store's free tools chart last year, with over 50,000 downloads, before the malicious update arrived six weeks after release. Kaspersky found more of them on Play three months ago.

The Call

The other type of app fraud doesn't depend on app-store reputation.

Here's how it runs in Bangkok. Grandma gets a text message on LINE, then a phone call from somebody claiming to be the police, or the electricity company, or a parcel service.

"There's a problem with your account." "A delivery you didn't order." "A money-laundering case with your name on it."

He is patient, he is helpful, and he stays on the line while he talks her through downloading a file and installing it. Once it's on the phone it asks for the accessibility service, allowing it to see the screen, read the codes and move the money while she's still saying thank you.

A purpose-built malicious app like this would be caught inside an app store with their automated checks. What does the work is a person on the phone, building trust and talking the victim through each step.

We'll call this one The Call, because the software is the smallest part of it.

Singapore's cyber security agency collaborated with Google on this a few years ago. It calls the category malware-enabled scams. The police there count where the money actually moves. In 80 percent of reported scam cases, victims made the transfers themselves. They didn't even need a malicious app. The scammers never took control of the account at all.

Their report explains it like this:

In most of these cases, the scammers didn’t gain direct control of the victims’ accounts, but manipulated victims into performing the monetary transactions by means of deception and social engineering.

Developer identity verification doesn't touch the Call, because the man on the phone directs the victim's own hands. It doesn't stop Droppers either. Google Play tried identity verification on its app store already, and it fails at the type of fraud they say they're stopping. That's the same check Google is now extending to every app on every phone, citing fraud prevention again.

Fake IDs

Let's be honest. Anyone who has ever watched a teenager buy beer at the corner store knows exactly how effective asking for ID is.

But there's a deeper reason collecting ID doesn't work: a register only bites if identity is scarce, and it isn't. The US Department of Justice describes syndicates luring workers to Thailand with offers of well-paid technical work, seizing their identification documents, and trafficking them into scam compounds. Thailand's own Technology Crime Investigation Bureau recorded mule-account arrests rising to more than six thousand last year, and one anti-trafficking group has documented at least 961 cases of Thais taken to Cambodia and made to surrender passport, SIM and a facial scan. The UN's IOM found 300,000 people trafficked into scam compounds in South East Asia. They get the ID documents along with the captured human.

Google says carding every app developer will slow down the criminals. On the other hand, criminal operations that traffic thousands of humans between countries won't have trouble getting as many ID cards as they need.

Google's answers

In April, a developer went to register his app and found that somebody else had already registered it. Google's registry, built to establish who owns an app, had let an impersonator claim his first. He also hit another problem: the right to an app's name goes to whichever existing key holds the most installs. That wasn't him. On F-Droid, that key is F-Droid's. On Play, it's usually Google. This is exactly what F-Droid had warned.

But days later, Google had fixed it. The developer could claim his app and register it.

That's how fast Google moves when it means getting more apps registered.

The EFF warned Google that people building Android apps to report ICE misdeeds shouldn't have to worry that Google will hand their personal information to the Department of Homeland Security. Brave explained that developers of privacy browsers, encrypted messengers, VPNs and tools for journalists in hostile environments would have to upload government ID to a company they have no reason to trust, and that many would simply stop. A coalition of more than seventy organisations put their names to an open letter making the same case.

Google answered them differently. And eventually.

First, for hobbyists and students who can't afford the twenty-five dollars, they created the limited distribution account with no fee and, Google says, no government ID required. What it does require is a Google payments profile holding your legal name and address. And then the app goes on twenty phones. But that's not twenty people who can just grab your app and install it: each one has to authorise your app itself, through what Google calls "a secure handshake process involving QR codes or links," one phone at a time. That is really a testing allowance, not a distribution channel.

AndroidAPS has already written a help page for this, because according to Google, it's actually worse than the 20 users they imply. Each type 1 diabetic running it is the developer of their own build. Each now has to register with Google as a developer themselves, or learn ADB, to keep their insulin pump talking to their glucose monitor. That's how they keep themselves alive through the night.

Second, Google added an "advanced flow" so they could say phone owners may still install software of their choice.

In reality it's a confusing maze, designed as a deterrent. The steps: enable developer mode, which means finding a specific unlabelled option deep in your settings and tapping it seven times. (Noting it also puts your phone in an insecure state.) Confirm that nobody is coaching you. Restart the phone. Wait twenty-four hours. Reauthenticate. Then tap through another warning. Or, you know, just install some Android developer tools, learn them, then keep updating apps over a USB cable like it's 2002.

Google calls this the path for power users. Everybody who installs an app directly now has to take it. That is every v2rayNG user in China, Turkey and Turkmenistan. Everybody in the United States downloading Red Dot's APK from its website, the only channel Google left it. A teacher in Jammu, a cook in Shanghai, and every Anglican in Madagascar who wants a Christian prayer book in their own language. These are not power users. They are not technical. But now, this is what they need to do to install the same app.

And grandma? The scam was always about gaining trust and patiently talking her through steps on a phone. More steps are the only thing that's been added. The man calling her has the time and the motivation. He is probably trapped in a scam compound in Cambodia, in a room with no windows and fluorescent lights. If he can already guide grandma to download an APK, enable unknown sources and install it, he can handle developer mode and a call back tomorrow.

In the end, Grandma is the reason Google gives for all this, and she's the one it doesn't save.

What Google learned from the police

Here's what gets me. Google already knows this. They've already fixed it too. Not in theory. They built the solution and ran it across Singapore, with the same Singapore police, back in 2024.

They looked at it technically: exactly which privileges do scam apps actually need? Reading your texts (READ_SMS, RECEIVE_SMS). Killing your notifications (NOTIFICATION_LISTENER). Taking over your screen (ACCESSIBILITY). So they blocked those four, specifically.

They didn't block all direct installing. Only apps that flicked those four switches.

Once the phones started checking for that combination, 900,000 installs got stopped in six months in Singapore alone.

None of those criminals were asked to please send their ID before committing their crime. It stopped The Call because the man on the phone had nothing to say. There was no button grandma could press for him.

Google rolled it out to India and it showed the same, at thousand times the scale. India logged 2.8 million cyber-fraud complaints last year (reported there as 28.15 lakh), and a standard playbook never sends a malicious app at all.

It's a lot like the Singapore police explained. Scammers posing as Paytm support talk the victim into installing a legitimate remote-support app, like QuickSupport or AnyDesk. They use the access she grants them herself to move the money and read the codes as they arrive.

Take that in. The scammers don't even need their own app.

Every app they use already has verified developers, legal names, registered companies, everything Google is now demanding outside of the app store.

If it doesn't stop them in the app store, it won't stop them outside it.

You can block just the bad apps

The Singapore pilot was a police collaboration. So the direct installs Google saw were the ones turning up in fraud cases. Over 95 percent of the malware abusing those permissions arrived that way, which is a fact about malware. Google read it as a fact about direct installing. When you're counting fraud investigations, everybody is a criminal. So their model of a developer is that they always have something to hide.

What the pilot showed Google was actually something else: that it's those four system privileges that should make an app suspect, not that it was directly installed. Most regular apps, including the life-saving ones, never touch those privilege switches.

Some do: a seizure detector that has to wake a carer, a messenger built for the moment the network goes down. To block the scammers but not the good apps, there's something better to look at: app file history.

Files can have global histories, known to the whole world, using something called an append-only log. It's basically a published list that can only be added to, never quietly edited, with cryptographic cross-checking so anybody can verify nobody has rewritten it. If phones can check a log of how apps were built, they know things like: how long has this exact one been public? How many versions have there been? What permissions did each of them ask for?

Against that, the Call fails. Scam apps are usually built fresh for each victim, so the file is new every time and the lists of known-bad files have never seen it. That is what makes them invisible to a blocklist. It is also what gives them away to an append-only log, because an app built yesterday has no history at all.

Combine that with a block on those four dangerous app permissions. Google can make it so an app with no public track record doesn't get any of them. Period.

There's nothing the scammer can tell grandma to do to get them. But uniqx and Tsiory Rajaonirina both get those capabilities if they need them, because their builds are old, public and unflagged. The moment an app asks for a dangerous permission it never had before, that takes a new release, and the new release is published to the log. After two years, if a PDF reader starts wanting the accessibility service to read your screen, that gets flagged immediately.

So there's a better place to put the friction: the 24-hour delay, the anti-coaching question, those should be used when activating a dangerous capability. Google knew this from the Singapore pilot in 2024.

Instead, it's decided to bolt all of this complication to anyone who doesn't register on Google Pay, instead of just the app permissions that actually get abused.

The hard parts

By now, a technical reader will have some good questions about these logs. How do new versions restart the access timers? What about an app that declares dangerous capabilities from day one, the way droppers already do? What about code injected at runtime, which never touches a build? What gets logged, and how do you stop the log being spammed? Should revocations be public, and if Google can issue them quietly, how is that different from Google deciding what gets blocked today?

These all have good answers, and this isn't the essay for them. They belong to the people who have spent a decade working on exactly this, at a conference run by a company that has already solved the same problem once, for the entire web.

If you can guess which company this is, you owe me 25 bucks.

Who gets to look

Google itself built something called Certificate Transparency, a decade ago, covering every website on the internet.

Certificate Transparency started because one certificate company, registered and well documented as it was, had issued false certificates used to break into Gmail accounts in Iran.

It requires every website certificate to be published to append-only public logs. When your browser visits a new website, it check its certification against the log, so a bad one can't be issued quietly. The logs are cross-checked by different operators so mis-issuance is visible to everyone, and this kind of visibility turned out to be enough: Symantec, then a major issuer of certificates on the internet, was caught issuing them improperly often enough that the browsers stopped trusting it, and it left the business.

Anyone can check the logs, not just Google. Anyone can run a monitor, and the people with the most to lose do. A company watches the logs for certificates issued in its own name and finds out within hours if somebody else has gained access to one. That's the whole design. Certificate Transparency doesn't ask, or need, anyone to see everything. It goes the other way, making it impossible for anyone to do anything invisibly, and then lets the people with the most to lose do the looking.

Apply that to Thailand, one of the four countries where this new ID policy starts. Thai banking fraud runs on impersonation, an app wearing a real bank's name and icon. Under a public log the bank could watch for imitations of its own product: its real package names, signing keys and icon files are all in the log, so an app that has just appeared, looks almost exactly like the real one but has no history behind it -- that's something a script can find.

Google has less reason to chase Thai-language impersonation than the banks themselves, that have to reimburse the victims. The Bank of Thailand and ThaiCERT could watch the whole category, in Thai, in near real time. And that's before the cross-checking that banks, security researchers and NGOs could do across borders to catch international fraud.

It could do what it does with website security certificates, and let everyone look.

And Google made this for itself

Here's the last kicker. Once again, Google already built an append-only log system for Android apps.

In May this year Google shipped binary transparency for Android. Its own production apps, released after 1 May, now get an entry in a public append-only ledger. Google's framing: a signature is a certificate of origin, binary transparency is a certificate of intent. Google's own words on the design:

It's built so that no party, including Google, can change the software authorised for your device without creating a public record.

That is the correct principle, written four months before it shipped the opposite for everybody else.

For its own software: no single party should decide unaccountably what runs on your phone, not even Google.

For everybody else's: Google decides, and the price of admission for any app developer is their passport.

Everyone else doing this

The people building these systems meet at the transparency.dev conference, which Google started and hosted at its London office in 2024.

The same idea is already protecting some of the people this policy endangers, journalists. WEBCAT comes from the Freedom of the Press Foundation, a small nonprofit who make SecureDrop. That's the system the Washington Post, the Guardian and dozens of other newsrooms use to receive documents from anonymous sources (and one I've learned a lot from on my own projects). Those newsrooms trust a handful of people to protect the identity of a source against a state that wants it. WEBCAT extends the principle to web apps: a browser checks that the code it's about to run is the code the developers signed, before running it, and can see the history of the web app. WEBCAT presented at Google's transparency summit last year.

Sigstore, a Google-backed project, is now how npm and PyPI, the two largest public collections of reusable code in the world, let a developer prove a release came from where it claims to.

Sigstore is worth a moment, because it shows the middle ground exists: it ties a signature to an identity, but that identity can be an email address or an account rather than a state document, and that link goes into a public log instead of a private database at Google.

It works, it's proven, and no ID cards are involved.

So why is Google doing this?

Google spent six years rebuilding Chrome's extension platform, and the version that arrived can't do what a content blocker needs. uBlock Origin's forty million users lost the full version in 2024, and Google cited security. Ad blockers cost Google money. Draw your own conclusion.

I'm sure people argued against it inside Google and lost, and I'd bet the same fight for binary transparency over developer ID was fought and lost. Because commercial incentives usually win those fights.

I don't think this is a conspiracy. It's a company behaving the way companies behave. Google runs a store and sells advertising, and the Play Store and the other licensed stores are among its biggest money-makers: Google Services makes almost $350 billion per year. When it has a distribution layer, it consolidates that control in ways that protect its revenue and reduce its legal exposure. Each of those decisions, once made public, comes wrapped in the language of user safety.

App stores are businesses. Governments offer access to their markets.

What's different now is that to squeeze more control out of a platform, Google has to put people's lives at risk. And this time, it can't pretend a government is forcing it.

Google has better options. It has the people who pushed Certificate Transparency into the browser, the people who shipped Binary Transparency for Android in May, and the people who host the conference on this entire class of technologies.

Larry Page and Sergey Brin wrote this in their founding letter:

Google users trust our systems to help them with important decisions: medical, financial and many others. Our search results are the best we know how to produce. They are unbiased and objective... We believe it is important for everyone to have access to the best information and research, not only to the information people pay for you to see.

That describes responsibility.

Billions of people later chose Android, and paid for the hardware themselves, at a price that is months of their income. Note the phrase above: "not only to the information people pay for you to see." Now, by blocking apps they don't control, they are blocking that information.

Google had a human rights program with oversight running up to Alphabet's board, the board the founders still sit on. In 2020 the board wrote civil and human rights explicitly into that committee's charter. In October 2025 it took it out, and told shareholders that leaving it out lets its committees be "nimble and flexible". Though almost a year later, Google's public page still says that Human Rights Program exists.

There is still something left from this in Google's Code Of Conduct, a phrase as a final note: "...don't be evil, and if you see something that you think isn't right – speak up!"

The apps we'll never see

Azmeh's last update went out in July 2025. It was a big update, improving a bunch of screens and adding a much-requested comments feature. Three weeks later the app opened to a blank page. No checkpoints listed. Fourteen months later, it still hasn't been fixed, and they never shared an explanation. They just disappeared. The Play listing still carries a person's name and a street address in Jerusalem.

Every app you read about here was someone writing software for a problem they were standing in themselves. Costik was a supermarket engineer whose son had diabetes. Azmeh's author was a twenty-year-old law student in a city full of checkpoints. Those girls in a Mumbai slum built a system so more people could have water. Most software like this has hundreds, maybe thousands of users, but it's most needed where nobody is counting. Usually, where nobody can count them.

The cost is that half the world loses the ability to make these apps for each other. Not just the ones they've made, the ones they will make. They have no payment method Google will take, or no ID card, or a good reason not to trust Google with it.

They will have no reason to write software, because the only devices everyone in their community owns won't accept what they make.

When their apps go dark, like Azmeh, they won't make the news. If they disappear, nobody will count them, but we can count them now. This cuts off billions of people. That's billions with a B, no matter how you spell googol.

We can't know how many lives will end at closed checkpoint gates, armed raids, cartel firefights, or for that matter, late-night insulin emergencies. But consider this: Azmeh, Doroob (a similar map app), Gershad, Way Way Nay and Fogo Cruzado are all apps people use to make life-and-death decisions. That's five apps, and they've helped close to a million people between them. We can't see all the other ones, but it's reasonable to think they protect many, many millions more.

Rakan Said is still stuck in a line at a gate somewhere in the West Bank, unable to see whether it is open.

But who knows? uniqx might send their passport, change app stores, and the Vienna tram app keeps working.

Then Google can tell themselves everything is fine.

Your browser has fully verified this page, except for the page itself

Sun, 14 Jun 2026 12:49:00 GMT

You come home and the kitchen isn't right.

Cleaner, maybe? Your mug sits exactly where you left it, but the light through the window is off. You stand there holding the cup, turning slowly. Everything is where it should be and yet none of it is yours. You take a sip, trying to figure out what isn't right, and realise you don't know what you're drinking.

It's warm, but it isn't tea.

This is how a domain hijack works. Right door. Identical furniture. But not your place.

On your screen it works a little more quietly. You type your bank's address, or click the bookmark you've used for years. The page loads. The padlock is there. The logo, the layout, the wobble on the login button: all perfect, because they copied all of it. But when you type your password in, you've just given it to a hacker.

For a bank, that kind of breach is bad but survivable; the real ledger is still on their servers, and they can hand your money back. For local-first and p2p apps it's an unrecoverable disaster. The whole point of what a lot of us are building is to push keys and data all the way down to the user, so the company can't betray you. Remove the company that could betray you and you also remove the one that could save you. A hijack here doesn't leak a session. It takes the keys, all the data, and there's no one who can make it right.

There's a technical problem underneath it: you can do every piece of web security correctly (valid certificate, perfect TLS, integrity-checked scripts) and none of it matters, because we don't control the domain registrar. The attacker tricks the registrar, changes the domain name to point to their server, and bypasses all the security.

It's strange. All security checks in your browser but none of them check: is this the right server, or just one that answers to the name?

A domain hijack is just one way in. A compromised build pipeline, a poisoned dependency, a CDN serving something extra, an insider pushing one commit. They all end the same way, with code running in your browser that the developers never wrote. Which is strange, because your browser is perfectly capable of refusing that. Extension code is hash-verified before it runs. So is a mobile app.

But the page sitting right next to the extension, in the same browser, gets no such check?

Suspicious.

The blind spot

The closest thing we have is Subresource Integrity (SRI). The page lists a hash for every script, stylesheet, and image it pulls in; the browser checks each fetch and refuses anything that doesn't match. A compromised CDN delivers tampered JavaScript, the hash fails, the code never runs.

It works. But it verifies every ingredient the page brings in, not the page itself. The kitchen is the root HTML, the document listing all those hashes, and it has no hash check of its own.

Why not? To answer that you have to ask, where would you put a hash of the page?

You can't put the hash in the page itself, because it has to go somewhere the attacker can't change. It can't go in DNS either, as we've just seen. A hijacker who can redirect your domain can just swap your real hash for their fake one.

DNSSEC (the SEC stands for security) is a way to sign DNS records with a cryptographic key, but it has the same problem. Because with DNSSEC the way you check the key is to ask the registrar. Yep, the same registrars that get hijacked. So if the attacker tricks your domain registar, say by claiming the domain name is there's and emailing a picture of a fake ID (yep, that works), then attacker just signs as you.

So we need some way to check that the records themselves really come from the people who own the site, that don't depend on the webserver or the DNS records.

The boring fix

What about this? Do what SRI does, but for the DNSSEC keys that signed the DNS records. Hash them the first time, check against it after. If those keys ever change, someone else is signing. Get out. Don't open any drawers. Don't drink anything.

This is Trust On First Use (TOFU), and it's already used everywhere. SSH, the standard way to log into servers, hands you a host key the first time you connect; after that, a mismatch screams at you. Signal does the same with safety numbers.

The problem is very few sites use DNSSEC because it was kind of a mess when it started. But we can maybe still use the TOFU idea for DNS records themselves?

A browser extension can do this in two layers. Pin the DNS records on first sight, check them on every visit after. And use the same records to carry a content hash for the key pages, so the documents that need security get SRI protection down to their root.

DNS pinning is possible

The hard part is people. DNS records legitimately move all the time: CDNs, CNAME chains, cache TTLs, even DNS resolver disagreement. False positives train people to click through. You see that same old security warning which turned out not to be problem last time, you just click whatever button let's you through next time.

This is starting to get useful because nothing here requires the website operator to do anything. A user can just install this kind of checker, and get protection against their bank or whatever other site from being hacked.

The thing to get right is the pinning policy. Strong enough to work. Lenient enough that it doesn't cry wolf.

So I've started measuring it. Some domains rotate records every minute as a matter of course. Others haven't changed in years. Turns out they cluster by what kind of website they are. Global consumer sites behave one way, banks another, messaging services another, and the static hosts that local-first apps deploy to are the most stable of the lot, almost never changing. Pinning policy can be written per cluster rather than per domain, which is what makes the false-positive rate workable.

You don't flag every change, just the changes that are inconsistent with that type of domain.

Transparency logs

There's still a gap though. Your first visit, when there's no history to compare against yet. That's where a transparency log comes in. A public, append-only record of what a domain should serve, so you know if anything's changed before you go inside.

The pattern already runs under every HTTPS connection you make. Your browser trusts a few hundred Certificate Authorities to vouch that a domain is who it says it is. In 2011 a Dutch one, DigiNotar, was broken into and used to issue a fraudulent certificate, which was then used to expose the Google Mail accounts of hundreds of thousands of people in Iran. One compromised ceritificate issue, out of the hundres anywhere, was enough to impersonate anyone. Certificate Transparency was Google's answer: every certificate a CA issues gets published in an append-only log that anyone can audit, so a forged one can't be issued quietly.

It was a good idea. It went through a standards process, went live, and it caught things.

Except it made Google the gatekeeper. Anyone can run a log. Cloudflare runs one, Let's Encrypt runs one. But a log is only worth running if Chrome accepts it, and Chrome accepts the logs on a list Google's own programme maintains. The mechanism that was supposed to make that unnecessary, log operators communicating with each other to confirm they're all being shown the same log, never shipped. It had some technical challenges, but really it was bogged down in multi-year standards negotiations, and that let Google just say, "that's fine, we can just control everything, thanks."

I'd been circling this for a while

For a year I'd been building zKal: ZK proofs that let people prove things like attendance, eligibility or reputation, without the data ever leaving their device. The EUDI wallet's privacy promises, except actually kept. I've since parked it, but the cryptography we developed lives on.

I worked on it with Mircea, a Metamask core dev who also built Veramo, an open source library that makes identity data portable so people aren't locked to one provider. Two timezones apart, Jitsi call, Excalidraw open, our own shorthand for crypto operations scrawled across the canvas.

We kept figuring out things that people said were impossible. Full key custody and rotation with no seed phrase. Restoration on a device with no server. Moving data between wallets with no reconfiguration.

I always needed a concrete use case to design against. I'd run scenarios and permutations, looking for simple designs. Mircea was usually three moves ahead, designing for a gotcha I couldn't see yet.

He kept steering me back to one thing. I'd hand him a clean, practical answer; he'd point at something and scrunch his forehead. "There! Domain-rooted security again." And send me back.

Sometimes it felt like he was Mr. Miyagi-ing me.

DNS hijacks felt out of scope. Until Berlin.

Berlin

I flew in, and we spent the day walking the parks, jumping between topics. I kept circling something that bugged me. Some explorations would dead-end at the same wall: "that's why everyone ships wallets as browser extensions."

I didn't want to accept it.

Extensions are clunky, their app stores are sketchy, and it felt like we keep dumping a whole app into a sandbox just because the sandbox was the only thing with verified code. I wanted to know where the actual security boundaries were, between the app, the wallet, the storage, instead of shoving everything behind one wall.

In your browser, extension code is hash-verified. The actual webpage sitting next to it isn't. Integrity for extensions, integrity for subresources, and nothing for the page that contains them. That suspicion started.

I was already staring at the answer without seeing it: the verification chain I wanted could be bootstrapped from an extension. One small check, watching the page from its secure extension sandbox. Does this domain, this page, hash to what it should?

Mircea's eyes lit up. "That's actually a great idea. It's something that should really be built into browsers."

I was almost annoyed. I remember thinking: I wish the browser people had already sorted this out, so I could get back to the fun wallet stuff.

Then I went looking

So I built it, an extension that pins DNS records, and then worked my way backwards through the technical question I'd skipped.

But there was a bigger question I couldn't shake. If this should be a native browser feature, how does that even happen?

I know people on W3C committees. I've watched the sausage get made, and I've read the autopsies of how standards bodies consistently ruin good proposals, because the big players in the room all have a business model to protect.

So I looked at Let's Encrypt, the one org that got past both the standards process and the certificate cartel and changed what the whole web does by default. They now run their own transparency logs on Sunlight, a deliberately simple CT log design, and Sigsum, a minimal transparency log built so that trust doesn't accumulate anywhere in particular.

Then Mircea found WEBCAT. WEBCAT comes from the Freedom of the Press Foundation, and it's further along. A working extension, built on Sigsum, that verifies a site's manifest carries signatures from developers the site owner has named. Their client is the website operator; their users are journalists and whistleblowers, people who will do real work for real safety and who are targeted by people with big budgets. Their enrolment even includes a cooldown before changes take effect, so a stolen domain can't be quietly re-enrolled. It's amazing work, and they'd already found most of the answers I was looking for.

This led me, ironically, to Google's transparency conference talks, where I discovered WEBCAT was leading the way for a new standard called WAICT.

WAICT, Web Application Integrity, Consistency and Transparency, is a draft specification with Cloudflare and Mozilla in it: hash every file a site serves into a manifest, commit the manifest to a transparency log witnessed by independent parties, have the browser refuse anything that doesn't match. It's a good draft. The problem is we've just established what the big players do to good drafts, so I'm not holding my breath. But Cloudflare describe the goal as app-store-grade security for web applications without a central gatekeeper. That's a world I'd like to see.

All these assume the website operator opts in. That's the part I'm wrestling with. It's the right assumption for a newsroom and the wrong one for the bank my mother uses, because it requires the website operator to cooperate and do helpful things. Website developers are not exactly known for being cooperative, and banks are not known for being helpful.

Protecting someone who uses sites that will never opt in lets me relax constraints the others can't. I can let domain lookups leak, for instance, since they leak through DNS lookups anyway. (Besides, CONIKS gives us a way to make those lookups private later.) Operator-first and end-user-first: same wall, different sides.

So why isn't this solved

It has been tried. For over a decade. I watched a lot of it.

The DNS pinning primitive I'm making has a famous, and crazy, granduncle. HPKP, HTTP Public Key Pinning, shipped in Chrome in 2015. A site could pin its keys and the browser would refuse anything else.

Setting it up correctly was hard. You had to pin a backup key you weren't using yet, keep it safe for as long as the policy lasted, and get the rotation windows to line up with certificates that expire on their own schedule. Get any of that wrong and the browser does exactly what you told it to: refuse the site. With nothing you can change from the server, because the server is the thing being refused.

The protocol itself wasn't well designed, and website operators kept footgunning themselves. They pinned themselves off their own sites. Smashing Magazine, an advice site for web developers, did it to themselves with a year-long policy. And HPKP created a new kind of attack, too. If a hacker can get into a web server even briefly, they pin keys the owner doesn't have, and then hold the site to ransom.

Some people argued for fixing it: better tooling, safer defaults, a way to recover. Chris Palmer's intent to deprecate went out in October 2017 instead, and pointed operators at Certificate Transparency, which didn't really solve the same problem but was considered safer because you could recover from your own mistakes. Chrome deprecated HPKP in 2018 and removed it in 2019. Firefox never finished shipping it; Safari and Edge never started.

Same plot as before. The mechanism that let a site defend itself was removed. What replaced it was Certificate Transparency, enforced by browser policy that Google controls.

Browsers are dead, long live the browsers

To put anything new in a browser you needed the standards bodies and the big vendors to play along, and by then it was clear enough what that game does to anything threatening their app store or advertising revenue. They don't fix these problems because they sell the app store as the fix.

So if you wanted to change what a browser checks, you had to build your own browser.

Dat and Beaker gave you a peer-to-peer web with a browser you could install and a data model that travelled with you. Elegant, self-contained, still admired. Paul Frazee wrote it, and before that the first Secure Scuttlebutt client. When he stepped back he was clear about where it broke:

"The challenge was that Beaker apps had no backend. If you want to build 100% client-side SPAs, you need something akin to a Firebase: a toolkit of databases, users/identity, and networking. We took a lot of shots at building that, but struggled to create APIs which matched the browser's security and page-based runtime model."

There's domain-rooted security again. Mircea's spiritual ancestor, speaking.

Paul's the CTO at Bluesky now, where the answer is peer-to-peer structures on a federated network: portability kept, but with servers instead of peer to peer.

Scuttlebutt built a whole social world that worked off-grid. Gossip protocols, cryptographic identities, the works. Rabble ran Planetary on it, then moved to Nostr, and his account of why is worth reading whole:

"I was never building tools just for solarpunk anarchists."

Which meant building for communities where he wouldn't feel at home. He lists what came out of people hitting the same limits: earthstar, p2panda, moderator, chatternet, nostr, farcaster, and the at_protocol.

remoteStorage tried to prise your data loose from the app that held it, so an app could be swapped without losing the notes you took in it. The pattern was good enough that Solid picked up the same thread years later. It had Tim Berners-Lee, Inventor Of The World Wide Web, behind it. But almost no app adoption.

And people are still building new browsers. Peersky and a handful of others have some of what I've been describing baked in from the ground up. But decentralization is not a word that makes a normal person change browsers, and so far every one of them has found the same small, technical, already-convinced audience.

None of these died of bad cryptography. Some are really well designed and are still running today.

So there's a different problem.

The hubris

"I love these people, they're a team who can force silicon, lithium, and code to bend political reality. But I cannot stand the compromises we have made in the name of this hubris."

That's Cade Diehm, the same Cade who helped me with zKal. He was on the team in Hawai'i in January 2015 while Signal was being finished, arguing that phone numbers were the wrong identifier: "This app is going to be used by people escaping intimate violence. Their abusers know their phone numbers. You need to let them in with pseudonyms." He describes Signal's founder, Moxie Marlinspike, rolling the interface back with a shrug, insisting instead that address-book discovery work as smooth as butter. It was the first time he met someone who could "look at the risk and simply not see it".

Cade was right, and after a decade it's obvious. Usernames finally arrived in Signal in 2024. Even the people putting real cryptography in ordinary people's hands can miss what their compromises cost, because the people who pay aren't in the room. That's the hubris I'm trying to avoid.

Meanwhile, on your phone

You stand in your kitchen, mug in hand, and ask yourself if it's really yours. Your kitchen answers you, yes. You're comforted, somehow, even though something in you knows your real kitchen doesn't talk.

Except this time it's not some website, it's your one itself. And the one who's tricking you isn't a hijacker, it's Google itself. Plot twist!

And Google is now requiring every Android developer to register with them personally, with government ID and twenty-five dollars, before their apps can install at all. It starts in September, in four countries, through the app stores. By 2027 it covers all apps on certified devices, which is nearly every Android phone on earth, outside China.

Same move, third time. Take out the thing that let people check for themselves, then keep the list of who's allowed to be checked. I've stopped being surprised by it, and I don't think that's an improvement.

What's actually possible

You write an app. You sign it with your own key. You send it to a friend, or put it on a website, and their browser checks it against a public log that nobody owns. The same integrity guarantee an app store gives, but no need for the store.

Who made it, who has looked at it and what they found, travelling with the app instead of sitting in one company's database. No permission, from anyone.

The pieces exist. Sunlight and Sigsum are running. WAICT is being drafted by people who ship browsers. WEBCAT has done the most work. They built something that works today. The pinning layer needs nobody at all. That's what I've built, and it runs against domains that have never heard of it.

What I'm exploring now is the rest: reputation without a five-star rating database, where quiet signals like usage and drop-off tell the real story. Key theft and recovery, where sharding and a delay before a handover takes effect buy the time to catch attackers. And false positives low enough that a warning still makes you stop the tenth time you see it.

What are the right questions?

Which brings me back to Cade in that Signal mansion. Ten years ago you had to guess which trade-off you could afford. The tech surveillance of today was only on the horizon.

Whole ecosystems saw it coming though. They wrote the apps, ran the servers, onboarded their friends, and now have ten years of experience seeing what actually worked. Even if it was just for niche communities.

Those are lessons I want to learn from.

The big questions I'm left with aren't just technical. They're more like: what is adoption even supposed to look like for something whose whole selling point is that nobody owns it? And what to do about the fact that every institution positioned to help has a reason not to?

Parking zKal: lessons learned

Tue, 19 May 2026 07:45:00 GMT

The best place to start is Brewster Kahle's feedback to me when I was in Berlin:

"This isn't just a cryptography toy for tech events. Activists need this. If they see it, they'll use it for real. You have to get it right."

Then he asked really good questions about the security model — how the ZK proofs worked, where trust assumptions lived, what happened if the server was compromised, what happened if an attacker faked events.

I loved the hard questions. I couldn't stop smiling on the inside. Finally someone understood what I'd been working on for a year! And it was someone who knew what worked - the founder of Internet Archive and Alexa Internet.

I'm glad I had good answers too. It boosted my self-confidence, realising my work was able to pass a serious bar.

This was an unconference session c-base — that spaceship discovered under Berlin, turned into a hackerspace. The first time I was there, I saw the massive array of LED-lit recycled bottles, radiating warmth. Later I noticed the tea station. Community infrastructure. Care. Since then, it's felt like a kind of spiritual home to me.

Talking to Brewster there about Ethereum hackathons and ZK proof privacy — then about people whose privacy needs are life-or-death — it felt misplaced.

Originally, I thought zKal was something I could build as a gift to the DoD team, something I could do to give back. Standing here at c-base, I realised this was something else.

Lesson 1: I built on the wrong question

Two years ago, at ethBerlin, I'd asked ligi a question: "What DoD problem do you wish you'd solved by now?"

Great hackathon question. It surfaced something real: their calendar privacy mattered to them.

But a suicidal product question. There were reasons it hadn't been solved already. Those reasons would bear down on zKal too.

I should have been helping solve problems they were putting energy into solving too.

Lesson 2: I missed the train

After the hackathon, ligi said they might even try zKal at Devcon in Thailand. There was an open door.

I couldn't get there.

I remember staying up all night hacking, taking breaks for baby feedings. The math of babies: At 3AM, two hands aren't enough but four hands make things easy.

I had a flight to Devcon. I couldn't get on it. My family needed me at home. But doors ligi could open wouldn't stay open forever.

Once I had time to commit seriously, I wanted to give it a real shot. I asked if it was still useful. Yes. But the lack of excitement was clear. "Let's talk at CCC" — the door still open a crack. A kindness.

But the message underneath: Sorry, I don't have time for this now.

Lesson 3: I planted the seed in unstable ground

Even if I'd asked the right question and hit the timing perfectly — the organisations I was trying to plant in couldn't support it.

Zupass support was intermittent at first, and eventually it was quietly abandoned. No commits. Support channel dead. ligi and I both loved it, and their new direction with the underlying POD2 framework. I offered to maintain Zupass myself. Didn't matter. They weren't interested.

You might know this smell: when orgs go opaque, it's usually infighting behind the scenes.

DoD had become disillusioned with Berlin Blockchain Week. They politely describe it as too "corporate". What I read in the situation is the broader cultural schism in Ethereum between FOSS values and crypto-bro mercenaries. The practical situation: DoD controls the event listing website, but its a legacy obligation put into maintenance mode.

The DoD partnership with DWebCamp was rushed, broken from the start imho. DoD thought it would mean less work; it was pitched as a chance to curate a stage with their deep connections. Instead they're carrying the operational roles, plus managing a collaboration beset with different priorities, decision-making structures, and operational stacks. And doing the curation. All while being called "the local partner" in public.

Again, I figured I'd push through. The alternative was admitting I'd been building something nobody really wanted. I rationalised it with ethics: do what you can to help the cause.

The smell test for next time: No straight answers? Contributions getting ignored or trapped in political cross-fire? These are not the organisations where a new tool plants adoption roots.

Lesson 4: I mistook principle signalling for adoption choices

A few days after c-base, I spent the afternoon with Cade Diehm. We walked around green suburban parks and coffee shops on a sunny day, while he laid bare the brutal mechanics of surveillance totalitarianism. He's observing a setup for something worse than what we see today.

It put some things in context:

I've heard from more than one person that the web3privacy (now rebranded "Neo Cypherpunk") organizers call privacy "just a meme" behind closed doors. The fact that they still use Luma after two years of being asked to stop backs that up. They're literally handing a list of every activist in attendance to a US server -- a package deal that comes with FISA warrants, Palantir and ICE targeting.

It explains why the real activists in Berlin steer clear from them.

In my conversations with DWebCamp and DoD, nobody wanted to give decision-making power over tool choice away — not even to the teams using those tools. DWeb had been burned by alpha tools before and felt they had enough tooling changes to contend with already. DoD had to take a hard line to get dWebCamp to switch Google Docs and Zoom to decentralised alternates. (Why were these still being used in 2026?) They gave up on the Cloudflare issue, which blew up badly when a few weeks of 404s showed the whole community they were using one of the most centralised hosting platforms in the world. In such a tug-of-war, it was no wonder nobody wanted to stick their neck out to try something new.

This meant that for me, every time I asked about goals or what operational functionally was needed somewhere, calendars or otherwise, the answer was avoided. Instead, it was always about power dynamics: "We'll need keep this decision ourselves," or "You'll have to ask someone else."

This was even the answer after they asked me to take responsibility for their unconference. I volunteered happily, but said we needed to look at goals first, then design to those. And I needed authority over tool choice to meet those needs. That wasn't on the table.

I learned Holochain and Ink & Switch, builders I look up to, had tried contributing before. The dweb team wasn't happy with the results, and I was regularly asked to pass judgement on them, when all I wanted to do was learn from their past experience. I didn't know whose fault it was, but it was another warning sign of a difficult environment.

At that point, I bowed out.

I can understand the time pressures of running events, and how you just grab last year's version and update it. Lock-in is a powerful force, even for dWebCamp, who are personally feeling those same totalitarian trends back home in the US.

But clear out all the reasons why and why not, look past the principles and rationalisations to the user behaviour alone. When have they actually made the space to change tools? What does it take to trigger a change?

I wasn't able to see actual adoption behaviour I could connect to.

Lesson 5: I confused entry taxes with real needs

A simple Node.js app on a small server could remove Ethereum events from big tech infrastructure entirely. hi.events has a one-click install and Pretix is tried-and-true. But that's not the latest tech, so nobody's interested.

ligi had originally suggested ZK proofs because that was the hackathon theme. It felt overkill, but I took it on, and started believing that ZK would be worth the long-term benefits. It ended up being 10X to 20X the time and complexity to build on. Time I didn't have.

What I should have kept clear: ZK was an entry tax.The price of fitting Ethereum's frontier tech preferences, not the price of solving calendar or privacy problems.

Like the entry taxes of selling to banks — procurement, compliance, risk reviews, year-long cycles — stuff that isn't part of the core offer, but still needs to be there. The difference is Ethereum's status currency is novelty, not stability.

That became obvious when DoD shifted to Bluesky — completely open attendance data instead of private. I went right along, and started working out how tack merkle roots into Bluesky event updates.

But let's be honest with ourselves.

When we say, "we need privacy-preserving identity infrastructure," what we're not saying out loud is, "we want to use whatever feels like the next big thing."

In this way, the Ethereum community's instinct to dogfood frontier tech also functions like chasing hype.

Ligi pushed me toward Zupass, and I'm still grateful. The ZK patterns I designed from there — proof projectors, portable-data wallet design, in-browser security models, the density index — those are real. And the're useful far beyond conference calendars.

Both things are true. ZK produced patterns that matter for a more serious class of privacy user. But it was too high an entry fee to a small community like Ethereum conferences.

And back to Lesson 2, my time constraints. I took on a drag factor with Zupass that was really high, and it was more than I could afford.

Letting go is a form of persistence

When I was planning on coming to Berlin for that unconference, Afri told me, "Don't come for zKal. Come to be with us."

I love how he can speak high truths in short syllables.

DoD brings together a community that matters to me and to the world. It was a great week in Berlin.

zKal will return to its simpler version, and we'll use it for The Infinite Build. I'm glad I built my cryptography muscles on a real-life problem.

I'm excited about having the ZK mechanisms in my toolbelt for whatever comes next. These explorations opened a lot of paths outside of events, some about collaboration at scale, and some about the security problems that affect all browser-based apps.

I can see DoD keep up the fight for their principles, but feel their energy slipping. I'm sad there's no way I can help.

Better to try different paths than keep sliding back down the same one. There are many roads to where we want to go.

I keep reminding myself that, and every time I do, it feels like a relief.

Sessions without cookies

Wed, 08 Apr 2026 13:53:00 GMT

The standard session model: user logs in, server stores state, server decides what you're allowed to do.

Structurally incompatible with privacy.

I've been working on something better, called HDK Sessions.

Cookies were the original sin. Once you have a persistent identifier for each browser, building a profile behind it costs nothing. We hoarded data, built profiles, and found ourselves in the surveillance economy. (Lou Montulli built cookies in 1994 so MCI could offload e-commerce state to the browser. But the very first deployment was Netscape's own site tracking returning visitors. Montulli protested when ad networks co-opted the technology. His own employer ignored him, then sold to a media company built on eyeballs. Funny how that worked out.)

So HDK Sessions asks: can we get what we need from server-state but without storing any personal data on the server at all? Authentication, access control, personalisation?

Turns out, yes.

HDK Sessions uses modern cryptography to let users carry their own session state, which is encrypted, tamper-proof, and forgotten by the server the moment each request is done.

But the real win isn't the crypto. It's what you stop storing.

Don't store what the user did:

{ visited: ["/lesson-1", "/lesson-2"] }

Store what they're entitled to:

{ entitlements: ["lesson-3-open"] }

You already know where your access gates are and how you'll assess them. You just do those assessments as they occur rather than historically.

It's actually easier. Even in complex cases, you're composing entitlements rather than doing complex ACLs or database queries prone to edge-case leaks. The instinct to hoard user data is the problem, not the protection. Letting go of what you don't need turns out to simplify everything downstream.

How it works

Your browser generates its own random ID. On each request, it sends that ID, a request counter, and an encrypted blob of your session state.

The server holds one root key. From that key, your ID, and the counter, it derives a unique encryption key for that specific request (using Heirarchical Deterministic Keys), decrypts the blob, processes your request, re-encrypts, and sends the new blob back.

Then forgets. EAch visit is processed once, transiently, to derive the state, then discarded.

Nothing stays on the server. You don't need a database.

The blob travels back and forth in HTTP headers, not a static cookie. You can open DevTools and verify this. No cookies.

And this isn't just cookies with a different header. The architecture centres around proving entitlements and rights that evolve, not collecting personal data.

The big insight I had was that to invert keypairs from the usual sense; the server has the private keys for the encrypted blobs. This allows you to protect the payload from visibility and tampering, making the system behave with the same security properties was ask of cookies and server-side data. But the custody of the data stays with the user. They can delete their own personal data without even asking permission.

HDK Sessions are also just a better technical choice. Beyond privacy, HDK Sessions gives you things the cookie model doesn't:

Architectural Minimalism: In many cases, this removes the need for your app to have a database altogether. Your server just needs to store a secret root key. Fewer moving parts. Way simpler devops.
Compartmentalised Breach Impact: Per-request key rotation means a leaked key exposes exactly one request, not your entire session. Replay protection is structural. A blob encrypted at counter N can't substitute for counter N+1.
Dual Breach Requirement: A server breach gets the root key but not your blobs. A device breach gets your blobs but not the root key. An attacker needs both. That's meaningfully better than a database breach, where the server holds everything, and that everything contains personal data.

Where you might still want a database

There are cases where HDK Sessions don't replace server-side storage.

Header size limits. The encrypted blob travels as an HTTP header. Practical limits across CDNs and proxies sit around 8KB. A typical entitlement-based session runs 200–500 bytes, so this isn't binding in practice. But if your state outgrows the header, and you don't want to purge (the library has a provision for cleanup), then your alternative is to keep encrypted user state server-side. The decryption key can still live in the HDK session payload, so the data is still only accessible by the server on client action. A little server storage, and the user still controls when it's accessed.
Compliance and financial data. For shopping carts, payment processors like Stripe handle the sensitive data. But some compliance requirements mean you keep records. Here, you can (and probably should) use a distinct anonymised ledger, not a user profile.
Social and relational data. Data that changes state between user interactions, like messaging, collaboration, social graphs, either needs decentralised systems (Bluesky, blockchains, p2panda, etc.) or a server database.

The point isn't that databases are bad. It's that if you're keeping a server database just for session state, you're making your life hard and making privacy hard.

HDK Sessions are for the large class of applications that adopted server-side profiles not because they needed them, but because cookies made them the default.

I've built a SvelteKit library if you want to try it, and you can see it in action at One Line For Your Mind (source). The full design rationale covers the trade-offs honestly — including what this doesn't guarantee.

I'd love to hear your thoughts.

The Density Index

Mon, 06 Apr 2026 13:52:00 GMT

My first Ethereum conference was 20,000 people, sprawled across Amsterdam.

I had a game plan. Find the venues where someone was putting in effort for a great experience — not big-name speakers or swag, but comforts like good food, and communal spaces away from the megaphones. Because when an event works, it's because the people in it are at their best. Learning, conversation, connections. All of those depend on the state of the people in the room.

That lead me to 0xPARC's Dark Forest conference.

After the talks, we've all seen small crowds form around speakers. People waiting their turn to get answers in a topic they care about. The speaker's coming down from nerves, just wants a bottle of water, and the whole conference environment isn't built for this moment to be good. But it's where you can find the meaningful questions, thoughtful expert answers, and deep conversations.

And if it's your topic too, it's where you find your people.

I hit it off with a bunch of game developers.

The Amsterdam tourist district was a drunken, crypto merch explosion. I wondered how many were setting themselves up to get pickpocketed, or worse.

What struck me about the whole Blockchain Week experience was the exclusive events. Tickets sold out on the event pages. Bouncers at the door. Then you'd get inside and find a mostly empty room. Like clubs that keep a line outside to look full.

A group of us figured out a better way. Check which events your friends were at. Show up. They'd come to the door, maybe grab the organiser, who'd be happy to let in people vetted by their community. No tickets needed.

I had to be missing something. Crypto was supposed to be about economic design, and nobody had solved this economic design problem they were all living through every summer?

The design problem

Blockchain Weeks have a no-show problem. RSVPs are free options, organisers compete on hype, and the events that could really move people forward get lost in the noise. Years later, I'm building zKal, and the Proof Projector architecture it uses gives you a privacy-preserving way to publish aggregate signals from private attendance proofs.

It's a crpytophraphic pattern. It doesn't tell you what to aggregate. And that turns out to be the harder question.

But the constraint helps by bringing the design challenge into clearer focus.

When you can't see raw attendance history — because privacy — you have to ask: what's the thing across all this data that tells you something real?

It breaks down into two specific functions:

Projector Function: What single, anonymous number comes out of an individual's private history?
Aggregation Function: How do you combine those so they're useful to others in the community?

What the weight needs to capture

If you've run meetups or conferences for some time, you've seen a general progression.

First, someone's checking out the scene. Is this a place for me? They're scanning the topics, the vibe, the people. Big-name speakers help here — trustworthy authorities who high-level the current issues, a fast track to understanding what matters.

Then they start applying what they've learned. Their needs shift. They want practitioners who are various distances ahead of them on their specific path. Too many big names actually get in the way at this point. They become noise to a signal that's about practicalities — projects working and learning in public, people who've been building for six months or a few years and have hard-won things to share.

The crypto ecosystem is full of these people, but the conference structure very rarely surfaces them. I'd argue this is the one of the big reason we have a chasm between many with deep interest and only a few succeeding projects. (The other is over-funding kills projects, but that's another thing altogether.)

On the other side, you get the committed communities. Specialised workshops, cohort programs, or just small rooms of people around hands-on practical topics — seemingly niche but major unlocks for anyone in that space.

A good weight function should reflect where someone is in this progression, and match them to events where they'll get the most out of it.

The formula

zKal is a self-hosted ticketing platform, but you can host for an entire community of events. The tickets are private ZK proofs, and the fun part is how tickets can get released in phases. A phase is for people who have been before (they need an attendance proof) or who've been to related events, and then there's open access. Event hosts choose the amount of tickets and timelines for each phase.

When someone proves eligibility for a ticket, the proof carries properties derived from private inputs, their prior event attendance: recency, event type, event size. Enough to generate a single weight. Not unique, not traceable.

Only the weight enters the aggregate layer. The person doesn't.

participant_weight = recency × trust × size_normalization

Recency uses exponential decay — weight halves every 12 months since attendance. Recent engagement matters more, but older participation still contributes. Nobody gets permanently locked in or locked out.

Trust reflects how often a prior event is cited as an access credential by other events in the ecosystem. It's bounded between 0.33 and 0.66 on an S-curve — starts increasing after 2 independent citations, saturates after 6. This prevents any single anchor event from monopolising reputation while rewarding events the ecosystem organically values.

Size normalization is the inverse of the prior event's RSVP count. Smaller, more focused gatherings carry stronger signal.

The event's public score is:

Density Index = mean(participant_weights)

The Density Index is a single public number per event, visible in realtime on the calendar. It tells you how likely this event is to have a high density of people who actually care about its topic.

That's the model I started with. Grounded in years of running meetups and conferences, encoded into math. The question was whether the math would agree with the experience — and where it would break.

Breaking it

I vibe-coded a scenario simulator and threw two years of blockchain week event listing data at it. No historical attendance records existed, only event listings — so the exercise was about ranging assumptions across scenarios and looking for where the model fell apart. Each run would push a different set of permutations; event hosts playing the Density Index game, and participants reacting to it.

I kept running it, scanning for outcomes that looked wrong or broke free from what the incentives were supposed to do.

Running it again and again and again.

Under-curation

The first thing that broke was the obvious way to game the system. Event hosts can select relevant events for theirs, which give early access and up your event's Density Index.

Hosts that want to attract big crowds can just select a large number of other events for early access to their — or cherry-pick attendees from the biggest or most exclusive events. The simulations showed an optimal range of 3–4 relevant intake events, with an inflection point around 5. Go beyond that and you're not curating, you're harvesting.

So the Density Index gets a curation penalty — an S-curve centered at 5 listed qualifying events. The farther from that range, the steeper the cost.

Density Index = mean(participant_weights) × curation_penalty

The limit forces choosiness -- picking the right people for your event rather than mainstream or "in-group" event.

The modeling was about finding the right shape for the penalty — where to set the inflection point, how steep to make the curve.

Collusion

The curation fix surfaced a deeper problem.

A related event adds weight to yours through the trust factor — but that relationship can be faked. Two organisers list each other as qualifying access events, fake a bunch of attendances, and points go up for both.

Mutual cross-listing for free score. Vouching rings. Circular amplification.

But responding to this with typical collusion detection is tricky.

In crypto events ecosystem, there are natural cliques. Polkadot events have their specific crowd. The ZK chains are kind of the same people, competing with each other but sharing a core community. DAOs and the pro-social funding crowd are another cluster. They form organically around shared interests. Some of that is unhealthy: siloed knowledge, exclusive in-groups that atrophe. But a lot of that is healthy. Tight relationships, internal jargon and mental models. That's how communities cohere.

Separate from these cliques, there's a small network of event marketing people who work across the better-funded projects. They co-promote constantly, and it produces a sameness across events — similar lineups, similar sponsors, similar vibes. This creates a form of de facto collusion, horizonal integration for conference visibility. Not great, but it's how the conference industry works. This shouldn't necessarily be penalised unless it can be empirically demonstrated that those events have weaker communities.

So the model needed to reward two things at once: a returning core community (which shows your event is good and your community is strong enough that attendees will find great conversations easily) and genuine openness — pulling in diverse groups based on topic-interest rather than who-you-know access. True inclusiveness, not in-grouping.

Then it needed to penalise the gaming layer without punishing the organic collaboration underneath.

The answer was a steep anti-collusion penalty when two events cite each other above 40% mutual overlap.

Density Index = mean(participant_weights) × curation_penalty × anti_collusion_penalty

As an event host, you can collaborate broadly. But the Index rewards you for having a distinct community core and for drawing in people from genuinely different communities. Not for trading favours with three friends to look exclusive.

Scarcity and sorting

The penalties had a side effect I noticed when I looked at the scenarios qualitatively.

When early access is limited — for both hosts granting it and participants earning it — exposing the right events increased demand for them, and that demand moved scarcity to them. Anchor events got more exclusive too. And participants started self-selecting into topics that actually mattered to them.

This maps to the progression I described earlier. The newcomer checking out the scene gravitates toward big-name events — broad, authoritative, good for orientation. But someone who's been applying skills for a while, who needs practitioners and practical work, starts gravitating toward the focused rooms where those people are. The Density Index was matching the-events-you-want-now with the-events-you-can-get-into-first.

The model was shifting high scores away from large general events toward focused rooms with strong community stickiness — with the exception of anchor events that the whole ecosystem genuinely draws from. The design was encoding the sorting that conferences have never managed to produce: people finding the rooms that match where they actually are, not where the hype tells them to be.

Whether this plays out in practice is the experiment. But the simulations showed the mechanism — expose quality, distribute scarcity, and people sort themselves toward depth over time.

Small samples

One practical problem: early-stage events with fewer than about 10 signups were wildly volatile. A few strong attendees could spike a score. A few early signups with no history could crater it.

The fix is Bayesian shrinkage toward the ecosystem mean for events under 30 RSVPs — a weighted blend of the event's raw Density and the network baseline, stabilising scores until there's enough data to trust them.

Density Index = mean(participant_weights) × curation_penalty × anti_collusion_penalty × baysian_shrinkage_factor

Without it, your newest events will be the noisiest, with the least trustable score. And we want the opposite effect, to help people find the small but good events that are right for them.

Those are where the strongest connections and relationships form.

The new game this creates

Right now, event organisers play one game: maximise RSVPs, compete on hype. The currency is attention. Free drinks, big-name speakers, aggressive cross-sponsorship. It degrades into out-spending, not out-performing.

The Density Index creates a second game. Your event has a public score — a signal of whether your attendees actually show up, how strong your community core is. That score gets you featured on the calendar. That score tells someone with five choices to pick you.

Returning members become your most valuable asset. You start winning by focusing on building your own community snowball effect, which means serving them better over time.

It shifts the intake goals towards which communities you invite, not just how many people you get through the door.

The cynical version of this game still exists. A competitive event will notice that pulling their strongest competitors' community members spikes their weight. Two friendly organisers will notice that mutual cross-listing earns free points.

But I'm hoping we can still tip them towards a better one.

When your score compounds with genuine retention — people who came last time, brought a friend, came back again — you stop optimising for footfall and start optimising for your community members' success. You want the kind of attendee who'll be building on what they learned six months later. Who'll introduce two people who end up collaborating. Who'll come back because last time mattered. Because when you have a room full of those people, your newcomers meet the people they need to to succeed for themselves.

That's a different conference than the one everyone's been building. It's a different conference week than anyone's ever seen.

Whether the score makes enough organisers play the second game to shift the ecosystem — or whether the edge cases eat it first — is the question worth finding out.

Proof Projectors

Sun, 05 Apr 2026 13:31:00 GMT

Everyone's focused on what ZK proofs hide. We're missing what they can usefully reveal.

Reputation, attendance, commitment, these used to require surveillance infrastructure. We're rightly moving away from that.

But those signals served real purposes. Communities need legibility to coordinate: is this restaurant safe to eat at, is this contractor reliable, did people actually show up, is this neighborhood getting the services it was promised.

ZK proofs now let us rebuild those public signals without the surveillance. Privacy and transparency are not opposites anymore.

I've been working on a system that does this for a specific problem, and the architecture generalizes, so I thought it was worth sharing. (And the gotchas too.)

I call the pattern a Proof Projector.

A Proof Projector is a system that takes privately held proofs and emits public, verifiable signals about a group, a state, or an aggregate — without revealing the underlying personal data. It separates what individuals prove from what the system publishes.

That makes it broad enough for attendance, reputation, eligibility, coordination metrics, and other cases where you want social legibility without a surveillance graph.

The RSVP Problem

I got pulled into this problem by Ligi and Afri, some of the organisers of ethBerlin and Protocol Berg. They're the anchor events of Berlin Blockchain Week.

At Blockchain Weeks, no-shows are a big problem. RSVPs are free options. Collecting them is rational. Organizers compensate by inflating capacity, competing on hype, stacking events against each other.

High-signal rooms — round-table dinners, technical meetups, problem-solving groups, reading clubs, even the good workshops — get washed away under the hype.

And the big events suffer too. The whole system optimizes for attention, not cohesion. You ping between events, feeling like the party moved somewhere else just before you arrived. And there are amazing talks given to echoey rooms that could've been buzzing with great people and projects. When you're back on a plane, you're somehow less connected than you hoped. Ethereum's flagship event in Thailand was badly affected by this — Devcon itself had empty rooms. Everyone was guessing which side event was the hot one, and the sad reality was people were stuck in Bangkok traffic for the whole week.

A fix is making demonstrated participation matter. Signalling which events have sign ups from people who actually show up about those topics. It makes the game less about raw numbers, and more about knowing all the right people will be there when you show up.

I've been attempting to do that with zKal, a privacy perserving community calendar I hacked last ethBerlin.

The Proof Projector

We want data to be transparent, composable. But we want claims about data to be verifiable without revealing the data itself. Most systems pick one. Proof Projection makes you separate them into two layers.

Shine a light onto a wall, over dozens of complex, overlapping 3D shapes and they cast a single 2D silhouette. You can clearly see the outline, but it's physically impossible to reverse-engineer the exact geometry of any single shape hiding inside the mass.

A Proof Projector creates that structural asymmetry. The objects are our complex personal histories, represented mathematically as high-dimensional polynomials inside a zero-knowledge circuit. The public information is the shadow on the wall, reduced to a one-dimensional number.

The proof layer

At the personal layer, we use Zupass and the POD system. The user holds their private history, credentials, and attendance data entirely in their own wallet.

When qualifying for access to a new event, they emit only a zero-knowledge proof about a specific property of that history, using selective disclosure through the Z-API query system. They prove they hold a valid attendance proof matching a qualifying event, without revealing which event, when, or any linkable identifier.

The issuer only verifies that you're eligible for a ticket at a given access phase: the first tickets are open to prior attendees, then to attendees of related events. The ticket issuer doesn't need to know who you are, and they don't need to store any record of you other than ticket inventory for each event. You just tally that one more spot was taken.

With this design, you don't need a central database of ticket holders. No personal identity data needs to exist anywhere, other than the attendance proofs the user keeps in their own wallet and never reveals.

For each signup, the Projector Function produces a single number, a weight, that's projected into the aggregate layer.

Only the weight enters the aggregate layer. The person doesn't.

The aggregate layer

The aggregate layer is public, designed for transparency. That's why it never sees personal data.

The weights it receives get committed to a public record so anyone can verify them and the indexes that are calculated based on them. For immutability, you could use Merkle-rooted attestations on ATPROTO or something like Ethereum Attestation Service.

Those weights are then combined through an aggregate function to produce the public index. This means each event's signup quality score can be reconstructed from the public signup stream. Individual attendance histories cannot.

The Projector Function

The pattern works because the two layers don’t leak into each other.

You have to get clear on what needs to be provable, and to whom, then define the link between layers.

The Projector Function does that. It sits at the boundary between the two layers: it accepts a ZK proof from the personal layer, verifies it, derives a single anonymous value from it, and emits that value into the public layer.

Absolutely nothing else crosses the boundary.

In zKal's case, participants need to prove attendance to prior events to request tickets. Event hosts need signup stats they can actually rely on. The public needs to verify claims about the commitment of their ticket holders, to sense which events will have a solid community.

All of that goes in the public layer.

zKal

For Berlin Blockchain Week, I built zKal. It's an events calendar with ticketing built in, except the tickets are all ZK Proofs using Zupass.

Whoever hosts a zKal instance, whether EF or any local community group, becomes a ticket issuer for their whole community, which can both integrate platforms like Luma as backends, or replace them. Either way, this moves an ecosystem into zero-knowledge anonymous tickets, and lets the whole ecosystem see useful data that helps it improve.

In this role as calendar and ticket issuer, zKal mediates between private individual interactions and public aggregate data. That's where the Proof Projector pattern does its work.

The zKal instance publishes anonymized signup events that include the specific event and a single weight expressing the value of that person's signup to the event. The weight is higher if they have a good attendance history for this event, or related topics.

The crucial property is that you can't connect the outputs back to the inputs; the math discards information. It's one-way by construction.

Trust model

A future version could use a recursive ZK Proof system, like o1 Lab's Kimchi, so the issuer publishes a ZK proof that they checked the ticket applicant's ZK proofs correctly. That would mean full cryptographic verification from public data all the way back to the individual (and still private) attendance proofs: fully "trustless". (Zupass doesn't use Kimchi, or support this kind of true recursion.)

But since each layer can have different trust assumptions, a simpler version is possible.

I rely on a Verifiable Credential from the issuer. That makes the calendar host an issuer for event reputation in their ecosystem, with the same trust model as any VC system. The event hosts or attendees always provide proof to the issuer, and the ticket issuer verifies it and then signs attestations for public record.

In this simpler version, we only trust the issuer to attest they did the eligibility check honestly.

So we have ZK proofs to protect personal data and issue tickets. And VCs for event stats and quality metrics.

What a Proof Projector Must Guarantee

The Proof Projector pattern doesn't get you off the hook on correlation attacks. While the cryptographic proofs can't be reverse-engineered, observing the output values and timing of the Projector can leak metadata.

We need to carefully manage the frequency and granularity of what gets projected. For the pattern to hold, three properties are required:

ZK proofs with private inputs. The proof must be generated from data that never leaves the user's device.
Non-unique outputs. The value emitted into the public layer must not be unique to the individual. The output set needs to be small enough that any given value is plausibly shared by many participants.
Non-correlatable outputs. Patterns across outputs can re-identify people. Some approaches help here: minimizing the possible output set (fewer distinct values means more cover), selecting among eligible inputs privately (ideally randomly), obfuscating timing with batcheing and/or random delays.

In zKal, we don't know which matching tickets a participant selected to compute their weight. That's chosen deterministically (the highest weight attendance proof you have), which isn't randomly, but at least chose from a private set of options.

The Density Index

There's still a catch. The Proof Projector gives you the architecture. It doesn't tell you what to project or how to aggregate.

Choosing privacy sharpens that question rather than dodging it. When you can't see raw attendance history, you're forced to ask: what's the minimum signal, derived from private inputs, that still tells you something real? What aggregate function produces a public number worth acting on?

In our case, how can visible participation history actually shift which events rise, which communities cohere, which rooms fill with the people who matter to each other?

That's a design problem in its own right. It's part incentive mechanism, part community scoring, part game theory. My answer to it for the RSVP Problem is a whole other ball of wax, The Density Index.

Use the pattern

Private and transparent aren't opposites. The trick is separating the layers:

Individuals prove properties about their history without revealing it.
The system publishes aggregate commitments that anyone can verify and recompute.
No central registry required.

When you want social legibility without a surveillance graph, if you're working with attendance, reputation, eligibility, or coordination, see if Proof Projectors get you there.

The Anti-App

Fri, 03 Apr 2026 10:56:00 GMT

Most meditation apps are content apps with calming aesthetics. They want you coming back daily, consuming more. It's a business model thing.

A good meditation teacher does the opposite — they teach you to sit comfortably, in silence, with yourself.

The goal is your independence, not your retention.

I started with that goal. Around that time, I was learning about different schools of meditation, and the Buddhist and Ayurvedic histories that brought them to us.

Koans stood out.

Koans are the Rinzai Zen practice of sitting with paradoxical phrases that resist logical answers. They have roots that run through much of East Asian Buddhism.

Some people say "koan study" but this feels like a misnomer to me. The idea isn't to study them or unlock them like riddles. It's to just sit with them, in meditation or in regular life. To let them be with you, and let them go at the same time. (Grasping is this whole thing in Buddhism.)

The underlying impression I got from Rinzai is that we don't need to earn enlightenment, per se.

Some ants work their whole lives toward the fruit. Others sit under the tree and let it fall. The Rinzai masters say we are all already enlightened! It's just we have trouble noticing it!

One Line For Your Mind was inspired by this. Each session offers a single line, the kind of thing that feels just beyond the reach of logic, something you sit with rather than solve. It lets you respond, only to play with the fallacy of responding.

Three to five clicks. Then it tells you, enough.

Go.

Be.

I built the first version years ago.

At one point, I added a notification.

"Your next session is ready."

It felt wrong though. If the thing has value, people will return on their own terms. I removed it.

"Your next session will be here waiting for you."

Turns out not doing the things 'apps' are supposed to was better for 'retention'.

Around 3-4% of cold users — people who found it through social media, not searching for a meditation app — kept coming back. That was about four times higher than bigger meditation apps at the time.

No notifications, no email signup, no streak mechanic.

Just the thing itself.

Meeting where AI eyes can't follow

Wed, 01 Apr 2026 16:36:00 GMT

I applied to the Community Privacy Residency, and the past projects reminded me of a cryptographic exploration I come back to every once in a while, just for fun.

What if people walking the same path through content on the internet could find each other, without profiles, sign-ups, or any server watching?

Visit the same pages in the same sequence, and you're in a chatroom together. Like recognising a familiar face on the train home from a conference, and starting a conversation.

A true shared secret can't emerge from a deterministic function of public inputs, right? You always need random private inputs for keys, right? Well, sorta.

But this is slightly different. You could build a rendezvous scheme where shared movement plus costly derivation makes it impractical for an attacker to occupy every possible location.

Let's call it a cost-asymmetric anonymous rendezvous protocol because that sounds smart.

It's probably impossible, but it's been a fun driver for me to explore cryptographic primitives that don't get much attention — a lot of paths outside the current ZK/blockchain world that seem left unexplored.

V1: The Hackathon

Ephemerant v1 was a Mina Protocol hackathon entry. It was my first time learning about zero-knowledge proofs, and for the first few days I just couldn't get anything to work. I assumed I just wasn't smart enough.

Towards the end, I realized, after the community folks escalated my questions, that a lot of the underlying library actually hadn't been built.

So I dropped the actual ZK proofs and worked with what the library did have: Poseidon hashes. I tried to build something that felt ZK-ish: a system where your browsing path generates a chain of hashes, and only someone who walked the same path could produce the same chain. No personal data shared, no central authority. Just matching hashes.

Then I remembered William Gibson's Neuromancer. A self-aware AI recruits and manipulates humans to carry out a plan they barely understand. The "matrix" — his networked cyberspace — is where AIs locate, probe, and manipulate targets by intercepting their activity. Hackers use encryption, proxying, dead channels, air-gaps — but these only buy temporary concealment. A determined AI with node-level access generally wins.

It's like the Byzantine Generals problem, except against an AI dragnet.

Ephemerant asks: what if the human connections themselves were unfindable, not just protected by encrypting what's inside them, but by making the address something only shared experience can produce?

This was way funner than saying "educational cohorts," so I ran with it.

It was enough to win a prize. Which I never collected, because they required KYC to pay out. A zero-knowledge chain demanding you reveal your identity to receive a prize for a privacy tool. Sometimes the irony writes itself.

But the problem stayed with me. With generative AI getting cheaper and more capable every month, the question became real: could you actually build this, and could it survive an AI attacker that can impersonate humans and never sleeps?

"I Am The Attacker In Every Room"

Let's define the problem with some math. Picture a site with 20 pages. An attacker can scrape the site, then can compute every possible path permutation and generate every possible key. For a path of 2 pages, that's 380 permutations. For 3 pages, 6,840. An AI scraper runs through all of them, generates all the keys, joins every possible room, and waits silently for any activity to observe.

The v1 design has no defence against this. The hashes are fast to compute. An attacker with a laptop could cover a small site in seconds.

Making each hash hurt

I just had a question - how could I increase the defenders' advantage, making it harder for an attacker to run permutations while cheap enough for a regular user to use this from a phone?

The first thing I learned about was memory-hard hash functions. Argon2 and scrypt are designed so each computation demands not just CPU time but a large block of RAM that can't be shared across parallel operations.

I decided to blindly trust this post I found in an internet forum:

Argon2 was specifically crafted to fix the inherent flaws of compute bounded key derivation functions like pbkdf2. With pbkdf2, you can double your iterations, which will double the time you have to wait to unlock your vault, but also double the time an attacker will take to crack your password (if they have your masterpasswordhash). In contrast to this, argon2 is not just compute-bounded but also memory bounded. This means that - for the same unlock time for you - password cracking will be significantly slower for an attacker attempting to crack your password on a GPU or ASIC, because an attacker cannot run as many instances of argon2 in parallel on a GPU, as they could with PBKDF2 due to memory limitations.

Quick napkin math

With Argon2 set to 512 MB memory cost and 0.5 seconds per computation on a single thread, the numbers for a 20-page site shift:

For 3-page paths (6,840 permutations): ~57 minutes of sequential computation, ~3.4 TB of total memory. For 5-page paths (1.86 million permutations): ~10.8 days, nearly a petabyte of memory.

That's not nothing. But for 3-page paths, 57 minutes is still within reach for a motivated attacker with cloud resources.

What a VDF adds (and why Argon2 isn't enough)

I thought this was a pretty clever idea for a while.

Then I realized I'd missed the point altogether.

Even with Argon2's parallelism set to 1, each individual computation is single-threaded, but nothing stops an attacker from running thousands of them at once on different path permutations. Duh!

And with an FPGA, this might be really easy.

This led me to Verifiable [Delay](](https://storage.ghost.io/c/a6/22/a6222a4e-2e35-45bd-99bd-553de64e73e7/content/files/2018/601.pdf) Functions. A VDF requires a fixed number of truly sequential steps (like repeated squaring in an RSA group) that cannot be parallelized no matter what hardware you throw at them.

Both Verifiable Delay Functions (VDFs) and Argon2 use deliberate computational effort to secure systems, but they achieve completely different cryptographic goals. VDFs are designed to enforce a strict time delay that cannot be sped up by parallel processing, yet their results can be verified almost instantly. In contrast, Argon2 is a memory-hard key derivation function built to defend passwords against brute-force attacks by making the computation expensive in both time and memory, but verifying an Argon2 hash takes the exact same effort as computing it.

Don't worry if you're confused too. I needed to ask an AI to explain this to me:

Feature	Verifiable Delay Functions (VDFs)	Argon2
Primary Goal	Delay	Password hashing
	Enforce a prescribed sequential delay while producing an output that is efficiently and publicly verifiable; common applications include randomness beacons and leader election.	Password hashing and password-based key derivation; RFC 9106 also includes proof-of-work applications.
Parallelism	Sequential	Parallelizable
	Sequential by design: the delay function must take time even on a parallel computer. Some proof-related work can be parallelized, but the core delay remains the sequential bottleneck.	Parallelizable by design: Argon2 aims at effective use of multiple computing units, and its parallelism degree is the number of parallel threads.
Resource Bottleneck	Compute	Memory
	Dominated by sequential serial work; in common RSA-group VDFs this is repeated squaring, and concrete hardware work focuses on low latency modular squaring.	Memory-hard: Argon2 is explicitly a memory-hard function with tunable memory cost, plus time and parallelism parameters.
Verification Speed	Asymmetric	Symmetric
	Asymmetric: evaluation requires the delay, while verification is fast; the original paper says its constructions achieve an “exponential gap between evaluation and verification time”.	Verification is ordinary password checking against an encoded string containing the parameters, salt, and hash; there is no separate VDF-style succinct proof.
Hardware Resistance	Parallel processing	Specialised hardware
	Resists parallel speedup, but custom low-latency hardware can still reduce wall-clock time; that is why VDF hardware projects optimize modular-squaring latency.	Raises the cost of GPU and ASIC attacks by making attackers pay heavily for memory: the reference implementation says Argon2d is highly resistant against GPU cracking attacks, and the spec says Argon2 increases the time-area product for ASIC-equipped adversaries.

Replacing Argon2 with a VDF gives an attacker using a Field-Programmable Gate Array (FPGA) a massive advantage. The attacker's objective is not to compute one path faster than the user, but to compute thousands of possible path permutations to discover all active chatrooms. Because standard VDFs have a tiny memory footprint, an attacker can program a single FPGA to house thousands of independent VDF-evaluating circuits without facing a physical memory bandwidth bottleneck.

I'd just met ArticMine, the Monero developer, at CCC. He'd told me all about their RandomX algorithm that uses ALL CPU instructions making specialised hardware like ASICs pointless.

I looked at him like Bill and Ted look at Rufus.

"Whoa, you can do that?"

That somehow made things click.

So what about both? Chaining a VDF before the Argon2 hash? Each permutation would cost real, non-negotiable wall-clock time plus memory. Two different bottlenecks: single-threadedness and RAM.

This is one of those beginners' mind things: either it's something useful an outsider sees, or it's completely dumb for reasons I don't understand yet...

It felt like a weird idea that comes from staring at the properties of two primitives rather than their intended use cases. They have opposing parallelism models — why would you chain them? Could you even?

Later, when I could ask an LLM to run this research for me, I learned people already do:

The Chia blockchain (founded by the creator of Bittorrent, Bram Cohen) did something similar with Proof of Space (storage-hard, like Argon2 is memory-hard) chained with a VDF to prevent attackers from instantly simulating alternate histories. The principle is the same: force the attacker to pay in two different physical resources that can't substitute for each other. It was an alternative to Proof of Work and Proof of Stake consensus systems.

The IETF's recent draft "Proof of Process" protocol is a way of verifying a document was created by a human, not an AI.

It introduces Proof of Biological Space-Time (PoBST) to enforce temporal monotonicity and Cross-Domain Constraint Entanglement (CDCE) to bind behavioral entropy (human jitter) and physical state (thermodynamics) to the document's evolution.

It combines VDFs with Argon2id specifically to create multi-layered constraints: temporal ordering from the VDF, memory-bandwidth bottlenecking from Argon2.

So the combination isn't totally novel. What might be novel — or might be naive — is applying it to this specific problem: making path-hash computation expensive enough to deter permutation attacks while staying cheap enough for a single honest user on a phone. The parameters are very different from blockchain consensus, and I haven't found anyone doing exactly this.

Which either means there's a gap, or there's a reason nobody bothers.

I might have stumbled on this same cool combination, but I'm no Bram Cohen.

Time windows

Onto the next problem. Time.

An attacker can pre-compute hashes at leisure, then wait for people to show up.

The obvious approach: include the current hour (as hours since epoch) in the hash input. Different hour, different hashes. So an attacker would have to repeat their work every hour.

But this has two problems. First, the edge case: at 2:01, a hash generated at 1:55 won't match one from 2:05. So, each client needs to compute hashes for both the current and previous hour.

Second, and more interesting: hours since epoch are predictable. An attacker can still pre-compute next hour's and all of tomorrow's and next year's hashes. It's more work, but still possible.

This is where I found the NIST Randomness Beacon — a service that publishes cryptographically random values every 60 seconds.

By including each minute's beacon value in the hash input, you bind computation to real-world time. The attacker can't run ahead because next minute's value doesn't exist yet.

It also gives you a sliding window of one hour, adjusting every minute.

The trade-off: honest users now generate 60 hashes per path segment (one per minute of the sliding window). At two page visits per minute, that's 120 hashes per minute. The Argon2 parameters have to come down to stay feasible on a phone — 64 MB memory, time cost of 1, single-threaded.

Even with lighter parameters, an attacker trying all 3-page paths across 60 minutes faces 410,400 hash computations at ~700ms each (VDF + Argon2). Roughly 80 hours of sequential work per attempt window.

Maybe we'd be better off sticking to two one-hour hashes (current and previous) using the NIST on-the-hour beacon value.

I should note: the NIST beacon is a single point of trust. Alternatives exist — drand, blockchain block hashes — each with its own trust model.

And again, I ask myself, why not combine a few? Say, drand's beacon and Bitcoin's latest blockhash, for example. The difference in time windows would be an issue, but that's more of an implementation engineering problem than a cryptography one.

Finding each other without a server

If there were action movies about computer programming, "it's just an engineering problem" is what you'd hear a character say before dying a slow, painful, and totally predictable death.

Real life brings up real constraints.

And in real life, all of this is useless without a way to compare hashes. Say each client produces 120 hashes per minute. They need to find anyone in the network with a match.

Broadcasting everything to everyone falls apart fast. At 1,000 users, each client would check 120 hashes against 120 × 999 incoming hashes per minute, about 14 million comparisons. At 100,000 users, 1.4 billion.

Okay, using hourly hashes instead of minutely would help but there'd still be a scaling issue eventually. And the wonderful thing about these nerd-snipe explorations is you can let yourself get recursively nerd-sniped. It led me to more wonderful stuff:

Bloom filters compress a client's hash set into a fixed-size bit array (~8 KB). Instead of broadcasting 120 raw hashes, you broadcast the filter. Other clients test their hashes against it in constant time per check. False positives happen (the filter might say "maybe" when the answer is "no"), but false negatives never do. A potential match triggers a direct hash exchange to confirm.

Domain-hash clustering reduces who you talk to. Each visited domain gets hashed, and clients form gossip groups by domain. You only exchange Bloom filters with peers who've visited similar sites in the last hour. If someone hasn't visited any of your domains, they can't share your path. No point exchanging data.

With both mechanisms, the estimated load at 1,000 users is about 880 KB of bandwidth and 6 seconds of CPU per minute per client. At 100,000 users, assuming gossip reaches about 1,000 relevant peers, roughly 8 MB bandwidth and 60 seconds of CPU. That means the CPU is continuously running on a mobile device, so that's way beyond a practical maximum.

And clustering means most real scenarios involve far fewer relevant peers. Intuitively, there's a bunch of observability problems this creates.

Still more questions

Here's where I've left the exploration. I'll have more fun later, and discover new things with these questions:

The Bloom filter attack surface. Broadcasting Bloom filters across the gossip network might itself create the attack vector. If an AI agent can collect Bloom filters from every cluster, it can test pre-computed hashes against them without ever joining a room — just listening to the gossip layer. The Bloom filter is meant to reduce bandwidth, but it might also reduce the attacker's work. Will domain clustering make this even worse? Do the Bloom filters need their own layer of protection?

Gossip bootstrapping. The network needs seed nodes. Domain clustering assumes enough users to form meaningful clusters. Won't this create a separate attack surface?

The mobile computation budgeting is way off. 120 VDF+Argon2 computations per minute at 700ms each is 84 seconds of work per minute. That's more time than there is in a minute. Something has to give — fewer hashes, lighter parameters, background processing that runs behind real-time. Or probably a fundamentally different approach to the time windows.

VDF implementation is non-trivial. RSA-based VDFs require a trusted setup. Getting this wrong doesn't just reduce security — it can break the whole construction. I've participated in various ceremonies before, but just as a good citizen. This is another category I can explore with a fun use case driving my curiosity.

I'm deep in the Dunning-Kruger well. I'm a coder that learns about cryptography as a black box (though I like to rip open the box and poke at the math to try to understand it.) So when something feels easy, alarm bells ring.

If you see something wrong, I'd genuinely like to know.

Silly, but it matters

There's a dystopian version of the internet where every space is indexed by default — where walking through content leaves traces that get aggregated, correlated, sold, trained on models that are used against us. I think we're in that timeline.

Ephemerant is an experiment in the opposite direction: spaces that exist only because of shared movement, that dissolve when the movement passes, that can't be mapped by anyone who wasn't walking the same path.

The engineering is hard. The attack model is unforgiving. The math might not work (yet). But the core idea feels like something worth building toward: that shared experience could produce shared secrets, without anyone in the middle.

The finite game is getting the cryptography right.

The infinite game is enabling the people who share a path to be the only ones who decide on it.

The Third Floor at ethBerlin

Sat, 28 Mar 2026 12:03:00 GMT

ethBerlin is full of rooms you have to find yourself.

At the back of the third floor there's a big, quiet room with good light and big windows. You can really focus here. The food's a long way off, so people bring back fruit and water to share.

I'm there with SDP — Social Dist0rtion Protocol — making one of their treasure hunt games for the hackathon. Ronan's beside me. He made hardhat-deploy. He regularly does things with Solidity that nobody else thought possible, and he wins hackathons the way some people finish crosswords. I'm the opposite: a novice, learning to code again after years away. We became friends because we both stubbornly choose Svelte over React.

One of the hackathon tracks is "meta" — hack the hackathon itself. So I find Ligi, one of the organisers, and ask him: what's the one thing that's been bugging you since last year?

His answer: they're stuck on a Google Calendar backend. Again.

They know they want open, privacy-respecting calendars, but they're locked in, and changing platforms always gets pushed back for the constant urgencies you deal with.

So I start building an anonyming calendar frontend thing with Zupass, the ZK ticketing platform, gating access. Three days of fighting JavaScript. Zupass is built for React. Svelte is ESM, and the CJS/ESM incompatibilities in Zupass are brutal — so I have to cut into it, finding the pieces I need to pull out.

At one point I've been stuck for hours on a module problem I'm too embarrassed to ask for help with. Especially not Ronan who's sat beside me— the man builds frameworks for fun. But during a casual check-in, he clocks that I'm stuck and just helps.

I meet a dad on the third floor. I have a new baby at home. He tells me about Diaper Free — blows my mind. We talk about parenting between hacking sessions. At one point, he helps me find something in Zupass too.

Five Minutes Left

Between running the SDP game and hacking, I'm up for three days straight. Pretty sure this is only possible because of my new dad superpowers.

We get down to the final hours. I joke to Ronan: "you're gonna end up making a new framework instead of shipping your game." He grins. He'd actually done exactly that.

We say: let's just submit whatever we've got. Neither of us think we have a hope, but at least we'll have a record that says we were here.

I've been peeling back Zupass's abstraction layers all weekend. With an hour left, I decide to cut to the root. Implement PSE's Semaphore library directly. Clean. It works. Just no UX.

A minute left. I don't have a name. I tell Ronan. He looks at me, in a French way, and says in his French accent: "well Zkal of course, with a zk."

I'm chatting with friends at the auditorium door when my name gets called. I place first in the meta track and I don't believe it. When I walk to the stage, I feel like I'm tuning into someone else's body from another dimension.

Then the dad's team wins a prize for their social game.

And Ronan wins in smart contracts. Of course he does.

I genuinely wanted to make something useful for DoD, not win a hackathon. So I commit to getting it done.

The hackathon wraps up. DoD does rounds, doing shots with the hackers. I catch a conversation with Afri, another organiser, worried about the no-show problem — how competitive side events and RSVP inflation had even affected ethBerlin that year.

Then I go home. New baby. Difficult situation. A bunch of logistics collapsing at once. Zkal stays a priority in my head, but time is a thing I don't have.

That Slow Squeek is The Sound of Doors Closing

We stay in touch. Each time something shifts, I reach out to Ligi, take on the new direction. Their calendar privacy problem evolves into the RSVP problem — no-shows are ruining blockchain weeks everywhere.

But the doors start closing, one by one. I can't make it to Thailand for Devcon. Part of my prize was a ticket. Ligi had wanted to use Zkal there. That stings doubly.

At another point, Ligi asks for Bluesky integration. Somehow.

This whole time, I know I need to carve out reliable, regular time every weeo to take responsibility for a real app. When I finally have it, it's almost a year later. I check in with Ligi.

Is this still useful?

He says yes, let's talk at CCC.

So I get to work.

The calendar idea has grown into something else. A real answer to the RSVP Problem. A whole cryptography architecture. An indexing system for events to have a public quality signal — a score built from how many attendees have real attendance history — without anyone's identity touching the public layer.

But the Zupass dev channels are a ghost town. Docs are out of date — they're building a new POD2 library. I dig into the codebase myself, trace the paths I need through 50k lines of code.

I push through because DoD matters.

At CCC, Ligi tells me they might bring DWebCamp to Berlin instead of doing ethBerlin this year. He sees Zkal as the schedule layer.

A few months later: the DWebCamp organisers are against it. They're embedded in centralised platforms — sched.com, Google Docs. DoD's hands are already full making the collaboration work with Pretix and Cryptpad.

DWebCamp is a five-day glamping event with ticket prices to match. When people pay, the RSVP problem solves itself. At least for the organisers of the paid event. If you paid 800 EUR for a ticket, you're not likely to flake out.

It's the right move for DoD. New opportunities for DWeb and Berlin. Plus, they've been burning hard for years, holding together a community that matters to the whole ecosystem. This helps share the load.

The downside is that a lot of the regular ethBerlin community won't be able to afford it.

And the RSVP problem Zkal was built to solve isn't a DoD problem anymore.

I figure I've worked on this seriously for almost half a year, I should give it one last shot. I get on a plane to Berlin for the DWebCamp setup event, an unconference.

Besides, I just want to give back to DoD, and I can see they've still go so much on their plates. I've run lots of unconferences before, and I see signs their prep isn't happening, so I offer to help. Even to organise it if they need.

A lucky break

A DoD organiser reaches out on Matrix, and through the conversation I realise — she's from the same team as the dad from the third floor. The one who told me about Diaper Free. The people I'd hacked alongside, whose Devconnect tickets I'd shared when I won more than I needed. It turns out they later built Meerkat — a Zupass-based Q&A system.

There's one problem that was nagging at me. The whole system runs on attendance history, and at launch, nobody has any. My ideas all revolved around DoD and other event organisers bootstrapping old attendance history.

But if someone participated in Q&A at any Ethereum talk in the last two years, Meerkat could have the historical attendance proofs zkal needed.

Back to Berlin

I get invited to help run the unconference the day before, while I'm packing my bags for the airport.

At the unconference post-drinks, I'm thinking about something Ligi had mentioned earlier that day: that zkal could improve the unconference part of DWebCamp. I try to talk to a DWeb team member about what they actually use in sched.com — which features matter, what I should be thinking about. He'd turned up after the unconference, not realising I'd helped see it through.

He waves me off. Says they're going with Pretix, too many competing services to look at. There are other people he clearly wants to meet so the conversation dies. He's not listening when I explain the reason they're going with Pretix is Ligi, that he also asked me for zKal — or that zKal could work as a Sched replacement compatible with Pretix.

A few days after the unconference, Ligi finally has time to catch up with me about zkal, and sees everything that's been built. The DWeb collab is already straining with DoD's use of decentralised tooling. But zkal could replace their centralised form system for the Berlin Blockchain Week site.

He just needs to bring that to others at DoD.

He says he'll get back to me.

That was almost a month ago.

Nice-to-Have

I know it's nothing personal, and I know I missed my chance to respond their needs at first, but also I can't ignore the facts.

Organising events and communities is demanding, and "fix our calendar" never quite gets the time it needs between all the rest.

But the RSVP problem persists. The people in the woods at DWebCamp won't feel it. Everyone else at Berlin Blockchain Week will.

Cypherpunk™ is now gentrified. An empty aesthetic. The corpo Blade Runner vibe is a punk rock jacket at H&M.

Most "privacy" events are run on centralised platforms with shitty T&Cs (cough Luma cough), promoting speakers with bios on X.

Their talk just doesn't match their walk.

They actually push privacy-interested people into the surveillance graph, by forcing them to engage in those tools to participate.

But they play the hype game well, to position themselves as leaders.

The community that actually leads pro-privacy tooling in practice is getting pushed to the fringes.

We know there's no need -- and no excuse -- for Luma and Discord if you're a privacy advocating event.

I'm worried we'll disintegrate now, without ways to find each other.

Better Games

I'm talking to a friend at SDP. SDP are the crew doing the treasure hunt games with at ethBerlin, back when this whole thing started.

We're looking at zkal and the idea of calendars for blockchain week that surface small focused meetups through verified attendance — and something clicks.

Finding the right events is a treasure hunt, it just doesn't feel fun right now.

You know how etherscan.deth.net works? Take any etherscan.net contract link, add deth. in the domain, and you get an IDE with the contract loaded.

What if you could do that with Luma?

Take any luma.com event link, swap in a shadow domain, and get a page listing companion meetups — the focused, ten-person-at-a-bar gatherings that the main event doesn't care about.

You can also use your Meerkat proofs, and more hidden meetups reveal themselves.

The people who've been showing up to related things get first access. Everyone else can see how many verified attendees have already committed. Berlin Blockchain Week becomes a game of discovering the rooms that matter to you, not an over-stuffed fomo calendar.

It doesn't need to be championed through DoD channels. Doesn't need anyone's permission. A game that solves the RSVP problem by making finding the right room fun.

The architecture is there. The concept needs collaborators — people who run meetups in Berlin, people who've never hosted but care about a topic enough to book a table at a restaurant for people to trade notes on it. I've organised plenty of meetups. I'll personally support anyone who wants to try.

Third Floors For Everyone

I keep coming back to the third floor.

How we shared fruit because the food was far away. How Ronan helped me with a problem I was too proud to ask about. How a conversation about diapers turned out, a year later, to be the missing piece.

That's what good community infrastructure produces. Not the serendipity itself — the conditions for it. DoD created those conditions by carefully creating an accessible space, and inviting a high density of like-minded people into it.

zkal can still help people build those conditions at a small scale, around topics that matter to them.

There won't be an ethBerlin this year, but we can still create the same rooms.

Whether it works depends on whether enough people want the same thing.

I think they do. I just need help to find them.

Why does 2600 need St. John's?

Tue, 23 Dec 2025 08:06:00 GMT

It might seem strange that St. Johns University is evicting the 2600's conference after years of collaboration.

I met Mitch Altman at a small soldering workshop I randomly found at my co-working space. I didn't know he was kind of a hacker celebrity.

We spent that afternoon walking around the city. He told me about CCC, encouraged me to share my work as a talk.

We talked about getting bullied at school. I told him about when I was a teenager, convincing my parents to let me bus across the city to a mall food court where the 2600 meetup happened. I'd sit with trenchcoat-wearing nerds, with their schematics and Cinnabons, catching maybe half of what was discussed. But they gave me tips, encouraged me to start my BBS.

That's 2600. They show up, they teach whoever wants to learn, they're kind to strangers. When I finally made it to CCC years later, Mitch didn't remember me—he meets thousands of people. But he was still the same warm and kind man, respecting this other soul standing in front of him.

This is the community that St. John's has decided to evict? Why?

Their official reason was "alignment with values and mission."

It started when someone complained about a pamphlet left on a table by a random conference attendee.

They didn't complain to 2600, they went straight to the university president. After years of collaboration, the university didn't contact 2600, instead apparently doing a secret investigation where the accused couldn't defend themselves, then pointing fingers based on vague, moral accusations.

Most people would accept if St. John's just said: "We're a religious institution, some leaders got uncomfortable with some of the edgier elements that 2600 attracts, so we're deciding to part ways." That's at least honest. Instead of this, we'd be celebrating the years of St. John's support.

I doubt it was actually about 2600 at all.

Many universities have gutted great programs with weak reasons. The sad truth: they're collateral damage from internal power struggles.

St. John's cancelled their fun basketball event, and Columbus Day, not just 2600's conference. Three major cancellations in a year? Smells like political fallout.

We've all seen how protests are discredited by planting violent agitators, or taking things out of context. Same playbook. The pamphlet was just convenient pretext.

The real reason is probably one provost accidentally hit reply-all with a snarky comment last year, started a feud, and they've been cancelling each other's favorite events ever since. The poor communication liaison has to write it up as "for student engagement" and "alignment with values".

I kid you not. This happens all the time.

Whether it's infighting, lack of due process, or just letting their fears get the better of them, St. John's methods are theirs to reflect on.

The problem worth solving for us is that 2600 is having trouble shifting venues.

Hosting can be cut off for many other reasons - renovations, financial trouble, leadership changes. Maybe the administration building gets destroyed in fire and brimstone one day. Who knows.

Universities (at least good ones) compete for access to communities of practice.

In London, UCL, Imperial, and Kings actively seek out technical specialty groups. Oxford and Cambridge have such a rivalry they'd compete for something like this. Go tell a Cambridge prof about a great event at Oxford, and you'll get a lesson in how the British do polite insults.

Student bodies benefit from learning from people at the forefront of their fields. Universities want what 2600 does.

And here's 2600 in New York, a city full of great universities.

I'd love to see 2600 answer with what it already does best: community.

Student clubs hosting cool meetups across New York campuses, with 2600 help. 2600 workshops on digital health, cybersecurity, the things they've been teaching for decades. It'd show which clubs and faculties get excited, which are organized enough to literally open doors.

With active relationships with multiple universities, the frame shifts from "we need to find a venue" to "which university makes the most sense this year?"

The big HOPE conference could even rotate campuses, reaching more student communities.

Mitch gave an afternoon to a stranger. 2600s encouraged a kid to keep going. That person's here now, giving that encouragement back. The universities know they need you. You're already doing all the right things.

This isn't a setback, it's a dislodgement towards something better. HOPE is getting an upgrade.

Federated systems need better affordances

Fri, 19 Dec 2025 14:16:00 GMT

Ploum wrote about PixelFed sawing off the branch that the Fediverse is sitting on. He describes a kind of misuse of the protocol: PixelFed only delivers posts with images to followers.

This is arguably a response to Instagram, but he makes a good point:

In the Fediverse, if a poster publishes text, they expect followers to receive that message.

Followers likewise expect to receive posts, but they might not realize they're only receiving posts with images.

Ploum argues this means the Fediverse should have certain approaches to moderation to prevent such protocol violations.

But there's a deeper problem than respecting the protocol or determining appropriate moderation.

The fundamental issue is the assumption that users have a moral obligation that matches the app or protocol creator's intentions.

I'm not talking about political ideology. I'm talking about something more mundane.

With ActivityPub's federated server architecture, we place the moral obligation on the user to:

Find a server
Participate in the decentralized aspects of the system
Understand the system's implications

What actually happens?

Most people sign up to the big main server. They're not immoral. We've just designed these systems to imitate the centralized ones they're used to.

Their expectations come along with that imitation. They expect to sign up quickly, and get their toots a-tootin'!

We developers saw centralized systems and recognized we needed decentralized backends to make the world better. I absolutely believe that's true.

But we didn't take responsibility for going farther than that.

When we talk about respecting the protocol, we're talking about respecting a set of affordances that we haven't modified from the centralized systems themselves.

We need to design new affordances for decentralised social.

To be clear in my language, from the point of view of affordance theory:

Affordances: When you present a person with an object, they can look at it, interact with it, and learn what's possible. You can look at something and know if it's liftable.

Signifiers: These tell you how to use an affordance. We see these in design systems:

A box with a single handle on top signifies: lift with one hand
A box with two hand-shaped holes on either side signifies: heavier, lift with both hands
A hamburger menu (three lines) signifies: there's a menu under here
A heart under something indicates everyone will see a heart-count go up.

When we look at what went wrong with centralized systems that we wanted to avoid, much of it comes down to misuse of user data, but I think more so:

Centralised systems encourage users to behave badly for themselves

For example, what happens when you have followers and follower counts?

People want to raise that number
You get large controlling accounts
You magnify the divide between people who speak and people who consume
You get influencers
You get people paying influencers to gain access to their followers and reputation

It all stems from the follower count. From the visibility placed on knowing who your followers are, being able to enumerate them—even if you remove the number.

Medium was Ev's answer to Twitter's user behavior

We needed:

More discourse
People able to express nuanced and complicated thoughts
So, long form content

Otherwise, we'd fall into retweeting headlines without reading anything.

But that happened anyway. Medium inherited all the other problems. Not only followers, but also the title, the headline.

What did we get?

Playing to the world of writing good headlines
The rise of Buzzfeed-style "one weird trick" headlines
Social media bubbles and the negative effects on political discourse

To be fair, this wasn't just Medium. This was during the rise of Facebook and Open Graph.

But Medium, in spite of trying to do better, chose affordances that reinforced this pattern:

People retweet/reshare a headline that makes them angry
They believe it because it matches things they already believe
They share immediately without reading the article
Others receive it with social proof: "If this person is sharing it, it must be valid"

Headlines will spread faster than anything else in the protocol. We can't control that.

This isn't a one-sided political problem. It's a problem of the networks we choose, the communication networks, and the affordances and signifiers we choose to participate with.

As app developers, they're affordances that we choose to recreate.

ActivityPub set up an alternative to centralized systems and solved a lot.

But decentralising isn't enough.

Ploum argues you should follow the protocol in its entirety because that's the user's expectation. There's undeniable truth to that:

We should do right by users' expectations.
We shouldn't mislead them.

Are we making it the user's responsibility when it's ours?

Our sign-up mechanics don't reflect the ease of expectations users have for signing up, combined with the difference of "go find yourself a community that is a server."

We're asking them behave in ways where the integrity of the system depends on doing something, but giving them ambiguous directions.

We've also put the onus on server operators, who, if we're being honest, are second-class citizens in the ActivityPub world. It is not easy to run Fediverse servers. We haven't put the same effort into making it turnkey to run servers cheaply and without maintenance as we have into being a user.

Yet our decentralization properties completely depend on these.

When I compare different networks—ActivityPub, Bluesky, Nostr, Farcaster—you see quite different decentralization properties. You have a different way of putting the onus on the user in each case.

We start by recreating the signifiers users are used to, because that's how they know "this is like that other thing":

We make it look like Twitter with a like and a retweet
Or like Instagram with images
Or like TikTok with swipeable videos

Those signifiers tell users: "Here's a handle on top. You can lift it with one hand." We're telling users to expect the same thing.

The signifiers are the same. And so are most of the affordances, just with an extra aspect of decentralization added that they don't really understand yet.

Have we done the full steps of changing the design toward the behavior we're aiming for?

Back to Medium, I've always been interested in: What does long-form writing look like without the problematic affordances?

A though experiment. What if:

There are no titles or headlines
There is no "list of headlines" or "card with title and description." These fields don't exist at the protocol level. (You can use headings in what you write, but they're no longer a special feature.)
The interface is simply a feed of streams of consciousness writing, one post after the next
The only way you could refer to somebody is quote them
You don't separate "comment" from "post" in your underlying ontology
You just say "here's where you've been quoted, go read"
You're dropped into a stream of consciousness

Sure, you'd see lots of people just taking a quote and sharing the quote without context.

The only way you know somebody has interacted with you is they've quoted you. They quote this and they keep writing.

Now we don't have followers in the same sense.

You could still follow people and follow their streams of consciousness, but:

No follow count. No list of follows. It's not the obvious target or game for people to play.
Discovery isn't through a reshare, it's through quoting.
Similarly, the only way for you to see that people are reading your stuff is that they quoted you, or emailed you.
It encourages a different kind of writing. Share your thoughts and move on. You don't even need to think in "full posts", which is freeing.

There are better affordances asking to be protocolized.

We see bloggers everywhere, asking for replies by email. They don't want to "build engagement" but actually just meet interesting people and get into genuine conversations. They want to be in relation with each other.

So, what if our Medium Without The Mistakes simply allowed that instead? Private replies. Co-authored feeds. Let those affordances lead.

This could give rise to very different communication, something more personal and less performative.

I shared this with Manu (linked above, who also responded to Ploum and he pointed out that the profile and feed themselves are the problem. He contrasted forums, which put our attention on discussion threads, not profiles and feeds.

Sure, you technically did have a profile page on forums, but I suspect most people never even bothered checking them. Because your profile on a forum wasn’t really relevant in the context of that digital space. You learned about people through discussions. You see the same usernames popping up and over time you learn things about them.

Every interaction has a well defined starting point and it’s not just one big stream. Plus discussions on forums could stretch for weeks and months and sometimes even years.

This was said in a broader context: Manu was making a case that social media itself isn't healthy. I asked him how he considers his blog being different from Medium.

RSS is entirely personal and private. You make your feed. There’s no vitality inside an RSS feed. There’s no reposting, no boosting, no metric driven surfacing of content. You get everything that’s posted and that’s it.

This leads right back to the question: which affordances are we reproducing?

If we choose to take away just one things, say images or reshares, that's a different set. A different kind of object we're providing. A different animal that encourages different behaviour. But we can't just focus on the one feature we're adding or dropping, it's the aggregate of capabilities we're making possible for that matters.

We're not just decentralising, our goal is deeper: making deeply user-centric alternatives for pro-social behavior.

If we're thinking terms of effects on psychology and individual relationships that we create, that means responsibility for set of affordances we provide.

That's how we'll get the world we're building this stuff for.

Volunteering at the Critical Decentralisation Cluster

Thu, 18 Dec 2025 06:58:00 GMT

*➡️ tldr We need help to operate the CDC! Please volunteer here

Last year's CCC was beautiful chaos. At the CDC Habitat, dllud and parasew from RIAT spun a hurricane together: coordinating 46 talks, a workshop track, 15 assemblies cat herded, thousands of people finding their way through the habitat each day, more watching on streams. With a handful of helpers, they made it work, but it was heavy on everyone. Constant pinballing from one need to the next.

When everybody showed up to help with teardown, we felt the love! This year, we'd like to distribute that support across all four days. Many hands will make for light work.

I'm hoping we can give the guys more of an orchestra conductor's position. Guiding the music. Coordinating instead of reacting. Having time to eat!

How you can help

👷🏾 Habitat Build/Teardown Our conductors will have just driven a van from Vienna with the habitat kit. Instead of them chasing people around after a long trip, we'll try a queue of volunteers ready for tasks. An MQ but for helping hands! Show up, get directed, complete task, repeat. A lot of the tasks are little puzzles. A fun way to make friends.

During CCC, there are a few shifts we need covered each day:

🧑🏽‍💻 Info Desk Review the day's schedule, read about the assemblies, know where they are. And then, hang out at the desk and let people approach you. The few questions that come up often turn into nice little conversations. I met some really interesting people at the Infodesk last year.
📽️ Stage Technician Keep the stage and streaming running, help speakers plug in laptops, make sure audio works before talks start. We'll show you through the setup. It's really just monitoring and occasional troubleshooting. Some AV experience useful.
💝 CDCB (Critically Decentralized Care Bear) Circulate and make sure everyone's okay. Offer water and fruit, those little reminders for self-care we all forget in the neon light. Be available to help the organisers find things or people when they have to focus elsewhere. It's a nice way to get to know different habitat contributors and assemblies.
🎤 Emcee On-Call List The Salazar brothers do a great job emceeing, but last year Diego got sick and had to push himself. Having a few on-call backups will be a nice relief if needed.

Example Schedule (TBC)

Day 1: Dec 26 (Setup)

Build Up: 6+ people (12:00-18:00)

Days 2–4: Dec 27–29 (Stage & Content Ops)

Info Desk: 4 shifts (10:00–13:30, 13:00–16:30, 16:00–19:00, 18:30-22:00)
Carebear: 4 shifts (10:00–13:30, 13:00–16:30, 16:00–19:00, 18:30-22:00)
Stage Tech: 2 shifts (13:30–17:00, 16:30–20:00)

Day 5: Dec 30 (Teardown)

Teardown: 10+ people (16:00–19:00)

➡️Jump in⬅️

We're self-organising. Head over to the infopage From there, join our Signal group and sign yourself up to shifts.

A node/connector perspective

Sun, 14 Dec 2025 15:19:00 GMT

Most of our coordination failures don’t come from conflict. They come from our containers.

Companies, foundations, DAOs.

We build them. Then step inside. We say they’re about guidance, but an org chart isn’t a map. It’s a mold.

People don’t use orgs. They serve them.

Attention and effort drift toward fixtures: boards, treasuries, governance. The work bends toward meetings. Toward process. Success becomes more and more defined as positions held.

When the shape stops working, we don’t question the container. We reshape it. A flatter hierarchy, or a top-down projection of the same structure—circles instead of branches.

A node-connector graph flips the unit of design: from boxes to relationships. You design for a single person, their goals and their connections.

You let the shape emerge.

Networks are already everywhere, hiding under containers.

Reading a Dalton Trumbo biography, I realized the film studios weren’t the rigid hierarchies I’d imagined. They look solid from the outside. But really, only their facades are distinct. Behind them is a different story.

Trumbo was one of Hollywood’s top screenwriters when studios started blacklisting suspected communists in 1947. The studios made an example of him. His name vanished from the credits.

But the work didn’t stop.

The King Brothers—small, pragmatic producers—kept him writing under borrowed names. Scripts moved quietly, hand to hand.

For a decade, Trumbo worked day and night, because that’s what writers do when the world tells them to stop. Under the blacklist, he actually got more work, and employed more and more writers.

The pretense finally collapsed when two directors, Kirk Douglas and Otto Preminger, decided for themselves. They credited him openly. The blacklist lost its grip, if it ever had one.

You can see how film production actually lives on a mesh of relationships. The crews form and dissolve like tidepools: the same grips who’ve pulled cable together in the rain, the same camera ops who can read each other’s eyebrows across a set. Directors pull in their writers, their actors, to suit their styles.

The hierarchy is temporary scaffolding. The relationships are the real structure.

Venture Capital also runs on a node-graph.

Beneath any VC brand, you find a sequence of numbered funds. Each fund has its own lifecycle—raise, deploy, return, close. Each has its own general partners, each with their own web of founder relationships.

Every experienced founder knows this. It’s not the firm that matters. It’s the partner. The person. Their connections.

Accelerators look like programs with curriculum, a mentor pool, office hours and a Demo Day, but under the hood, it's really that each founder's unique situation activate a specific set of relationships. The accelerator opens a network to cherry pick.

A partner checks in. Listens. Notices where things are stuck.

"I know someone who's been through this. She’ll get it. I'll intro you."

Usually it’s not a mentor or a trainer. It’s another founder, still in motion.

Two people who should know each other finally do. And the problem softens, or disappears entirely.

The real value isn’t instruction. It’s introduction.

Container thinking: "Our program tells you what to do."

Connector thinking: "Let’s talk every week and open doors."

Once you see this, you also notice networks that trap themselves in containers.

Bankless Academy was a few seasons in.

The ambition was large—teach crypto clearly, responsibly—but the output was thin. Two finished courses. Each one twenty slides long. Every new season reopened the same question: why is this taking so long?

The DAO's treasury had increased pressure, now threatening budget cuts openly.

On the weekly call, the budget was always on screen.

In DAOs with seasonal budgets, the last proposal writers effectively own the project. That season it was the illustrators and a developer. So the call focused on them.

The coordinator pushed the plan forward, assigned tasks, kept momentum. The writing budget had dried up, but they still needed a dictionary of cryptocurrency terms. He took it upon himself, and crowdsourced definitions from everyone on the call.

Meanwhile, in the sidebar, a different conversation was happening.

A few instructional designers were asking the questions that make or break a course:

Where are learners actually getting confused?
What do they think they understand, but don’t?
What not to explain yet?

Those messages scrolled by while the main call stayed on budget. The illustrators were negotiating scope. The hour was almost up. Someone asked for another week. The coordinator nodded.

After the call, I messaged one of the people from the sidebar.

He turned out to be the person who designed Intel’s training material for retail staff. He knew how to explain complex CPU architecture to a teenager at Best Buy.

He just wanted to help, he didn't care about getting paid.

He came to the next call. And the next.

Each time, the same rhythm. Budget first. Assignments. Not enough time. He stayed in the sidebar. After the third call, he didn’t come back.

No one pushed him out. No one decided he wasn’t useful.

The structure just created scarcity where none was required.

Container-thinking says: "Here’s the plan. Assign people."

Connector-thinking says: "Here’s the goal. Work in public. Share with each other."

When containers break down, reform becomes an endurance contest.

People with talent leave first. Why grind it out when they have better options?

The people who stay are increasingly the ones who prize the position itself. The work grows careful, then brittle. Momentum slows.

This isn’t malice.

It’s gravity.

Persistent structures accumulate weight. Decisions bend toward it.

In security, Defense-in-Depth means layers that make the attacker’s job too costly to bother with.

If they can get over the moats, walls, spikes, they then discover you can drop cow poop on them.

It works—until the castle is taken.

A node-graph behaves differently.

Maybe you've been in a group chat when one or two people stink up the room. A multi-day rant or two people beefing.

Everyone goes quiet.

You see a few people typing… but never sending.

Then someone else sends a dm to a friend about something else. Another group chat starts around that.

People drift across.

From the container view, it looks like a split.

From the network view, it’s just rebalancing flows. Each node is able to reroute as needed.

The relationships stay intact.

Ephemerality is defense-in-depth for networks.

Permanent structures create leverage points: treasuries, roadmaps, permissions, charters. They attract attention. They imply control. They invite protection.

A castle concentrates value, so someone will always try to control the gate.

A node-graph behaves differently. Force your way into any point and the relationships just route around you.

Once we let go of controlling the shape, we escape from assuming we need insides and outsides.

We get a different design question. Not: "What structure would serve this goal?" But:

"How do we give people agency over the connections they need?"

Containers always collapse into politics. Connectors create space for emergence.

A connector is anything that makes the right connection cheap, and in the hands of the individual: an introduction, a thread, a forkable workspace, a lightweight way to reroute when things jam.

We need better connectors.

Keeping contributors

Thu, 11 Dec 2025 10:33:00 GMT

Open-source culture rewards a funny kind of stoicism. We're supposed to bang our head against something for a week before filing a bug report.

Then we see FOSS projects and devrel programs designed like corporate tech support. Layers of escalation. Ticket systems.

The healthier pattern? Stuck → get eyes on it, fast. Anyone who's pair-programmed has felt how this keeps you in flow! Problems seem to melt away as fast as they appear.

But we can't just drop that pattern into FOSS culture. We need to make places that enable vulnerability. Where asking for help counts as a contribution. Because it is. Someone else learns too.

If you look at contributors as if they're product users, you'll see horrible churn. We take in people already motivated enough to use and contribute, then spit most them out frustrated. Or failing silently.

Repos and devrel rooms feel intimidating or cold. But meet a maintainer at a conference? Usually warm and open to help however they can.

The problem's in between: tools built around issues, or processes, or projects. Not contributors.

Discord makes help requests disappear in the scroll. GitHub shows you issue #1234, not "this person tried three times and gave up." The people disappear, the tickets remain.

It tells people: Figure it out yourself. Be worthy before you speak.

Then on the other side, project maintainers feel alone, struggling to attract help.

What's stopping us from making "I helped someone get unstuck" count more than "I closed an issue?" From making active contributors more visible than open issues? From tracking "time to first response from a human?"

We're friendly and willing! We need to make our tools that reflect that.

Healthy forks

Wed, 10 Dec 2025 15:50:00 GMT

"I'm really really angry. And I'll not say more, I don't want to right now, I'll regret it later."

That's from a GitHub issue about naming.

Not code architecture. Not licensing. Just what to call the project.

The story could be an opera. Hackpad was sunsetting after its acquisition, and HackMD emerged as an open source alternative. The HackMD core team commercialized a fork of their own project, labelling the open version HackMD CE. After a while, the community took over the open version. It was going a different direction so they renamed it CodiMD to avoid confusion, and eventually forked to a new repo outside of the HackMD Github account. You could feel the tension through issue comments and half-written PR descriptions—small technical notes carrying the weight of a breakup. Meanwhile, the HackMD team kept maintaining their open version, but also decided to call keep the CodiMD name. Fights also broke out over who represented the "real" project, which forks to take seriously, who could relicense. By the time the community maintainers finally fled to the fourth name, HedgeDoc, you could see everyone was exhausted.

Repos fork easily, by design.

But our social layers around them can't handle it.

Blowups are more and more the norm. Open/LibreOffice, Ethereum Classic, XEmacs, Core/Libre/Canoeboot. Or the long, smoldering feuds: Wikipedia edit wars, Bitcoin Core maintainer beefs. Even Grandmaster Linus Torvalds loses energy to it. He invented Git and decentralised code repos, so if even he's caught up in this, it's everywhere.

What would healthy forks need?

I keep coming back to three characteristcs:

Non-exclusive: people can participate in multiple branches
Self-resourcing: avoiding existential threats
Continuous: divergence happens in small increments, as normal evolution

If you have these three at the same time, the whole orientation shifts. You stop thinking about "how do we fix this organization," and start thinking "how does everyone find the what they need right now."

The pattern isn't just in open-source.

In a builder program I joined, the weekly Zoom calls always began the same way: a grid of faces, the host cheerfully setting the agenda, and after an hour-long webcast, it was time for the Q&A before the breakout rooms.

A few California startup founders took the mic, confidently dropping buzzword and polished jokes. The "I'm here to crush it, bro" types. They were hunting for technical co-founders, and Silicon Valley taught them that dominating meetings gave them visibility. So they brought that culture with them.

You could watch the introverted developers recoil in real time. Shoulders tensed. People muted themselves and started working on something else. Nobody said, "this isn’t working," but each week, I noticed a couple more faces were missing.

Finding a tech founder wasn't a bad thing. Some of the devs wanted to be found.

The problem was structural.

The environment wasn't built for the diverse needs it attracted.

One day someone suggested, "maybe we can choose our own breakout groups?" But the organizers resisted. They were proud of their matchmaking. They didn’t know their matches correlated with the highest dropout rates. They couldn’t feel the friction because they weren’t in it.

The deeper issue was nobody could modify the space to meet their needs.

After enough gentle lobbying, the organizers enabled free-choice breakout rooms. A tiny experiment. For the first minute, it was madness. You could see everyone popping in and out of rooms like they were testing doorways. You could see games of cat-and-mouse, or people jumping back-and-forth in indecision.

To the organizers, it felt chaotic, unprofessional, embarrassing.

To the participants, it was the first breath of oxygen. They were optimising for themselves, reconnecting with someone who'd opened up last time, or someone who they'd noticed spoke their language.

I remember thinking: this is all anyone wanted. To find their people. Not find a team, not choose a track. Just people they can relate to.

The breakout room scramble became a fun game that people looked forward to, part of the culture. It felt more like walking into a local cafe, saying hi to a bunch of people, and choosing who to sit with. After being able to connect a few times, people started meeting on their own. Which, ironically, is what the organisers had always hoped for.

Healthy forks, right in front of us.

We know this stuff, but keep getting in our own way.

Mina was the first blockchain project to use ZK proofs at the protocol level. Its architects and crypographers are deeply respected in technical circles.

But four years in, they hadn't really shipped a usable production chain. The org structure kept getting in the way.

Minacon was an unconference I organised for them—three days where participants had equal control of the agenda. Each day's schedule started with an open grid of parallel rooms with 45-minute sessions. Anyone could propose anything. No speakers list. No speakers room. No VIP treatment. The message was: we all have something to learn from another.

Mina's mobile-device proving had been at a stand-off. It needed app builders, cryptographers, and library maintainers to coordinate. Different orgs, different incentives. Months of forum threads—arguing, not seeing eye to eye.

But five of them in a room for 20 minutes, showing code, seeing what each was up against? It was simple once it came down to practicalities. Instead of fighting over on/off-device ideology, they each saw they could unlock each other. And they quite happily did.

The answer wasn't one or the other, it was both.

Then there were the two orgs running forked nodes, locked in a cold war for years. Communication had always been routed through managers who treated their roadmaps like chessboards—every feature, a pawn to box the other side in. This made "Feature Parity" into a way to exert pressure, but also an uncatchable moving target.

Once the builders were in the same room, they understood each other.

Turns out, both dev teams had wanted the same thing for years but were always forced back by their managers. Their technical debt accumulated, and each dev team though it was coming from the other org. This revelation freed both sides to cut loose, and move towards their common goal.

Forums, boards, devrel—they actually cut off relationships and filtered the wrong information. It wasn't the people in them, it was the structure getting in the way. People just needed to connect directly.

That 3-day unconference took two months of prep. I called every participant in advance so they'd feel okay proposing sessions. Checking in on what they were stuck on. Making sure everyone knew who else they needed and affected before day one.

That was 95% of the effort.

The execs and architects had expected to route their agendas through me, to secure a keynote or other special placement. I’d playfully tell them: "People will really love that topic. Propose a session on it at 9am on day one."

For the unconference to work, it had to stay neutral tool for connections to form and grow, a place where each individual was in full control of their experience. Everyone had a lot to achieve in that short time. It was there to serve their goals.

When divergence becomes painful, it’s usually because the structure stopped responding to the people inside it. Requests get dismissed as "edge cases," problems accumulate, and eventually the only release valve is a dramatic split.

The unconference approach let everyone choose where they wanted to participate, and gave everyone unconditional, direct access to who they needed.

Giving people what they need can dissolve conflicts. Who knew?

I've experimented with this in other ways: people pulling each other into temporary clusters, then drifting apart again.

I’ve started a POC called Fusion: a lightweight way to find collaborators through quick left/right swipes down a list of people. It uses MPC cryptography so small groups can form around everyone’s yes/no choices without revealing them. Private, low-friction, ephemeral formation. Not an org or group you have to maintain—just the right people, right now.

Fission is the opposite: letting groups split without rupture. It's a take on Moloch DAOs, but inspired by the failed NounsDAO forks.

MolochDAO's orignal RageQuit design was meant to incentivise understanding and discourse, because minorities couldn't be forced by simple majority. If they didn't like a proposal, they could exit with their share, so better to get their input first. Ragequit in a NounsDAO structure had the opposite effect, amplifying divisiveness, forcing the dissenters out into the cold. Don't like it? Take a walk. The remaining members also suffered, because they saw massive treasury depletion.

With Fission, a failed proposal can trigger a gentle amoebic split: a minority can still fund their idea in a new DAO while continuing to belong to the original one. A non-exclusive fork. No winner-take-all pressure. No exodus required. And divergence doesn't get suppressed or built up over time.

The social side of forks can be as undramatic as a git branch.

Fusion and Fission are based on social games I've tried in different builder groups.

They worked, so the next step is tool-ifying them. When the tool's in your hand, you don't need fell the need to wait for programs or orgs to serve you. We can start connecting as needed from wherever we are, introducing healthy forks where they're needed.

We can design for healthier forks.

When I look elsewhere for healthy forks, I see real-world examples in film, VC, conferences, academia...

People pick up collaborators as they need them, drop into parallel efforts, and let the structure emerge from whatever they choose to work on. Resources flow to activity.

These are places where nodes connecting and detaching are the real structure behind thin institutional labels and super-imposed hierarchies.

That builder group? Sadly it fizzled out. Turns out one of the company owners was doing most of the work, and when he couldn't agree with the other, he just found another job. They kept it quiet, both names stayed on the site, but the program spiralled.

I keep in touch with some dev friends I’ve met at hackathons and conferences.

We recently started a weekly hangout call. People joined because we were already talking, or because I mentioned someone they should meet.

It's the builder group I always wanted for myself. People with passion projects and always learning random new stuff.

Some of them suspected I had a big, master plan behind it, and that's kind of true? Really it's more of a speculative thesis. I wonder if we might co-develop these connection tools to see what "program", if any, emerges.

Still, we have unanswered questions:

How do we launch a without implying an organizer-participant heirarchy? Even the faint suggestion of a central host leads people to wait for permission. I want affordances that say, "it's yours, make it what you need it to be."

How do we help builders surface blockers early? Open-source culture rewards stoicism: the heroic week of hair-pulling before writing a bug report. (Because of our assumptions about accessibility to help.) The healthier pattern is stuck → get eyes on it. Anyone who's pair-programmed has felt this. It requires norms around vulnerability, and a culture where asking for help is treated as a contribution, an opportunity for others to learn too.

How do we make FUBU real from day one? If first participants don't just use the tools, but make them, then they own it as much as me. That's the the deep pattern with healthy forks: people designing their own tools into their own experience.

I'm open for ideas, and honestly, we're having fun sharing our own projects already. It's just that I think we'll have more fun if any of this works.

Herman's Send tool

Sun, 30 Nov 2025 20:26:00 GMT

HorusPass Send is another find while exploring Bearblog.

Herman Martinus built BearBlog, and has an inspiring projects page. There's something energizing watching someone just... keep putting cool things into the world. And Send isn't just one of those things, it's also a thoughtful application of cryptography!

Here's a little tool that lets you share a secret — a password, an API key, a confession of love — that can only be read once. After the recipient opens it, it's gone. Poof.

The server generates two tokens. Token A goes in the URL you share as a query parameter. Token B stays on the server. You need both to encrypt or decrypt. When the recipient clicks the link, the server hands over Token B — then deletes it. The browser decrypts the message.

It's kind of the same as writing your password on a sheet of paper, but ripping it in half and hiding both halves in different places. If someone finds one, you're still safe.

The thing here is that the server is writing the password, not you, and giving you one half. You have to trust it deleted the half it gave you, right?

Not quite.

Here's what you're not trusting: that the server saw your encrypted message.

Even if the server has the keys, it doesn't have the lockbox. The ciphertext passes from sender to recipient in the URL fragment: everything after the #. Browsers don't send those fragments to servers.

Why not generate both tokens in the browser and send one to the server? Then the server never sees the full key. That opens up another problem: the server would be storing data submitted by users, which opens it up to abuse — people uploading arbitrary content, not just random tokens. This could be even abused by bots, and Herman already has enough fun messing with them. Why invite more trouble.

There's more sophisticated cryptography. You can generate keys that are born split — where no single party ever holds the complete key, even at creation. The browser and server could each contribute randomness in a process cryptographers call "ceremonies" because they like to sound mysterious. Both sides random inputs combine in a way that produces key shares, and neither would ever see the full key. This is the world of threshold cryptography and multi-party computing. Pretty interesting to learn, but also more complex to build.

The beautiful thing about Herman's design: none of that is really necessary, since the ciphertext never hits the server anyway.

I wrote before about Ronan's commit-reveal games and the question he keeps asking: "Why do I need anything else?" HorusPass is the same insight.

What I really like: Herman's explanation on the site is fast and clear. Four bullet points and you understand what's happening. No jargon, no mystique. He wants you to see how it works.

That's a breath of fresh air for me. And it's the same ethos as the tool itself — serving a clear need using regular cryptographic primitives in a practical way. Just like writing your password across two sheets of paper.

The smart way is often the simple way.

Robert's Pink Friday theme

Sun, 30 Nov 2025 19:30:00 GMT

I found Robert Birming's Pink Friday scrolling through bearblog's discover page (I'm new around here, so taking a stroll.) It's a fun answer to Black Friday shopping madness.

The whole theme itself is delightful, but what caught my attention was the typography.

Robert's body definition: 1.075rem, line-height: 1.66, letter-spacing: 0.01em, max-width: 640px.

Getting all these to work together is the the heart of readability, and it's hard! Ever watched someone's eyes while they read different sites? Notice their cadence changing. It's a tiny thing, almost imperceptible, with huge effect. Reading speed, comprehension, even perceived tone, can all change massively.

Web typography gets harder when you have to make it work across different screen sizes and devices.

Then, there's boss mode: system fonts only, no custom typefaces to lean on.

The only other person I've seen nail this is Manuel Moreale. And Robert does it in elegantly light CSS.

I accepted his gift for my new Bear Blog, though I cherry-picked just the well-tuned typeface definitions since I like the default Bear theme too.

Then I read more of his blog. Discovered Robert's a home inspector, not a web designer?

His day job shows up in his writing. A homeowner cries during an inspection, not from bad news, but self-blame. Robert's response: "Go easy on yourself. You're doing the best you can." He draws parallels between fixing a house and building a blog: move in, hang a picture, take one step at a time. He notices how people sometimes enjoy being right more than solving the problem.

It has the same spirit as the early UX researchers who came up as ethnographers. Their approach was slow, quiet observation. Watching how people moved through their day, spotting what hides in plain sight. Like how every home has that landing zone by the door where pockets empty out. A tiny ritual that crosses cultures.

In Indian homes, they saw that power cuts were constant, so they added flashlights to phones. Studying how non-literate users handled interfaces built for Western audiences. They learned the fix wasn’t 'addressing illiteracy' and swapping text for icons, it was recognising that people usually memorise their way through menus. The solution was ruthless simplicity in their own product decisions: fewer options, fewer buttons. That really human approach produced the Nokia 1100, still the best-selling phone ever made.

Robert seems to do the same naturally. He steps into homes, pays attention to how people actually act and feel, and spots what overloads them and what genuinely helps. That empathy.

No wonder he can make an expressive pink website so readable.

I'm glad I found Bear Blog. It attracts like-minded builders using simple stacks, thinking about longevity and meaningful human connection. I feel somehow among my people here, and I'm eager to learn.

Playing with cryptography

Fri, 21 Nov 2025 15:27:00 GMT

Maybe Mental Poker is a good way to start this blog. It's a paper that changed the way I see things.

The paper appeared in 1978. The Cold War was on and the U.S. still classified cryptography as "munitions." Shamir, Rivest, and Adleman were perfecting public-key cryptography. They'd later turn their discovery into RSA Data Security Ltd to put those keys in everyone's hands. The NSA pressured them to stop (though not every US agency agreed) and if the RSA trio hadn't been so defiant, only governments would have encryption today. No HTTPS, no online shopping, no private messaging. The internet would be just surveillance and ads.

So here they were, the godfathers of cryptography, with a dorky puzzle about card games and MODEMS?

Can two potentially dishonest players play a fair game of poker without using any cards—for example, over the phone? This paper provides the following answers:

1 No. (Rigorous mathematical proof supplied.)

2 Yes. (Correct and complete protocol given.)

And then, with a straight face:

You might find it an interesting challenge to attempt to find, on your own, a method for playing Mental Poker, before reading on.

I found the paper last year. I was halfway through a course on the math behind zero-knowledge proofs. I’d implemented Diffie–Hellman. I knew the machinery of public-key systems. Still, I thought, "They're talking to the masters, not someone like me."

The surprise was that their solution hinged on a basic primitive I already knew as a beginner—just used in a way I had never considered.

It got me thinking about everything else.

Why do cryptographic primitives get boxed in?

Key pairs become “encrypt messages.”

HD keys become “wallet accounts.”

Commit–reveal is some toy protocol from the 80s that we say is for auctions, but hardly gets used outside of classrooms.

It's funny how fast we turn a mathematical structure into a product category.

My friend Ronan is a regular hackathon winner. Whatever framework comes out, he dives in and learns it. But when he sits down to build his games, he keeps coming back to a simple commit-reveal.

When he asks, “Why do I need anything else?” he’s not being dismissive; he’s noticing that we're not using the simpler things we already have.

The story with hashes shows the same thing. They were first used in databases for storage integrity. Then someone realized you could use them as proof-of-work and build distributed ledgers. Suddenly, data distribution can depend on verifiable math instead of trusting institutions. Blockchains.

Blockchains didn't require new cryptography. They required seeing hashes for what they really do.

Long division as cryptography

I like explaining cryptography without the mystique. You can think about it like long division. A remainder is a one-way move. When the result of an operation is a remainder, you’ve thrown information away, you can't reconstruct the original.

That’s the heart of most modern cryptography. Functions that run easily forward, and not back.

Encryption? I give you the remainder (the encrypted text), but you can't work out the number I started with (the unencrypted text) unless you know the secret number I divided by (the key).

Hashes seem more complex. How do you get that random looking data from a line of text, in a predictable way? Instead of that tangle of logic gates, you can just think of it like a remainder (the hash) changing when the numerator (the input text) changes.

When you see a complex cryptographic system, you don’t need to internalize every algebraic detail. Swapping it out for remainders helps you understand what's going on.

Seeing what it can do

A hash gives you proof some data hasn't changed. A key pair lets you make something only accessible to one recipient, or prove it came from its source. HD key generation lets you predictably create unlimited keys from a single secret number. Commit-reveal lets you lock in a choice now, prove it later.

It takes a bit of time, but strip away the jargon and you’re left with properties: one-wayness, opacity, verifiability, predictability, timing.

Those are building materials.

Once you see them as material rather than prepackaged products, you start noticing all the uses that weren’t in the original manuals.

Sessions without tracking

Here's something I've been playing with.

User tracking exists because, in many cases, servers need to connect isolated page requests to specific users. So we got cookies, and with cookies we also got session IDs, user profiles, knowing what users have done. This let us make more useful websites for users. But decades after, we saw that servers don’t stop hoarding user data, and that turned septic. GDPR appeared to try and fix that. A legal fix.

HD (hierarchical deterministic) key generation gives us another way.

A browser generates its own random identifier. The server treats that identifier the same way an account number gets used with a seed phrase: a way to get a new set of encryption keys, just for that user, and just for that request.

On the server side, the only things you keep are the browser’s random ID and a counter for each request. No user data at all.

The server encrypts whatever state it needs. Authentication data, rate-limit counters, feature flags, and sends the encrypted blob back to the browser to store locally.

Each page request, the server uses its root key, the user's random ID, and the counter, to get the decryption key it needs to decrypt the data. Then it re-encrypts what it needs with the next key pair, and sends it back to the browser.

No cookies. No "we value your privacy" pop-ups tricking us into clicking the wrong thing.

Servers can still customize content, enforce access limits, respond to user context. But the users data stays safe and encrypted, in their own custody on their own device. They can delete it all themselves.

This privacy win isn't theoretical. It's structural.

HD key generation has existed since 2012. GDPR arrived in 2018. The tools to avoid surveillance-grade storage were sitting in plain sight; we just didn’t think to use them this way.

The real work is play

Mathematicians keep inventing new cryptography. Elliptic curves, homomorphic encryption, zero-knowledge proofs. We're getting breakthrough after breakthrough that genuinely expand what’s possible. But going from a modern ZKP course back to this old paper made something obvious: we're still just scratching at what the early primitives can do.

The limiting factor isn't the crytography itself. It's that we don't understand what we already have. Maybe we tell ourselves it's too hard, maybe marketing people and academic experts make it sound harder.

Joera—another friend—has been building a publishing system for journalists. Not just proof of authorship; actual author control. A writer can revoke access to their work after publication, or move it elsewhere, and the proof structure follows them. No platform lock-in. No hostage situations disguised as CMSs.

I’m working on a cryptographic ticketing system for conferences, trying to solve the RSVP problem. Everyone signs up for a bunch of events but attends one, which leaves organizers guessing and events half-empty. Cryptographic tickets can turn this fomo into a positive signal game, all without surveillance.

A bunch of us hang out weekly. We're in chat helping each other on our projects, showing each other cool stuff, thinking out loud. We play with the primitives we have.

Most people think of Mental Poker as a fun aside—the RSA trio goofing around. Nerd-sniping us with a niche puzzle about modems and poker.

But rereading it now, it feels like they were leaving a message in the margins: the space of possible applications is much wider than we think. We just need to ask, “What else can this do?”

RSA were trying to show us that we already have what we need. They weren't making in-jokes for cryptography nerds, they were inviting us to play too.