This post is based on a presentation that Matrix AI recently ran with EthKL on mid-2025.

If you prefer to watch a video on this content instead of reading:

Nine Circles of Digital Hell​

It started with a mundane goal: charging an electric vehicle in Kuala Lumpur. The charger was cash-less and app-only. Simple enough. But the app was region-locked, invisible to my phone. So began a domino run through modern identity spaghetti.

Downloading the app required a burner Google account on local Wi-Fi with a Malaysian IP. Registering required a local Malaysian phone number. Getting that number required physically presenting the passport for KYC at a telco shop. With the precious +60 SIM in hand, one could finally register, only to face the final boss: a credit card the app would accept. A single failure at any point in this nine-step Rube Goldberg machine, a rejected card, a bad IP, a corrupted passport scan, would have left me stranded.

This isn't an isolated incident, just a different flavor of an old chaos. In the US, opening a bank account requires proof of address, which needs a lease, which needs a visa, which needs a travel record... It's an opaque web of interdependencies navigated by trial and error, a series of buggy side-quests masquerading as official process.

This brings us to a powerful realization, captured by Stafford Beer: "The purpose of a system is what it does." This friction isn't necessarily a grand conspiracy; it's the emergent outcome of institutional incentives that favor control over access. The system isn't broken, it's just not designed for you.

This leads us to a foundational error in how we conceptualize risk. We've been conditioned to think about it like an actuary, but we're facing problems that demand a systems engineer.

Actuarial, insurance-based thinking makes sense when risks are uncorrelated. An insurance company pools surplus capital to cover isolated house fires because it's statistically unlikely that every house will burn down at once. But what happens when the risk is systemic? What happens when a wildfire tears through the entire state, a flood submerges the whole city, or a bug in a core smart contract library is exploited? The model collapses.

In a systemic event, everyone's house burns down at the same time. The insurance company goes bankrupt. There is no surplus large enough to cover a system-wide failure. You cannot insure against this kind of risk; it must be engineered out of the system from first principles. Yes, re-insurance pools and state guarantees soften the blow, but even these schemes buckle when correlations hit 1.0. Therefore systemic risks require defense-in-depth and modular isolation that prevents cracks from propagating (exactly the principles upon which Polykey is built on), like the grain boundaries in a steel beam. It's a problem of materials science, civil engineering, and rational policy, not financial statistics.

Yet, this flawed, actuarial mindset has infected everything. We have begun to substitute spreadsheets for steel. We see the same tragic pattern in our healthcare system, which excels at financing intervention but fails at engineering prevention. Instead of engineering resilience, we buy insurance, trading structural integrity for a financial abstraction. It's a societal moral hazard that makes us feel safe while leaving us catastrophically vulnerable.

This is the Great Symbolic Drift. Our L1 systems, the abstract symbols of identity, credit, and risk have become dangerously untethered from the L0 material and engineering reality they are supposed to represent. We're living in a castle of abstractions built on foundations of sand, and the tide eventually comes.

The Panopticon, The Passkey, and The Security Theater​

The castle of abstractions we critiqued isn't just an academic problem. It has real, sharp edges that define our relationship with power in both the public and private spheres. That flawed, actuarial mindset doesn't just produce brittle systems; it produces systems designed for control and liability-shifting, not resilience. Let's examine the two major fronts where this battle for your sovereignty is being waged.

The Human Front: When Your Phone Becomes a Leash​

Do you own your identity? If you think having some crypto makes you sovereign, you are in for a ride. Identity is far more than money; it's who you are, who you represent, and your license to exist in the digital world. And right now, you don't own it.

The primary instrument of this dispossession is your mobile phone number. It has become the de facto global identity anchor, the "hot identity" more operationally significant than your passport. Each time a service demands your phone number, they shackle you to a state-controlled system. The passport scan for that SIM card, the video of your face for that new app, it's all part of a very bad deal.

The hidden logic is: "Our identity infrastructure is brittle, so we must take ownership of your device." Because they cannot trust you, they must trust the hardware they can co-opt, the secure enclave inside the phone you paid for. Control is silently slipping from users to a public-private mesh of regulators and platform owners. You don’t feel the hand on the leash until you try to pull away.

This is why even well-intentioned advances like Passkeys become a gilded cage. They offer a smoother user experience, but their recovery paths almost always lead back to the same centralized bigtech gatekeepers Apple and Google who act as deputies, verifying you against the very government documents and phone numbers anchored the old system. The state remains the identity of last resort, and the tech giants become its willing deputies.

This centralization loads a hair-trigger. A single, silent database toggle can freeze your economic pulse, severing your access to the digital world. History shows that such triggers, once built, are eventually pulled, often in a crisis where the definition of "good citizen" becomes conveniently narrow.

The complex web of dependencies also creates systemic sovereign vulnerabilities. The architecture is so fragile that a single exploit can ripple through entire populations. When this happens, the losses are socialized onto the users, and the crisis itself becomes the justification for even more centralized control. The cycle feeds itself.

The Machine Front: The Security Theater​

This same flawed thinking in managing risk via abstraction and compliance rather than sound engineering manifests in the corporate world as "cybersecurity." The dominant model is a joke: build a perimeter, buy some "outside-in" security products, and then, most importantly, buy a cybersecurity insurance policy.

This is security theater: an expensive illusion that transfers blame faster than it patches code. The goal is not to engineer resilient systems, but to generate the paper trail necessary to satisfy auditors and insurance underwriters. Certifications like ISO 27001 and SOC 2 become legal artifacts for shifting liability, not technical guarantees of security. In this regime, large organizations don't engineer cybersecurity; they perform compliance.

This security-by-obscurity game is already failing catastrophically against human attackers. Now, consider the coming Cambrian explosion of non-human actors. The "secret sprawl" of API keys, tokens, and certificates for cloud services, IoT devices, and autonomous AI agents is growing exponentially. A compliance checklist cannot govern a fleet of collaborating AI agents. The outside-in, compliance-driven model will not just bend in this new reality; it will shatter. The systemic vulnerabilities being created right now are ticking time bombs.

