From 73f6caa7af762a982fb01e85f8e3b5c551e5697c Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Mon, 23 Jun 2025 14:59:16 +0100 Subject: [PATCH] plugin sdk presentation --- _drafts/tlsn-sdk-2025-06-23/Prover.svg | 4 + _drafts/tlsn-sdk-2025-06-23/README.md | 10 + _drafts/tlsn-sdk-2025-06-23/Verifier.svg | 4 + _drafts/tlsn-sdk-2025-06-23/plugins.drawio | 61 ++++ _drafts/tlsn-sdk-2025-06-23/plugins.svg | 4 + _drafts/tlsn-sdk-2025-06-23/sdk.html | 302 ++++++++++++++++++ _drafts/tlsn-sdk-2025-06-23/sdk.md | 144 +++++++++ .../tlsn-sdk-2025-06-23/tlsnotary-logo.svg | 17 + 8 files changed, 546 insertions(+) create mode 100644 _drafts/tlsn-sdk-2025-06-23/Prover.svg create mode 100644 _drafts/tlsn-sdk-2025-06-23/README.md create mode 100644 _drafts/tlsn-sdk-2025-06-23/Verifier.svg create mode 100644 _drafts/tlsn-sdk-2025-06-23/plugins.drawio create mode 100644 _drafts/tlsn-sdk-2025-06-23/plugins.svg create mode 100644 _drafts/tlsn-sdk-2025-06-23/sdk.html create mode 100644 _drafts/tlsn-sdk-2025-06-23/sdk.md create mode 100644 _drafts/tlsn-sdk-2025-06-23/tlsnotary-logo.svg diff --git a/_drafts/tlsn-sdk-2025-06-23/Prover.svg b/_drafts/tlsn-sdk-2025-06-23/Prover.svg new file mode 100644 index 0000000..0c67ac2 --- /dev/null +++ b/_drafts/tlsn-sdk-2025-06-23/Prover.svg @@ -0,0 +1,4 @@ + + + +
Desktop
App
Browser
Mobile
App
Plugin
Tester
Plugin
Plugin
Plugin
Plugin
Plugin
Plugin
Plugin
Plugin
\ No newline at end of file diff --git a/_drafts/tlsn-sdk-2025-06-23/README.md b/_drafts/tlsn-sdk-2025-06-23/README.md new file mode 100644 index 0000000..b20f387 --- /dev/null +++ b/_drafts/tlsn-sdk-2025-06-23/README.md @@ -0,0 +1,10 @@ +* https://marpit.marp.app/ +* https://chris-ayers.com/2023/03/31/customizing-marp + +``` +brew install marp-cli +``` + +``` +marp sdk.md --preview +``` \ No newline at end of file diff --git a/_drafts/tlsn-sdk-2025-06-23/Verifier.svg b/_drafts/tlsn-sdk-2025-06-23/Verifier.svg new file mode 100644 index 0000000..df77d99 --- /dev/null +++ b/_drafts/tlsn-sdk-2025-06-23/Verifier.svg @@ -0,0 +1,4 @@ + + + +
Verifier
Server
Plugin
Plugin
host
\ No newline at end of file diff --git a/_drafts/tlsn-sdk-2025-06-23/plugins.drawio b/_drafts/tlsn-sdk-2025-06-23/plugins.drawio new file mode 100644 index 0000000..f43d5c2 --- /dev/null +++ b/_drafts/tlsn-sdk-2025-06-23/plugins.drawio @@ -0,0 +1,61 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_drafts/tlsn-sdk-2025-06-23/plugins.svg b/_drafts/tlsn-sdk-2025-06-23/plugins.svg new file mode 100644 index 0000000..aada364 --- /dev/null +++ b/_drafts/tlsn-sdk-2025-06-23/plugins.svg @@ -0,0 +1,4 @@ + + + +
Desktop
App
Browser
Mobile
App
Plugin
Tester
Plugin
Plugin
Plugin
Plugin
Plugin
Plugin
Plugin
Plugin
Verifier
Server
Plugin
Plugin
\ No newline at end of file diff --git a/_drafts/tlsn-sdk-2025-06-23/sdk.html b/_drafts/tlsn-sdk-2025-06-23/sdk.html new file mode 100644 index 0000000..7efbf30 --- /dev/null +++ b/_drafts/tlsn-sdk-2025-06-23/sdk.html @@ -0,0 +1,302 @@ +TLSNotary SDK
+

