diff --git a/src/contents/Prove-Online-Facts.mdx b/src/contents/Prove-Online-Facts.mdx
new file mode 100644
index 0000000..07e92c2
--- /dev/null
+++ b/src/contents/Prove-Online-Facts.mdx
@@ -0,0 +1,315 @@
+---
+name: "Prove Online Facts Without Revealing Too Much"
+index: 12
+summary: Learn to prove online facts securely without exposing sensitive information using TLSNotary.
+author: Chiemezie Agbo
+authorIcon: https://pbs.twimg.com/profile_images/1697221657373360128/iqDhBtk9_200x200.jpg
+authorLink: https://x.com/ChiemezieAgbo
+published: Dec 19, 2024
+readTime: 12 min read
+labels: ["ZK", "Privacy", "TLSNotary"]
+---
+
+
+Have you ever needed to prove something online without revealing too much personal information?
+
+Imagine you’ve got an online deal, but it’s available only to people with a certain number of followers and who live in a specific city. Let’s say you’re a public figure and want to protect your privacy, avoiding unnecessary attention. How can you prove that you meet their criteria without revealing your full identity or additional sensitive details?
+
+Welcome to **TLSNotary**, a tool that allows you to generate verifiable, cryptographic proofs of your online interactions while revealing only the information you choose. This tutorial will guide you through proving you have a certain number of X followers and live in a specific city, all without disclosing your exact profile details.
+
+# **What is TLSNotary?**
+
+[TLSNotary](https://docs.tlsnotary.org/) is a protocol that lets users securely export data from any website using **Zero-Knowledge Proofs (ZKP)**. It allows selective sharing of data with others, ensuring cryptographic verifiability without exposing sensitive information.
+
+With this protocol, users (referred to as **Provers**) can share their data with others (**Verifiers**) as they deem fit, enabling true data portability and trust.
+
+# **Why is TLSNotary Important?**
+
+## **The Limitations of TLS for Non-Repudiation**
+
+[Transport Layer Security (TLS)](https://en.wikipedia.org/wiki/Transport_Layer_Security) plays an important role in digital security by safeguarding communications between users and servers. It provides:
+
+- **Data Integrity**: Ensures data is not altered during transmission.
+- **Server Authentication**: Validates the server’s identity using Certificate Authorities (CAs).
+
+However, while TLS is effective in protecting data transmitted between user and server, it falls short in providing **non-repudiation** — the ability to prove to a third party that data is authentic and untampered.
+
+This limitation arises because TLS uses a keyed hash (Message Authentication Code, or MAC), which requires the user (e.g., Alice) to know the key. This means Alice could potentially alter the data and recompute the hash after the TLS session, making it impossible to verify the data’s authenticity to another party (e.g., Bob).
+
+**The Solution?** Digital signatures based on asymmetric public-key cryptography are required. Unfortunately, TLS does not natively support server-side signing of data, and even if it did, such an approach might compromise privacy if not designed thoughtfully. You might ask, what of [**Delegation**](https://en.wikipedia.org/wiki/Delegation_(computer_security))?
+
+## **What About Access Delegation?**
+
+[**Delegation**](https://en.wikipedia.org/wiki/Delegation_(computer_security)) is the process of a computer user handing over its authentication credentials to another user. A user (Alice) might want to share data with Bob using OAuth. In this case, Bob would access the data directly from the server to ensure its authenticity. The issue is that Bob gains **more information than necessary**. Even worse, many servers don’t support OAuth due to lack of incentive.
+
+***Here is where TLSNotary comes to the rescue,***
+
+TLSNotary addresses these challenges by introducing **Multi-Party Computation (MPC)** into the TLS communication process.
+
+# **How TLSNotary Works**
+
+The TLSNotary protocol operates through three main steps:
+
+1. **Multi-Party TLS Request:** Traditional TLS connections are between a user and a server, but TLSNotary introduces a third participant: the **Verifier**. Unlike a “[man-in-the-middle](https://en.wikipedia.org/wiki/Man-in-the-middle_attack),” the Verifier operates within a secure **Multi-Party Computation (MPC)** setup, ensuring that user data is not exposed in plaintext. To the server, the connection appears as a standard TLS request, preserving its integrity.*Alice and Bob can jointly manage the TLS connection, ensuring Bob can independently verify the data’s authenticity without seeing unshared portions.*
+2. **Selective Disclosure:** TLSNotary allows the Prover to **selectively disclose specific portions** of the data to the Verifier. Sensitive information can be redacted before sharing. ****Zero-Knowledge Proofs can be used to verify properties of redacted data without revealing the actual content.*Alice can choose which parts of the data to disclose, safeguarding her privacy.*
+3. **Data Verification:** The Verifier can then authenticate the disclosed data by validating the server certificate using trusted Certificate Authorities (CAs). This ensures that non-redacted portions of the data match their cryptographic proofs.*With this approach, Alice retains full control over her data while providing Bob with cryptographic proof of its authenticity.*
+
+## **TLSNotary and the Ethereum Foundation**
+
+TLSNotary is developed by the [**Privacy and Scaling Exploration (PSE)**](https://pse.dev/) research lab of the Ethereum Foundation. The PSE team is committed to conceptualizing and testing use cases for cryptographic primitives.
+
+# **Project: Prove Online Facts Without Revealing Too Much**
+
+**Overview:** This project demonstrates how to use **TLSNotary** to prove online facts, such as having a certain number of followers and living in a specific city, without exposing sensitive information like your exact profile details.
+
+**Use Case:** Ideal for scenarios like online deals or partnerships that require verification of certain criteria without compromising privacy.
+
+# **Setting Up the Development Environment**
+
+For this, we will go through **Three** **steps**. Most of these steps offer **two options** — choose one and move on to the next step. Often, the first option is easier from my perspective.
+
+## **1. Browser Extension**
+
+Install the TLSNotary extension in Chrome or Brave:
+
+***Option 1: Install via [Chrome Web Store](https://chromewebstore.google.com/detail/gcfkkledipjbgdbimfpijgbkhajiaaph)***
+
+Go to the Chrome Web Store and click **Add to Chrome**.
+
+
+
+ _TLSNotary Chrome Extension_
+
+
+ _Develope rMode And Load Unpacked_
+
+
+ _Hosted Proxy_
+
+
+ _UserByScreenName APi endpoint_
+
+
+ _Notarize button_
+
+
+ _Redact Data_
+
+
+ _Pending Notarization_
+
+
+ _Proof_
+
+
+ _shareable Recv Proof_
+