A Builder's Manifesto: From First Principles to Anti-Fragile Trust​

So, what can we do? This is not a lamentation; it is a call to create. It's a call to build technology that doesn't dispossess people, armed with a clear-eyed understanding of what all centralized entities ultimately want.

Before we can build, we must first define our terms. We must ask the most fundamental question, the one these brittle systems get so catastrophically wrong:

What is identity?

It is not a record in a database.

It is not an ID card.

It is not a symmetric or asymmetric key.

It is not a biometric template.

These are all just instruments. Brittle, static, forgeable instruments.

Your identity is a social relationship. It's a dynamic social process, not a static anchor. True, resilient identity is a social fact, a dynamic consensus among those who recognize you as a continuous process through time.

Once you understand this, everything changes. The absurdity of the current system becomes painfully clear. Why is bootstrapping an identity when you cross a border such a strange, friction-filled process? It's because the system is trying to map a static, instrumental credential (your passport) onto a dynamic, living reality. It will always be frustrating.

With this correct first principle in mind, the engineering requirements for a truly sovereign system become obvious. As a team, these are the principles that have guided our work. Let's use Polykey as an inspiration, as a case study in how to build from this foundation.

Principle 1: Verifiable Memory​

If identity is a social process that unfolds over time, then we need a way to reliably record its history. To build real trust, we must all have a stake in the observation of reality. A centralized database is not a shared memory; it is a liability, a tool for the powerful to rewrite history.

We need a new primitive. This is why Polykey is built on sigchains: per-node, user-owned, append-only ledgers of cryptographic claims. They are not just static logs, but composable, portable records of your digital relationships and delegated authority. They are designed to make security a first-class, programmatic concept from the ground up.

Principle 2: Pluralistic Sovereignty​

If identity is a social consensus, then its recovery must also be social. The idea that you can be "deleted" because you lost a single instrument like a key, a phone, or a password, is an engineering failure born of a philosophical mistake. Resilience demands pluralism.

A sovereign system must therefore be recoverable through social consensus. This is why Polykey's architecture is built for social recovery, where a quorum of designated peers can collectively attest to restore a lost identity. Polykey's social graph called the Gestalt Graph recovers the individual node. (When all the Gestalt Graphs are put together, we create a Decentralized Trust Network) This is crucial because, as we'll see, even the strongest physical anchors can be lost. If we allow ourselves to be atomized into disconnected nodes, we become disposable cogs in a machine.

Principle 3: The L0 Anchor​

To prevent the symbolic drift we’ve talked about, our digital systems need a provable, cryptographic link back to material reality. A social graph, no matter how resilient, needs a grounding in the physical world to prevent symbolic drift. Our answer to this "bits-to-atoms" problem is the concept of a Polykey Anchor.

This tethers L1 claims to L0 material facts. Building this at scale means working within the tightly-cartelized secure element ecosystem today, while paving the road toward verifiable, open hardware supply chains for tomorrow. True sovereignty requires it.

The Path Forward: An Asymmetric Strategy​

Critique is not enough. We must build.

But we cannot fight the incumbent identity stack head-on; that's a battle of attrition we would lose. Our strategy must be asymmetric. We must find the cracks in the system, the points of leverage where a small force can produce an outsized effect.

For identity, the most potent maneuver is to Overlay and Invert.

You don't try to replace the existing rails overnight. Instead, you first build an overlay that is compatible with them. For initial onboarding, you accept the legacy credentials: the phone numbers, the emails, the passports. This minimizes friction and allows you to gain a foothold.

But here is the critical move, the point of leverage where the inversion happens. Your new layer must offer a more trustworthy, more portable, and fundamentally more resilient recovery mechanism.

Control of recovery is control of the root.

The legacy anchors are demonstrably broken. Email accounts get locked. Phone numbers are vulnerable to SIM swaps. Passports are useless for day-to-day digital recovery. When a user's new sovereign identity that is anchored by social consensus and a physical key becomes the most reliable way for them to recover their digital life, it becomes their true root of trust. Users and platforms will migrate to it, first for recovery, then for everything. At that point, the inversion is complete. The phone number and the passport are demoted to mere attributes attached to your new, sovereign anchor.

This is how we build systems that empower, not dispossess.

Thanks to EthKL for Hosting​

This post is a crystallization of a presentation and, more importantly, a conversation I had the privilege of sharing with the EthKL community. The energy in the room was palpable, a clear sign that we are not alone in wrestling with these foundational problems.

The discussion that followed the talk was as illuminating as the presentation itself, quickly diving into the hard questions and exciting possibilities that arise from these ideas. I wanted to share a few of the key themes that emerged, as they point toward the collaborative work that lies ahead:

• The Abstraction Chasm: We had a great discussion tracing the line from object-capabilities to serialized tokens like JWTs, and a shared realization emerged: current tools create a "first-order box problem." When faced with managing too many granular permissions, users and developers alike give up and default to grant ALL. This highlighted the deep need for a higher-order abstraction: a programmable, first-class concept of authority, touching on ideas from Datalog to modern knowledge representation, that can be composed and delegated safely.
• Grounding The Digital in The Real: The L0/L1 distinction resonated deeply. The idea that "money" is just an entry in a database that can return "user not found" was a visceral moment. This led to a clarifying discussion about the Polykey Anchor, distinguishing its role as a hardware-based proof-of-action from a simple authentication tool like a Passkey. The Anchor's purpose is to tether the digital world to an undeniable physical event, and its irreplaceability is precisely what makes the social graph recovery mechanism a non-negotiable part of the architecture.
• Pragmatic Paths to Adoption: The conversation naturally turned to strategy. "How do we fight the incumbents head-on?" was revealed to be the wrong question. A more nuanced discussion about the Overlay and Invert strategy unfolded, focusing on pragmatic, asymmetric entrypoints. The consensus was that the most viable path is to first establish a beachhead in "greenfield" areas where legacy identity solutions are weak or non-existent, proving the model's resilience there before challenging the core human identity space.
• The Hardware Foundation: Finally, the discussion kept returning to a fundamental truth: software-only solutions do not grant full sovereignty. A system's claims can only be truly guaranteed if the hardware it runs on is verifiable. The group acknowledged that a long-term vision for anti-fragile trust must include a path toward verifiable, open hardware supply chains.

