Human Colossus blog

Journey to a Dynamic Data Economy

The Human Colossus Foundation introduces key components of a Dynamic Data Economy through a series of blog posts

Part 9: Bonus - when there is no box at all
Robert Mitwicki Robert Mitwicki

Part 9: Bonus - when there is no box at all

Bonus part of the series. The nicest property of the design is one nobody designed. Because nothing in the protocol ever depended on where a message came from, the box turns out to be optional whenever both people are actually present — same building, same local network, Bluetooth, a cable, a USB stick in someone's pocket. This part is about what that means in three situations: conversations that never leave the office, disasters where the infrastructure is gone, and places where the infrastructure is the adversary. Most systems degrade to a spinner. This one degrades to talking directly to the person.

Read More
Part 8: What we haven't solved
Robert Mitwicki Robert Mitwicki

Part 8: What we haven't solved

Part 8 of the series. A series that ends with a summary of its own achievements is marketing; this part is the ledger instead. What remains visible even when contents, senders and contact lists are hidden — and what padding, cover traffic and rotating addresses really cost. Why losing your keys is still serious and social recovery is not a finished design. Why the most likely failure isn't cryptographic at all. And the four shortcuts we won't take to fix any of it.

Read More
Part 7: What happens when your box goes away
Robert Mitwicki Robert Mitwicki

Part 7: What happens when your box goes away

Part 7 of the series, and the one that decides whether any of the rest was real. A box is a machine run by somebody, and it can go down, go bankrupt, or be seized. This part does the accounting honestly: what you actually lose (some undelivered mail), what you don't (your name, your contacts, your history, your reachability), and how a conversation gets stood back up somewhere else from the copies its participants already hold. Then the consequence that matters most — when leaving costs an afternoon, hosting has to compete on service instead of on lock-in.

Read More
Part 6: Federation you don't have to configure
Robert Mitwicki Robert Mitwicki

Part 6: Federation you don't have to configure

Part 6 of the series. Every part so far quietly assumed both people keep their boxes in the same place. This one drops that assumption. Routing between boxes is derived from identity rather than agreed between operators — no server list, no application to join, no admin handshake — which means two operators who have never heard of each other interoperate by default. And because writing to someone already requires a capability they issued, the network can stay open at the routing layer without repeating email's slide from open federation into a handful of gatekeepers.

Read More
Part 5: Channels without a platform
Robert Mitwicki Robert Mitwicki

Part 5: Channels without a platform

Part 5 of the series. Group chats, announcement lists, newsletters, team rooms and public feeds are separate products in every platform you've used. This part shows they're one object distinguished by two questions — who may write, and who may read — and that the shape says nothing about whether it looks like a chat, an email thread, a forum or a timeline. That's a decision for your client, not for the network. Includes the case I find most interesting: a public feed anyone can mirror and anyone can verify, without trusting whoever is serving it.

Read More
Part 4: A server that cannot read your contact list
Robert Mitwicki Robert Mitwicki

Part 4: A server that cannot read your contact list

Part 4 of the series. A mailbox open to everyone is a spam funnel, so something has to enforce who may write to you — and the obvious way to do that is to hand your provider the list of everyone you know. This part is about why that trade isn't necessary. Admission can work like a ticket rather than a guest list: the box checks that a sender holds a valid one, learns nothing about who they are, and ends the day knowing how many messages arrived and nothing else. The social graph is the half of privacy that end-to-end encryption never protected.

Read More
Part 3: The Mesaĝkesto
Robert Mitwicki Robert Mitwicki

Part 3: The Mesaĝkesto

Part 3 of the series. If identity carries its own proof, the thing that stores your messages has very little left to do. This part is the cash-out: one envelope shape for every kind of communication, a strict order so a client's entire sync state is a single number, and the reason "give me everything after 42" beats any acknowledgement protocol ever written. Also why a box should refuse to hold your video library, and why forgetting on schedule is a feature you should want to pay for.

Read More
Part 2: Your identity is not an account
Robert Mitwicki Robert Mitwicki

Part 2: Your identity is not an account

Part 2 of the series. Part 1 claimed you can have a name nobody issued and nobody can take. This part is the construction: how you get an identifier that is unique without a registry, controlled only by you, stable for decades, and verifiable by anyone without asking an authority — and what happens the day your keys are stolen. The answer to that last one is the cleverest piece of the design, and it's why a compromise doesn't have to cost you your name.

Read More
Part 1: Messaging that doesn't need a platform
Robert Mitwicki Robert Mitwicki

Part 1: Messaging that doesn't need a platform

Part 1 of a series introducing Mesaĝkesto, a protocol for secure communication between self-certifying identifiers. Pick your favourite messenger and try to leave it — not stop using it, leave it, and stay reachable. You can't, and the reason isn't the cryptography: the thing that identifies you was issued by the service you're trying to leave. This opening part is about why every identifier we use is a lease — phone numbers, email addresses, even a domain you paid for — and what changes when the identity is yours and the service is just infrastructure holding a sealed envelope until you collect it.

Read More
HCF at PREMEDICARE: Federated Discovery for Genome-Centric OHCA Data
Philippe Page Philippe Page

HCF at PREMEDICARE: Federated Discovery for Genome-Centric OHCA Data

We are thrilled to announce the official release of Overlays Capture Architecture (OCA) 2.0.0, marking a significant milestone in our journey toward a dynamic, interoperable, and verifiable data economy. This release is the culmination of extensive community feedback, rigorous development, and successful testing of new paradigms in semantic flexibility.

Version 2.0.0 is not just an update; it is a fundamental leap forward. It transforms OCA into a more modular, extensible, and community-centric architecture, empowering non-technical users and entire ecosystems to define, share, and validate data structures with unprecedented ease and cryptographic integrity.

Read More