TLSNotary SDK

+

A modular SDK for private web data verification
+without compromising flexibility, privacy, or security.

+
+
+

From Breakthrough to SDK

+
    +
  • ✅ TLSNotary: zkTLS 0 → 1
  • +
  • 🔓 Censorship-resistant, open source, private, and secure
  • +
  • ⚠️ Next challenge: safe & flexible developer experience
  • +
+
+
+

What Does TLSNotary Proving Involve?

+

+
    +
  1. Prover creates request (with headers, cookies, payload)
  2. +
  3. Prover redacts/zkps sensitive parts
  4. +
  5. Verifier validates the revealed data
  6. +
  7. Verifier performs a follow-up action (e.g., attestation)
  8. +
+
+
+

Challenge: How to Use TLSNotary in Practice?

+
    +
  • TLSNotary is a Rust library 🦀 (+WASM 🌍)
  • +
  • Clone getting started examples (low level)
  • +
  • Clone our browser extension (requires access to all data on all sites 😱)
  • +
+

How to ensure that:

+
    +
  • it is secure?
  • +
  • user privacy is truly protected?
  • +
+
+
+

Insight: App Logic Is "Same But Different"

+
    +
  • Wide variety of integration patterns across web, mobile, and server environments
  • +
  • A structured solution is required to handle diverse use cases safely and allow for independent audits
  • +
+
+
+

Solution: SDK with Plugin System

+
    +
  • App-specific logic lives in isolated plugins
  • +
  • TLSNotary runtime handles the rest
    +Web, Mobile, Desktop, Server runtimes (wasm/native bindings)
  • +
+

Plugin-style architecture, running in a secure sandbox.

+
+
+

What Exactly Is a Plugin?

+
    +
  • Small WebAssembly module defining app-specific logic
  • +
  • Called by the TLSNotary runtime during proof or verification
  • +
  • Written in Rust, TypeScript, or any WASM-compatible language
  • +
  • Compiled, auditable, and sandboxed
  • +
+

(We currently use Extism to handle this.)

+
+
+

Why Not Simple Templates?

+
    +
  • Templates cover common cases but break under edge-case needs
  • +
  • Rigid approaches lead to workarounds and security risks
  • +
+

A simple template engine could be added as a plugin (e.g., to support Reclaim templates).

+
+
+

Prover Plugins: Creating proofs

+
    +
  • Developed by app developer (often also the verifier)
  • +
  • Should be open source
  • +
  • Balance between: +
      +
    • user privacy
    • +
    • verifiability (valid JSON with "holes")
    • +
    • ease of development
    • +
    +
  • +
  • Handles 2 major application specific tasks: +
      +
    • Creating requests requires input: headers, cookies, etc.
    • +
    • Redaction (more complicated than it sounds)
    • +
    +
  • +
+
+
+

Verifier Plugins: Interpreting Proofs Safely

+
    +
  • Can be closed source
  • +
  • Verification on multiple levels: +
      +
    • TLSNotary checks protocol and commitments
    • +
    • Plugins verify structure of revealed data...
    • +
    • ...and process the data for higher-level app consumption
    • +
    +
  • +
+
+
+

Performance and Security Considerations

+
    +
  • Performance-critical operations reside in core runtime
  • +
  • Plugin execution (control logic) incurs negligible WASM overhead
  • +
  • Sandboxed plugins reduce risk of misconfiguration and simplify auditing
  • +
  • SDK defines a clear API → low level development also fully supported
  • +
+
+
+

What About Generic Notaries?

+

A blind notary is a verifier plugin:

+
    +
  • Verifies commitments only, without inspecting revealed data
  • +
  • Issues signed attestation for downstream verification
  • +
+

→ Plugins enable both public attestations and fully private verification flows

+
+
+

Closing: Enabling the Next Wave of Use Cases

+
    +
  • Modular integrations without modifying TLSNotary internals
  • +
  • Safer, more consistent developer experience
  • +
  • Foundation for broader adoption across Web2 and Web3 applications
  • +
+
+

Speaker notes go here.

- Plugins allow for independent inspection