It's these kinds of conversations that transform ideas into movements. My deepest thanks to the organizers and attendees of EthKL for providing the forum.

If these questions and challenges excite you as much as they excite us, the conversation is only just beginning. Join us as developers, partners and pioneers building out this new Polykey substrate of trust.

From news organizations to schools to user-generated content platforms, they are all clamoring for solutions to detect artificially generated content. So how do we prove what's real anymore?

This has led to the emergence of numerous startups and tools aiming to identify AI-generated text, images, audio, and video. As of March 2025, examples include GPTZero, Copyleaks, Decopy AI Detector, Scribbr AI Detector and more...

Some of these solutions claim 99% accuracy (until they quietly roll that number back after real-world tests). Others take the security theater approach, offering expensive enterprise solutions that amount to a probabilistic guess wrapped in a glossy UI.

AI Detection is a Waste of Time because it Does Not Scale​

The problem is that AI detection is an arms race that cannot be won. The moment detectors improve, generative AI adapts to evade them. Both are trained using the same fundamental techniques, ensuring that detection will always be reactive rather than proactive. Since AI detectors rely on past data to recognize patterns, they can only flag content that fits known characteristics of AI generation. Meanwhile, AI models can continuously evolve to eliminate those characteristics, rendering previous detection methods ineffective.

This is the core dynamic of Generative Adversarial Networks (GANs): a continuous back-and-forth where detection improvements directly drives the refinement of generation techniques. Every time AI detection advances, it introduces new challenges for AI developers to overcome. Previously detectable traits, such as unnatural textures or irregular text coherence, disappear in newer model iterations. Detection benchmarks become part of the dataset for training next-generation AI, making forensic methods quickly obsolete.

Research in Adversarial AI has demonstrated how easily deep learning models can be fooled by minor modifications to input data. Small, imperceptible pixel changes can cause classifiers to misidentify an image. A well-placed sticker on a Stop sign can trick an AI into reading it as a Speed Limit sign. The same principle applies to AI-generated content, once detection models are publicly available, they serve as a benchmark for evasion.

For AI detection to stay ahead, it would need to anticipate and classify future AI-generation techniques before they exist, which is computationally infeasible. The space of possible AI-generated outputs is too large, and there is no fixed "fingerprint" of AI content that detectors can reliably target. Any pattern a detector identifies can be removed in the next model iteration. More aggressive detectors risk misclassifying human-created content, while more conservative ones become ineffective against rapidly evolving AI. This tradeoff between false positives and false negatives makes AI detection an unreliable long-term solution.

Ultimately, AI detectors are locked in a perpetual defensive position, always reacting to new developments rather than preempting them. Every detection breakthrough feeds directly into the next generation of AI, strengthening it. The fundamental asymmetry between AI detection and generation ensures that detection will always be one step behind.

Relying on AI Detection Creates a Problem of Trust​

Even if AI detection were effective, it raises a deeper issue: trust. Who controls these detection systems? Who verifies their accuracy? AI detection models function as opaque black boxes, making unverifiable claims about content authenticity. They just provide a probabilistic output that users are expected to trust. If an AI model flags a piece of content as artificially generated, how does someone challenge that claim? What recourse is there for those falsely accused of using AI-generated content? Without transparency or an independent verification mechanism, AI detection creates a new layer of authority that operates without accountability.

This problem extends beyond misclassification. If platforms rely on AI detection to filter or moderate content, it places significant power in the hands of whoever controls the detection models. AI detection can be abused, whether intentionally or as a side effect of systemic bias. If an AI classifier is treated as an arbiter of truth, it can be used to flag inconvenient content, silence dissent, or falsely discredit legitimate material. We've already seen real images being wrongfully flagged as AI-generated, raising concerns about false positives in high-stakes scenarios. This risk grows when platforms and governments start relying on AI detection at scale, as the ability to challenge an incorrect classification becomes nearly impossible.

This centralization of authority on what's real and what's not introduces a new failure mode: what happens when the detection system itself is wrong? If detection models are treated as infallible, their mistakes become indistinguishable from deliberate manipulation. A flawed detection system doesn't just misclassify content, it creates an environment where authenticity is dictated rather than demonstrated. If a system cannot be challenged or independently verified, then it cannot be trusted as a solution to the problem it claims to solve.

Cryptographic Provenance is the Only Solution​

Cryptographic provenance offers an approach fundamentally different from AI detection, it does not attempt to guess whether something is real or fake but instead provides verifiable proof of origin. Unlike probabilistic classifiers, cryptographic provenance ensures that content can be traced back to its source in a way that is independently verifiable and tamper-proof.

Cryptographic provenance is based on digital signatures and cryptographic hashing. When a piece of content such as an image, video, or document is created, a cryptographic hash is generated. This hash is a unique fingerprint of the content, which changes completely if even a single pixel or letter is modified. The hash is then signed by a trusted entity, such as the camera, software, or organization capturing the content. This signature proves that the content was recorded or created at a specific point in time and has not been altered since.

Because cryptographic hashes are computationally infeasible to forge, they provide strong guarantees of authenticity. Unlike metadata, which can be easily edited or removed, cryptographic provenance is tied directly to the content itself. This allows anyone to verify the integrity of a file without relying on a centralized authority. If a file has been modified, its cryptographic hash will no longer match, making tampering immediately detectable.

