Juraj on Nostr: I want to share a few things that currently fascinate me about **Zero Knowledge ...
I want to share a few things that currently fascinate me about **Zero Knowledge Proofs (ZKP)**. The first is **Private Set Intersection (PSI)**, which is a great tool for finding overlaps in data without revealing details. For example, a job applicant has certain skills (with a limit on their number), and an employer has specific requirements (also with a limit). Using PSI, you can determine if there’s a match between them. Additionally, with **Range Proofs**, it’s possible to prove whether the absolute minimum and maximum requirements align between the applicant and the employer. If there’s no match, there’s no point in inviting the applicant for an interview. This principle could be applied to other areas, such as finding common interests at conferences or on the **Nostr** platform. Combined with some identity verification heuristic and a **Humanity Score**, it could help identify interesting people to follow. I find these algorithms very intriguing.
Another thing that excites me is the combination of **TLS Notary** and **email verification**. Let me explain with an example of verifying a Twitter account linked to a Nostr account. One option is to use TLS Notary, where I generate proof that the x.com server returned a specific response to a request (e.g., the content of a status on a particular page). This proof is signed by the x.com TLS certificate. It’s a similar approach to what **Keybase** used—a platform I really liked, though it lost relevance after being acquired by Zoom. With Keybase, each client verified the proof independently, which may no longer be possible since Twitter requires login. However, a TLS proof allows verification of the status’s existence without needing to log into Twitter—the verifier simply checks the ZKP proof.
A similar principle works with email verification. Nowadays, emails are signed with a DKIM key corresponding to the sender’s domain. If I receive an email from Twitter with text like “Hello, Juraj, you have a message” or “Juraj, we detected a login attempt,” I can extract my username from it and prove that the email was indeed received and signed by the x.com key. This proof is tamper-proof—any changes would invalidate it. Additionally, it can be verified that the email came from a specific address to a specific address. I see this as a great alternative to Keybase, but built on Nostr. In Nostr, the problem is that anyone can easily create an account and have dozens of clones, so the only reference point is the follower count. However, if we could verify connections to Twitter, GitHub, or email, it would carry more weight. We could assign a score based on verified data and mutual following of verified (non-bot) accounts.
Such verifiable cryptographic mechanisms can be applied to various areas on the web. For instance, I can prove that I received a payment on **Revolut** or that I sent one. Accounts on various platforms can be verified, and even a bank balance in online banking can be confirmed. Another option, though not everyone likes it, is identity verification using a **national ID with a digital signature**. I can prove that I’m a physical person, for example, from Slovakia, over 18 years old, and that I haven’t verified any other Nostr account with this ID (using a so-called nullifier). The beauty of this is that I choose which data to verify—I don’t have to disclose my age, nationality, or other identifying details. I can simply sign the account with a valid but anonymous certificate.
Similarly, a passport can be used for verification. In this case, I’m not verifying a signature, nor can I sign anything with the passport, as it only contains the public key of the certification authority and the data from the passport’s main page (number, name, date of birth, etc.). This is also a way to verify identity. Modern passports, often called biometric, actually contain only JPEG photos, and even those aren’t always fully accessible. However, the existence of a passport (e.g., a Slovak one) can be verified without revealing specific details. Here, too, ZKP nullifiers are needed to prevent one passport from being used to verify thousands of bot accounts, which would defeat the purpose.
These are some aspects of Zero Knowledge Proofs that currently captivate me.
Published at
2025-06-08 08:12:31Event JSON
{
"id": "198cbc5b778c23eee1510891c5894b93c4a030d7b29c8e137d506547bc4ba731",
"pubkey": "dab6c6065c439b9bafb0b0f1ff5a0c68273bce5c1959a4158ad6a70851f507b6",
"created_at": 1749370351,
"kind": 1,
"tags": [
[
"r",
"x.com"
],
[
"r",
"x.com"
],
[
"r",
"x.com"
]
],
"content": "I want to share a few things that currently fascinate me about **Zero Knowledge Proofs (ZKP)**. The first is **Private Set Intersection (PSI)**, which is a great tool for finding overlaps in data without revealing details. For example, a job applicant has certain skills (with a limit on their number), and an employer has specific requirements (also with a limit). Using PSI, you can determine if there’s a match between them. Additionally, with **Range Proofs**, it’s possible to prove whether the absolute minimum and maximum requirements align between the applicant and the employer. If there’s no match, there’s no point in inviting the applicant for an interview. This principle could be applied to other areas, such as finding common interests at conferences or on the **Nostr** platform. Combined with some identity verification heuristic and a **Humanity Score**, it could help identify interesting people to follow. I find these algorithms very intriguing.\n\nAnother thing that excites me is the combination of **TLS Notary** and **email verification**. Let me explain with an example of verifying a Twitter account linked to a Nostr account. One option is to use TLS Notary, where I generate proof that the x.com server returned a specific response to a request (e.g., the content of a status on a particular page). This proof is signed by the x.com TLS certificate. It’s a similar approach to what **Keybase** used—a platform I really liked, though it lost relevance after being acquired by Zoom. With Keybase, each client verified the proof independently, which may no longer be possible since Twitter requires login. However, a TLS proof allows verification of the status’s existence without needing to log into Twitter—the verifier simply checks the ZKP proof.\n\nA similar principle works with email verification. Nowadays, emails are signed with a DKIM key corresponding to the sender’s domain. If I receive an email from Twitter with text like “Hello, Juraj, you have a message” or “Juraj, we detected a login attempt,” I can extract my username from it and prove that the email was indeed received and signed by the x.com key. This proof is tamper-proof—any changes would invalidate it. Additionally, it can be verified that the email came from a specific address to a specific address. I see this as a great alternative to Keybase, but built on Nostr. In Nostr, the problem is that anyone can easily create an account and have dozens of clones, so the only reference point is the follower count. However, if we could verify connections to Twitter, GitHub, or email, it would carry more weight. We could assign a score based on verified data and mutual following of verified (non-bot) accounts.\n\nSuch verifiable cryptographic mechanisms can be applied to various areas on the web. For instance, I can prove that I received a payment on **Revolut** or that I sent one. Accounts on various platforms can be verified, and even a bank balance in online banking can be confirmed. Another option, though not everyone likes it, is identity verification using a **national ID with a digital signature**. I can prove that I’m a physical person, for example, from Slovakia, over 18 years old, and that I haven’t verified any other Nostr account with this ID (using a so-called nullifier). The beauty of this is that I choose which data to verify—I don’t have to disclose my age, nationality, or other identifying details. I can simply sign the account with a valid but anonymous certificate.\n\nSimilarly, a passport can be used for verification. In this case, I’m not verifying a signature, nor can I sign anything with the passport, as it only contains the public key of the certification authority and the data from the passport’s main page (number, name, date of birth, etc.). This is also a way to verify identity. Modern passports, often called biometric, actually contain only JPEG photos, and even those aren’t always fully accessible. However, the existence of a passport (e.g., a Slovak one) can be verified without revealing specific details. Here, too, ZKP nullifiers are needed to prevent one passport from being used to verify thousands of bot accounts, which would defeat the purpose.\n\nThese are some aspects of Zero Knowledge Proofs that currently captivate me.",
"sig": "5dd6b66815ffba31520d1c5bcc07b63a23d32cf2be60301bf002016fffad972071aee77b25286eaa7ebb053cc299c703e67a17190591e0b7f4abcb930d98e508"
}