\ No newline at end of file diff --git a/_drafts/tlsn-sdk-2025-06-23/sdk.md b/_drafts/tlsn-sdk-2025-06-23/sdk.md new file mode 100644 index 0000000..542abe8 --- /dev/null +++ b/_drafts/tlsn-sdk-2025-06-23/sdk.md @@ -0,0 +1,144 @@ +--- +theme: gaia +class: invert +paginate: true +marp: true +style: | + .columns { + display: grid; + grid-template-columns: repeat(2, minmax(0, 1fr)); + gap: 1rem; + } +--- + +# TLSNotary SDK + +A modular SDK for private web data verification +without compromising flexibility, privacy, or security. + +--- + + +## From Breakthrough to SDK + +- ✅ TLSNotary: zkTLS **0 → 1** +- 🔓 Censorship-resistant, open source, private, and secure +- ⚠️ Next challenge: safe & flexible developer experience + +--- + +## What Does TLSNotary Proving Involve? + +![](https://tlsnotary.org/assets/images/overview_prover_verifier-d1c5dd944ba01e3fe8983375aad61c1e.svg#gh-dark-mode-only) + +1. **Prover** creates request (with headers, cookies, payload) +2. **Prover** redacts/zkps sensitive parts +3. **Verifier** validates the revealed data +4. **Verifier** performs a follow-up action (e.g., attestation) + +--- + +## Challenge: How to Use TLSNotary in Practice? + +- TLSNotary is a Rust library 🦀 (+WASM 🌍) +- Clone getting started examples (low level) +- Clone our browser extension (requires access to **all data on all sites** 😱) + +How to ensure that: +- it is secure? +- user privacy is truly protected? + +--- + +## Insight: App Logic Is "Same But Different" + +- Wide variety of integration patterns across **web, mobile, and server environments** +- A structured solution is required to handle diverse use cases safely and allow for independent **audits** + +--- + +## Solution: SDK with Plugin System + +- App-specific logic lives in isolated plugins +- TLSNotary runtime handles the rest + Web, Mobile, Desktop, Server runtimes (wasm/native bindings) + +_Plugin-style architecture, running in a secure sandbox._ + +![bg vertical 80%](./none) +![bg vertical 80%](./plugins.svg) + +--- + + +## What Exactly Is a Plugin? +- Small WebAssembly module defining app-specific logic +- Called by the TLSNotary runtime during proof or verification +- Written in Rust, TypeScript, or any WASM-compatible language +- Compiled, auditable, and sandboxed + +_(We currently use [Extism](https://extism.org/) to handle this.)_ + +![bg vertical 80%](./none) +![bg vertical 80%](./plugins.svg) + +--- + +## Why Not Simple Templates? + +- **Templates** cover common cases but break under edge-case needs +- Rigid approaches lead to workarounds and **security** risks + +A simple template engine could be added as a plugin (e.g., to support Reclaim templates). + +--- + +## Prover Plugins: Creating proofs + +- Developed by app developer (often also the verifier) +- Should be open source +- Balance between: + - user privacy + - verifiability (valid JSON with "holes") + - ease of development +- Handles 2 major application specific tasks: + - Creating requests requires input: headers, cookies, etc. + - Redaction (more complicated than it sounds) + +--- + +## Verifier Plugins: Interpreting Proofs Safely + +- Can be closed source +- Verification on multiple levels: + - TLSNotary checks protocol and commitments + - Plugins verify structure of revealed data... + - ...and process the data for higher-level app consumption + +--- + +## Performance and Security Considerations + +- Performance-critical operations reside in core runtime +- Plugin execution (control logic) incurs negligible WASM overhead +- Sandboxed plugins reduce risk of misconfiguration and simplify auditing +- SDK defines a clear API → low level development also fully supported + +--- +## What About Generic Notaries? + +A **blind notary** is a verifier plugin: + +- Verifies commitments only, without inspecting revealed data +- Issues signed attestation for downstream verification + +→ Plugins enable both public attestations and fully private verification flows + +--- + +## Closing: Enabling the Next Wave of Use Cases + +- Modular integrations without modifying TLSNotary internals +- Safer, more consistent developer experience +- Foundation for broader adoption across Web2 and Web3 applications diff --git a/_drafts/tlsn-sdk-2025-06-23/tlsnotary-logo.svg b/_drafts/tlsn-sdk-2025-06-23/tlsnotary-logo.svg new file mode 100644 index 0000000..b9d692c --- /dev/null +++ b/_drafts/tlsn-sdk-2025-06-23/tlsnotary-logo.svg @@ -0,0 +1,17 @@ + + + + + + + \ No newline at end of file