One of the most widely adopted provenance solutions is the Coalition for Content Provenance and Authenticity (C2PA), an initiative backed by Adobe, Microsoft, Intel, and Google. C2PA embeds cryptographic metadata into media files at the point of creation, recording details such as the source, timestamp, and any modifications made to the content. The goal is to enable verification of images and videos by checking their metadata against a trusted ledger of provenance records.

While C2PA represents a step toward verifiable media authenticity, it has limitations. The most immediate issue is that metadata can be stripped. A file signed with C2PA provenance can be downloaded, altered, and re-uploaded without its original metadata, making verification impossible. Many platforms already strip metadata by default for privacy reasons, and unless every major platform enforces C2PA metadata retention, unverified copies will continue to circulate.

Another limitation is that C2PA does not verify whether the content was manipulated before it was recorded. If an AI-generated deepfake is signed at the moment of creation, it appears just as authentic as real footage. Provenance alone does not determine truth, it only tracks the history of a file, not whether the content itself is genuine.

Beyond technical concerns, cryptographic provenance runs into a broader issue: centralization. For provenance systems like C2PA to be widely adopted, they rely on a small number of trusted organizations to issue and verify content signatures. This creates a single point of control over what is considered "authentic." If a handful of companies act as gatekeepers for verification, they have the power to dictate which content is considered real and which is not.

This introduces the same risks as AI detection: censorship, misclassification, and manipulation. If platforms or governments require provenance verification for content distribution, content without cryptographic signatures could be devalued or even suppressed. A centralized verification system does not eliminate misinformation; it simply shifts control over authenticity from AI classifiers to a small group of organizations.

Cryptographic provenance is an important step toward solving the problem of digital authenticity, but its implementation matters. If verification remains centralized, it risks becoming another authority-based system where trust is dictated rather than independently verifiable. The challenge is not just proving where content comes from, but ensuring that no single entity has the power to control what is considered real.

Introducing a Decentralized Trust Network​

Centralized provenance systems, like C2PA, introduce a single point of control over what is considered "authentic," making them vulnerable to manipulation and censorship. A Decentralized Trust Network (DTN) solves this problem by distributing trust across independent participants rather than concentrating authority in a handful of entities.

A DTN does not rely on metadata embedded within content, which can be easily stripped or altered. Instead, it allows content authenticity to be claimed on a distributed ledger, ensuring that provenance remains verifiable even if the original file is modified or reuploaded. More importantly, DTNs recognize that truth is not absolute. It is socially constructed. Authenticity should not be dictated by a single gatekeeper but established through multiple independent claims that can be corroborated, challenged, and verified.

Polykey's Decentralized Trust Network (DTN) is designed to provide cryptographic verification of content while avoiding the pitfalls of centralized control. It achieves this through cryptographic fingerprints, independent Polykey nodes that store and verify trust data, and Gestalts, trust collectives that allow for flexible, socially or institutionally scoped verification. Unlike traditional blockchains, Polykey's DTN does not require slow or energy-intensive consensus mechanisms. Instead of securing financial transactions, it is optimized for verifying authenticity efficiently through cryptographic signatures and peer validation. This makes it scalable while eliminating unnecessary computational overhead.

A DTN ensures that content's existence and integrity are verifiable, but it also establishes who created it and whether it has maintained its integrity over time. This is achieved through Signature Chains (SigChains), which form the backbone of Polykey's DTN. Each Polykey node maintains its own SigChain, where all claims are automatically signed by the node’s own authority, creating an immutable cryptographic record of attestations that can be independently verified.

Because all nodes in the DTN are part of a Gestalt, SigChains inherit the real-world identity associations of the Gestalt itself. Gestalts are cryptographically linked to external digital identities such as Instagram, X, Facebook, Nostr, or other third-party verification sources. This means that when a Polykey node issues a claim, it is not just a detached cryptographic assertion, it is rooted in a broader web of trust, where multiple independent entities corroborate authenticity. This structure enables trust delegation without centralizing control, ensuring that verification remains distributed while allowing for real-world accountability.

Polykey's DTN recognizes that truth is often socially determined. The current media landscape prioritizes speed over accuracy. News outlets, influencers, and platforms rush to publish first, even if the information is later retracted. By the time corrections are issued, the impact has already been made. A decentralized trust network shifts this dynamic by incentivizing accuracy over speed. SigChains allow multiple independent authorities to make corroborating claims on reality, supported by verifiable content. This creates a reputation-based system where those who stake their trust on false claims suffer credibility losses, reducing the incentive to publish misleading or inaccurate information. Unlike traditional provenance models, which rely on static metadata, Polykey's DTN enables a more dynamic and robust system of truth verification.

The key lesson here is that it doesn't actually matter whether content is AI-generated or not. What matters is the underlying truth claim that the content represents. AI-generated media is not inherently false, just as human-created media is not inherently true. A deepfake can be labeled as such while still being a valid satirical expression, and an unedited video can still be used out of context to mislead. The problem is not how content is created but what it claims to represent. This is why focusing on AI detection is the wrong problem. Provenance is not about filtering AI out of the conversation but about ensuring that claims about reality can be verified in a decentralized and accountable way.

Polykey's DTN is more than just a cryptographic provenance system. It represents the next phase of decentralized authority management. While Polykey began as a system for managing digital secrets and access control, the same principles of distributed trust apply to content authenticity, identity verification, and broader claims about reality. In a world where AI-generated content is becoming indistinguishable from reality, we need a trust system that is verifiable, resilient, and independent of centralized control. The future of digital trust is not about fighting AI, but about creating systems that allow us to verify the truth, no matter how it is expressed.

For example, giving an employee a key to an office containing confidential documents bears similar risks to granting users access to sensitive databases. Delegation requires trust, but trust introduces risk.

