Update TLSN project links and metadata

components/mastermap/tlsnotary-data.ts

@@ -16,7 +16,7 @@ export const TLSNOTARY: ProjectData = {
       name: "Proxy Mode",
       description:
         "TLS proxy that generates attestations without requiring MPC. Simpler setup, lower latency, but more trust assumptions.",
-      status: "In progress",
+      status: "In review",
       statusDot: "green",
     },
     {

content/articles/tlsnotary-do-not-pass-go.md

@@ -5,7 +5,7 @@ image: "/articles/tlsnotary-do-not-pass-go/institutions.webp"
 tldr: "To solve problems at scale, humans design systems which both encapsulate complexity and leverage specialization to achieve efficiency and predictability. This reduces the need for interpersonal trust by replacing it with systemic trust — that is, trusting the behavior of a system and not an individual. Much of societal progress can be attributed to this process of systematization, but much can also be said about the damage that is caused when the goals of these systems become misaligned, or simply when they fail to adapt to new circumstances. The modern world is increasingly characterized by both failure modes."
 date: "2026-01-01"
 canonical: "https://tlsnotary.org/blog/2026/01/01/do-not-pass-go" # (Optional) The original source URL, this tells search engines the primary version of the content
-tags: []
+tags: ["tlsn"]
 projects: ["tlsnotary"]
 ---
 

content/projects/tlsn.md

@@ -20,11 +20,11 @@ links:
   twitter: "https://x.com/tlsnotary"
 extraLinks:
   play:
+    - label: "TLSNotary Browser Extension Plugin Demo"
+      url: "https://demo.tlsnotary.org"
+  learn:
     - label: "Getting started"
       url: "https://tlsnotary.org/docs/quick_start/"
-  learn:
-    - label: "Documentation"
-      url: "https://tlsnotary.org/docs"
 ---
 
 TLSNotary is ideal for developers of privacy-focused projects that require **data provenance** from secure web servers. It leverages the widely-used **Transport Layer Security (TLS)** protocol to securely and privately prove that a transcript of communications with a web server took place. The protocol divides TLS session keys between two parties: the Prover and the Verifier, using **Multi-Party Computation (MPC)**. Neither the User nor Notary are in possession of the full TLS session keys, they only hold a share of those keys. This retains the security assumptions of TLS while allowing the Prover to demonstrate the **authenticity of the communication** to the Verifier. The Verifier remains unaware of which webserver is being queried, and the Verifier never has access to the unencrypted communications, except for the data the Prover explicitly wants to disclose.