At its core, delegation involves three key elements:

1. Authentication - Assigning Authority Choosing who receives decision-making power.
2. Authorisation - Defining Scope Setting limits on what they can and cannot do.
3. Accounting - Implementing Oversight Ensuring accountability and preventing misuse.

Here are 2 simple examples:

• A front desk worker can operate a Point of Sale register but cannot issue refunds above a set limit.
• A soccer referee can eject a player for a foul but cannot ban them from the league.

The same principle applies in digital systems, unnecessary access increases vulnerabilities, while restricting access too much slows productivity.

Delegation always involves a trade-off between trust and control:

• Too little authority - Tasks remain incomplete.
• Too much authority - You introduce risks of potential compromise either due to maliciousness or accidents.

Here are some examples of when there's too little authority:

• A receptionist must ask a manager for every patient update.
• A developer can't deploy code, delaying releases.

Here are some examples of when there's too much authority:

• A junior employee is mistakenly given admin access to a database.
• A cashier can issue refunds without oversight, leading to fraud.

The Principle of Least Privilege (POLP)​

To minimize risk, organizations follow POLP: "Give people only the minimum necessary authority to complete their tasks—no more, no less."

Most systems that enable delegation ends up granting more power than necessary, leading to ambient authority. These are the extra permissions that aren't strictly needed.

In the above diagram, we show that ambient authority is the extra authority someone has but doesn't need. Whereas the intended authority is the exact amount of power necessary for a task. Therefore reducing ambient authority reduces risk. This is the foundation of Zero Trust and this is something we will explore in subsequent blog posts.

Delegation is essential, but it requires careful management to avoid inefficiencies and risks. The key is to balance trust and control, ensuring authority is assigned wisely and responsibly.

Centralized platforms can make use decentralized capabilities to gate features within their systems. For instance, Clarity.so has introduced token-based roles and permissions, allowing users to unlock features based on their possession of decentralized tokens. Similarly, platforms like Luma use NFTs to gate events, requiring attendees to hold specific tokens in their wallets for access. Below is an example of how Luma implements token gating for event registration:

Why would centralized platforms open their security systems to the public blockchain? There could be benefits similar to why certain systems use "login via social network". The cost of implementation can be decreased, while leveraging pre-existing identity structures reduces the friction of onboarding for customers. Therefore at the same time, using NFT capabilities or fungible capabilities is way of leveraging a network effect of other public authority systems on the blockchain.

There are several problems with relying on NFTs as your permission system:

• Delegation of authority requires a transaction on the blockchain will cost some unit of energy.
• The authority structure is being revealed publically and this may not be suitable for privacy.
• The blockchain is being polluted with information that's only relevant to a subset of users.
• During high congestion, the cost to delegate will increase even more.

Before NFTs, tokenized capabilities existed in the form of JSON Web Tokens (JWTs). JWTs are self-contained bearer tokens, possessing the JWT as a string equals possessing the permission. This means the security of JWTs depend on the issuing system and the bearer system to securely manage the shared secret.

An example of JWTs in centralized systems are magic links. These magic links are a convenient way to grant temporary access to resources. However, using these links relies on out-of-band communication, potentially exposing the secret over insecure channels.

It is possible to avoid the problem of preventing exposure by changing the way ownership of the permission is expressed. Rather than simply bearing a secret token, the token can instead embed a claim that a particular identity has an authority. Then this is combined with a proof of authority that can be checked. The simplest proof is where the token is signed by a trusted authority, and the signature can be checked to be genuine. The user/program attempting access has to also prove that they are in fact the identity expressed within token claim. This can be achieved with the user/program's own signature.

Signed JWTs add a layer of asymmetric authority through a cryptographic signature from a trusted entity. This model doesn’t rely on decentralized consensus but rather on the trustworthiness of the signature’s authority. This makes it more flexible and scalable than NFTs but shifts security onto the reliability of the signing authority. What this means is that security of the signed JWT does not rely on secrecy. In Polykey, for example, signed JWTs could be made public to the network via the sigchain module.

In the signed JWT case, delegation of authority is not a simple matter of sharing a token. A derivative token must be minted that extends the authority to another identity.

A signed JWT doesn't have to be public, it can still be transferred secretly over secure channels, it just not catastrophic if it were exposed. However there could be benefits to public attestation to claims just like NFTs on a public blockchain.

Polykey enables the ability to manage both tokenized authorities such as JWT shared secrets and capabilities expressed through signed JWTs by creating a secure highway of authority. In scenarios where a more decentralized approach is needed, Polykey could integrate with Ethereum to mint NFTs representing access capabilities. These NFTs would be transferrable and verifiable through the blockchain enabling integration into further decentralized resources or centralized platforms relying on these public blockchain capabilities.

Polykey is also exploring the concept of federated tokens that operate across multiple domains or blockchains. These tokens could combine the best of both JWTs and NFTs, offering fine-grained control over permissions in a decentralized environment. Recent developments in Polykey, such as enabling nodes to access private networks through cross-chain interactions, underscore the potential for a federated trust model. By allowing nodes to issue and validate tokens across different networks, Polykey could create a scalable, flexible system for managing decentralized authority.

The issues Polykey#779 and Polykey#770 in our Polykey GitHub repository tracks our work on network segregation and authentication token logic. These developments are critical in ensuring secure and seamless access to private networks, enabling Polykey nodes to authenticate and operate within various isolated environments while maintaining decentralized integrity.

Enforcing policy across decentralized systems is challenging, especially when dealing with nodes not fully under central control. While decentralized networks offer resilience and flexibility, they also open the door to potential rule violations by nodes that may have been modified or corrupted. In Polykey, this challenge is addressed by leveraging its sigchain and decentralized architecture to ensure all nodes adhere to network policies. However, the need for full stack control becomes apparent when dealing with potentially rogue nodes that could hide unauthorized activities.

The convergence of NFTs, JWTs, and federated blockchains offers a tantalizing glimpse into the future of centralized and decentralized authority. By combining these technologies, we can create more resilient, scalable, and flexible systems for managing identities and permissions across multiple domains. As we explore these possibilities with Polykey, our goal is to create interoperable tokens that leverage both decentralized consensus and trusted authorities, paving the way for a new era of decentralized trust infrastructure.

Future discussions may focus on what it means to have a global ACL system where some kinds of access-control is mediated through the blockchain rather than ad-hoc trust networks between centralized platforms.

The public key identifiers are decentralized and secure, but they aren't human meaningful. This makes it difficult to find your friend's NodeIds.

Traditionally establishing a web of trust between these NodeIds without a centralized registry involved cryptographic key-signing parties in dimly lit back rooms of tech conferences—hardly accessible to your everyday internet user.

But what if we could skip the awkward small talk and instead tap into platforms where people already feel at home, like social networks?

Keybase discovered that social networks could serve as discovery focal points for discovering decentralized identities. Most people already trust these platforms and are familiar with how they work.

The idea is simple: users can post a cryptographically signed claim, or what we call a "cryptolink" on their social network profiles. This post, publicly accessible and searchable, serves as a verifiable claim that links their social network identity to their decentralized Polykey NodeId. As long as the social network provides APIs for posting and searching, it can be integrated into Polykey.

However, there's a hitch. Social networks are increasingly closing off their platforms, limiting API access for posting or searching content. This trend forces us to either adapt by using manual methods or restrict the range of supported networks. For instance, manually posting a cryptolink might involve copy-pasting a generated message, while manually searching for someone else's cryptolink could become a scavenger hunt. But with a unique link, the process remains feasible, even if less automated.

By using a platform like Polykey, users can discover the NodeIds of their friends or acquaintances directly through social networks. This approach doesn’t just democratize access to the web of trust; it makes it practical and intuitive. Unlike our inspiration, Keybase, Polykey does not maintain a centralized registry of cryptolink claims. The claims are simply replicated on each Polykey node's sigchain.

Do note that using these centralized social networks is entirely optional. Polykey does not depend on them. Any social network can be used as a discovery point, including your IRL key signing party.

Currently, Polykey integrates with GitHub, allowing developers to leverage their GitHub identities in the web of trust. We’re eager to expand this to other platforms and encourage contributions from the community. Given the nature of Polykey, future integrations will likely involve WebAssembly (WASM) plugins, offering flexibility and performance across various platforms. Decentralized identity platforms, particularly those using blockchain-based identifiers (DIDs), are tailor-made for this. They align perfectly with the principles of decentralized trust and provide a robust foundation for identity verification in the web of trust.

The potential here extends far beyond just identity verification—it could lead to advanced trust metrics, scoring systems, and even a marketplace for trust. The integration of social networks with decentralized identity systems represents a significant leap forward. It makes the web of trust more accessible and practical, moving it out of niche tech circles and into the broader internet community.

Polykey: Elevating Security and Efficiency​

Polykey fundamentally transforms how environment variables and secrets are managed, moving beyond traditional .env file approaches to a more secure and robust system. Unlike .env methods that often expose sensitive data in plaintext, Polykey entirely separates secret management from the codebase. This separation ensures that sensitive information is never stored alongside code or within project repositories, which dramatically reduces the risk of accidental exposure.

Advanced Encryption and Secure Management​

Polykey leverages the XChaCha20-Poly1305-IETF encryption algorithm, implemented through the Libsodium library, to secure secrets at rest and in transit. This modern cryptographic approach offers several benefits:

• Extended nonce size: Enhances security by enabling the safe reuse of encryption keys in various contexts without risking nonce collisions—crucial for dynamic and distributed applications.
• High performance: Designed for high-speed encryption and decryption processes, ensuring minimal impact on performance while maintaining robust security.
• Robust confidentiality and authentication: The algorithm guarantees that secrets remain confidential and verifiable, which is critical when handling sensitive operational data.

Enhanced Collaboration and Sharing​

Polykey also facilitates secure end-to-end encrypted sharing of secrets, ideal for collaborative environments. When developers need to share environment variables or other configurations:

• Secure Sharing: Instead of sharing secrets over insecure channels or cumbersome setups, developers can share directly through Polykey’s encrypted vaults.
• Seamless Integration and Execution: Shared vaults can be directly integrated into another developer's local environment. Once a vault is copied to their node, they can immediately execute scripts or applications using the shared environment variables without further setup. This capability not only simplifies workflows but also ensures that all team members work with secure, up-to-date configurations without manual updates or risky data handling.

By eliminating reliance on .env files and integrating these advanced features, Polykey significantly enhances the security posture of application deployments. It addresses common security challenges associated with environment variable management and sets a new standard for secure, efficient, and collaborative development practices.

Applicability Across Programming Languages​

Currently, Polykey's native support extends to JavaScript, TypeScript, and Node.js environments, which commonly utilize .env files managed by respective dotenv libraries. For other programming languages, interaction with Polykey is facilitated through standard IPC, as direct RPC interactions are limited to JS/TS/Node applications. For more details on library usage, refer to the npm library @matrix/rpc.

Demonstration of Polykey's Capabilities​

I created a GitHub repository to demonstrate the practical implementation and performance comparisons of replacing the traditional dotenv method with Polykey for a simple Node.js weather app. This showcases how Polykey can be effectively implemented in various environments where dotenv libraries are used. I encourage others to explore these demonstrations and consider similar implementations to witness the benefits firsthand. Follow the instructions in our README to perform the demo yourself, or view our detailed breakdown of the configurations and performance results of the dotenv-to-Polykey transition here.

Future Directions and Call to Action​

Currently, Polykey is optimized for development environments with plans to extend its functionality to production settings. This ongoing development promises to make Polykey a comprehensive solution for all stages of development, setting a new standard in the industry.

Conclusion: Join the Conversation and Shape the Future​

We invite developers from all backgrounds to join this transformative journey by testing Polykey in your development environments and sharing your insights with us in our discord server. Your feedback is invaluable as we refine this tool into an industry standard. Stay informed on our developments for Polykey by following our open-source GH organization.

In the realm of software development, managing environment variables and secrets has long been both a necessity and a challenge. Traditional practices, particularly the use of .env files facilitated by the dotenv library, have been fundamental in helping developers manage configurations without hardcoding them into their applications. These practices expose systems to security breaches, unauthorized access, and accidental exposure of sensitive data, vulnerabilities that can no longer be overlooked in today’s security-conscious environment.

Polykey is introducing a new open-source solution that enhances security, simplifies workflows, and integrates seamlessly into diverse development environments, addressing the urgent need for secure management of environment variables and secrets.

The History and Challenges of .env Files​

Environment variables are crucial in bridging the gap between operating systems and applications, managing sensitive data such as API keys and database passwords. Traditionally managed through .env files, these variables are vulnerable to several significant risks:

• Accidental Exposure: .env files can easily be committed to version control by mistake, even when listed in .gitignore.
• Plaintext Storage Vulnerabilities: Susceptibility to breaches if unauthorized access to the developer's machine occurs.
• Insecure Sharing Practices: Growing teams often resort to insecure methods to share sensitive information.
• Management Complexity: Scaling issues and key rotation complexities create inefficiencies and potential for errors.

Introducing Polykey​

Polykey is revolutionizing secret management by moving beyond traditional .env files and other less secure cloud-based secret management solutions. As a robust CLI tool, Polykey introduces:

• Encrypted Storage: Polykey securely stores each secret within encrypted vaults on the user's local machine, enhancing data confidentiality and control over secret management.
• Dynamic Injection: Through commands like polykey secrets env -e=<vaultname>:<secretPath>, Polykey injects secrets directly into the development environment on-demand, offering flexibility and minimizing risks associated with static secret storage.
• Decentralized Secure Sharing: Utilizing an encrypted, peer-to-peer network, Polykey enables seamless and secure sharing of secrets. This mechanism is crucial for collaborative projects requiring stringent security measures, allowing nodes that manage vaults to discover and trust other users' nodes across decentralized environments.

Step-by-Step Example: Using Polykey’s env Command​

Experience Polykey's secrets env command in action through this GIF demo, showcasing the secure and dynamic management of environment variables, transitioning from traditional .env files to a more robust approach.

Overview of the Demonstration​

This demonstration captures the following key actions and highlights their significance:

• Transition from .env Files: We start by navigating to the project directory, displaying the existing .env file, and then removing it. This visual representation not only underscores our departure from relying on less secure .env files but also reinforces Polykey’s capability to replace them with a more secure alternative.
• Secure Storage of Secrets: By creating a new vault and adding secrets directly into it, the demo showcases how Polykey encrypts and securely stores each secret locally on the user’s machine. This action highlights the enhanced security measures Polykey offers compared to plaintext storage in .env files.
• Dynamic Secret Injection: Entering into a secure, delegated subshell where secrets are dynamically injected on-demand exemplifies Polykey’s core functionality. This step is critical as it demonstrates the operational efficiency and security with which developers can now handle sensitive information, ensuring that secrets are only accessible when and where they are needed, without being exposed.
• Verification of Configuration: The final step of verifying configurations within the AWS CLI using the dynamically injected secrets illustrates the effective application of Polykey in a real-world scenario. It not only validates the correct functioning of the environment setup but also confirms that the secrets management process adheres to best security practices.

Significance of the Demonstration​

This demo serves as a potent illustration of Polykey’s capabilities in transforming secret management within development environments. It highlights the ease of transitioning to Polykey, the security benefits of encrypted storage, and the operational advantages of dynamic secret injection. By visually and practically demonstrating these features, the demo helps developers understand the immediate benefits of adopting Polykey, encouraging them to reevaluate and enhance their current secrets management strategies.

Try Polykey Yourself​

Following the demonstration, we encourage you to explore Polykey's capabilities further:

1. Download and Install Polykey: Follow our installation guide to get started.
2. Watch the Demo: View our demo video that will cover some of the basic commands for using polykey.
3. Try It Out: Experiment with the polykey secrets env command in your own development environment.

We are eager to hear your feedback and encourage you to join our Discord server to participate in discussions or contribute to Polykey’s ongoing open-source development at Matrix.AI.

It’s been some time since our last major update—the beta launch back in November. Our Sydney-based engineers have been hard at work enhancing the Polykey CLI and adding powerful new features. Matrix AI has undergone a few exciting changes that will significantly impact the company's growth and the development of Polykey.

Here’s what’s new:

Latest Enhancements​

• Cross-Platform Installation: In addition to Linux, Polykey CLI is now available on Mac and Windows. For detailed installation instructions based on your operating system, check out our updated installation guide in the Polykey Docs. (Polykey-CLI#152)

• CLI Standard Output Improvements: We've standardized CLI outputs across all interactions to ensure a consistent user experience. (Polykey-CLI#22)

• Advanced Monitoring with Audit Domain: We're advancing our monitoring capabilities to offer improved visibility and control. (Polykey-CLI#177)

• Optimized Node Discovery: Enhanced feedback mechanisms in node discovery improve network operations and independence. (Polykey#162)

• Secure Environment Handling: The $ polykey secrets env command securely injects environment variables from your encrypted vault directly into your system's local environment. This feature sets a new standard for secure data management both at rest and in use. Excited to share more about this feature's use-cases soon. (Polykey-CLI#31)

• Fault-Tolerant Notifications: Experience asynchronous notifications, enhancing system responsiveness and fault tolerance. (Polykey#703)

Critical Bug Fixes​

• Connection Stability: We've fortified network stability to prevent unexpected node crashes. (Polykey#592)
• Authentication Enhancements: Increased the Authentication Timeout window, improving user experience during the authentication process when running $ polykey identities authenticate github.com. (Polykey#588)
• Resource Leak Fix: Fixed issue with timers not properly cleaning up, preventing potential crashes. (js-timer#15)
• Node Discovery Overhaul: Decentralized node discovery now improves overall network connectivity. (Polykey#618)
• NAT Hole Punching Fix: Addressed challenges with NAT hole punching to ensure consistent node communications. (Polykey#605)

Recent Events & Organization Updates​

• Key Hires and Team Expansion: Recent months have seen exciting additions to our team, enhancing both our technical and marketing capacity. New roles include front-end engineers, back-end engineers, AI/ML specialists, and a marketing lead technical support specialist.
• Polykey Enterprise Development: We are actively enhancing Polykey Enterprise (PKE) to provide a hybrid mandatory discretionary policy network, allowing admins to enforce security policies robustly. We applied to YCombinator Summer 2024 to accelerate this development. We have some GUI prototypes in the works for the PKE which we're eager to share with you soon.
• Venture Miami Phase II: We're making waves in Phase II of Miami's largest incubator program, gearing up for a demo day on June 20th that promises to showcase our advancements to potential angel investors.
• Engagement at Major Events: Our participation at Eth Denver and SXSW in Austin has significantly expanded our network and fostered key collaborations.

Engage and Explore​

We’re eager to hear your feedback as we continue to refine Polykey. Engage with us through feature requests or issues on our GitHub or in our Discord server.

Stay Tuned​

Explore the vast possibilities with Polykey. Download the latest updates, try out new features, and share how they've impacted your workflow.

Escape the Ordinary, Secure the Extraordinary​

The Polykey Team

Since its initial launch in December 2023 for Linux, we've expanded Polykey's availability.

As of March 2024, you can now use Polykey on both Mac OS and Windows!

Best Way to Get Started:​

Download Polykey by following the installation guides tailored to your operating system, available here: https://polykey.com/docs/tutorials/polykey-cli/installation

Explore Through Our Demo Video

Watch our demo video to see Polykey in action. The video covers basic yet crucial functionalities:

• Starting Polykey
• Creating and managing Vaults
• Adding and viewing Secrets within Vaults
• Authentication and identity features with GitHub
• Discovering and trusting other Polykey users
• Sharing Vaults securely

Special Note on the Demo: This video showcases interactions that require two separate users to demonstrate the feature of sharing vaults. While this is a key aspect of Polykey’s collaborative capabilities, remember that Polykey also offers robust solutions for individual users, such as securely managing .env files. We will explore this in more detail in an upcoming post.

We Want Your Feedback

Connect with us on our Matrix AI Discord Server to share your feedback and discuss how you use Polykey in your own setups.

On December 8, 2023, at our Sydney headquarters, Polykey was launched. The event marked a major milestone for Matrix AI after three years of intense innovation and engineering.

The event began with a presentation by Roger, Polykey's founder. He introduced Polykey's philosophy and core features, including encrypted vault storage and Gestalt-based sharing. Roger also discussed digital identities in Polykey's secret sharing infrastructure.

Next, Polykey Enterprise was previewed. It's the peak of Polykey's offerings, turning the open-source framework into a robust enterprise solution for managing and delegating sensitive information within organizations.

The event also unveiled Polykey.com and Polykey dashboards. These platforms offer real-time insights into active nodes, improving user experience and control.

As the presentation concluded, guests were invited to a meticulously arranged refreshment break.

This interlude provided a perfect opportunity for the diverse assembly of tech enthusiasts, industry leaders, and innovators to network and share insights.

After the presentations, guests enjoyed a refreshment break. It was a time for networking and sharing insights among tech enthusiasts and industry leaders.

The event continued with a presentation by Amy Yan. Amy discussed her role in developing js-rpc, Matrix AI's RPC library. She highlighted js-rpc's advanced streaming methods, including raw, server, client, duplex streaming, and unary data transmission.

The final segment featured a live demonstration by Brian Botha. He showcased the Polykey CLI client's features like vault creation, secret sharing, and a git-based log system for tracking changes to secrets. He also demonstrated how new Polykey agents are integrated into the network.

For those who could not attend or wished to revisit the demonstration, the Polykey team provided a link to the Polykey launch video, capturing the essence of the demonstration:

Polykey Launch Video:

This concluding segment of the Polykey Launch Event perfectly encapsulated the blend of technical excellence and user-centric design that Polykey embodies. It provided a tangible showcase of Polykey's capabilities, leaving the attendees with a profound appreciation of the innovation and expertise driving the Polykey project forward.

Polykey is a decentralised open-source secrets management system. It facilitates zero-trust workflows that require the sharing of secrets between individuals, teams and machines in order to coordinate the secure utilisation of digital and physical assets. It manages passwords, public & private keys, API keys, structured & smart tokens, certificates and any kind of confidential information.

Existing password management systems which focus on storing and retrieving passwords treat secret sharing as merely identity credential sharing. Secret sharing is actually about the delegation of authority, and when possible, the subdivision of authority for fine-grained least-privilege delegation. A secret tokenises the capability to manipulate a specific resource. Polykey provides interfaces and automation for structured secrets management designed for developer, security and operations (DevSecOps) oriented workflows.

Polykey is decentralised. This means Polykey nodes are deployed ubiquitously across platforms and devices (on and off-premise), eliminating third-party storage, providing end-to-end zero-trust delivery, and last-mile ingress and egress integration.

Polykey ensures that your secrets stay secret. To learn more about Polykey:

• Download the latest pre-release
• Join our community on GitHub
• Follow us on Twitter at @PolykeyIO
• Learn more by reading the Polykey Documentation
• Get ready for Polykey's launch release