← All Articles
Technical 10 min read

Prove More, Share Less: Zero‑Knowledge Proofs in Meeting Place

Meeting Place lets you prove what matters in a privacy-preserving way, only sharing information needed for the interaction.

Michael Yih & Digvijay Dhamale

Most messaging apps protect message content but still ask you to identify yourself before you can participate.

Whatsapp is a good example. It offers end-to-end encrypted messaging, but you still need a phone number to create and use an account. That phone number is not just a login detail. It is a durable, real-world identifier that can be used to find you, connect with you, and link interactions across contexts.

Messenger shows a different version of the same tradeoff. Messaging is tied to a broader platform account and login, which means the conversation starts from a platform-controlled identity layer.

That is the privacy gap Affinidi Meeting Place is designed to close.

With Affinidi Meeting Place, you do not need to start by handing over a phone number, email address, or social login. When you connect, Meeting Place can create a private digital identifier for that interaction, so you can join the conversation without exposing who you are in the real world. Later, if there is a reason to share more, you decide what to reveal. Technically, that private digital identifier is called a Decentralised Identifier, or DID. They allow you to arrive anonymously, establish a secure connection, and share more only when there is a reason to do so. Your identity is not forced into the conversation by the platform. It is introduced by you on your terms.

In other words: connect first, disclose later.

What is Affinidi Meeting Place?

Affinidi Meeting Place is a toolkit for building messaging apps that let people discover each other, connect, and chat securely, without depending on phone numbers or email addresses.

The key shift is what you must share (identity layer) to exist on the network:

Platform Comparison

PlatformWhat the platform decides for youWhat that means in practiceWhat Meeting Place changes
WhatsAppYour phone number is the starting point for being reachable.Even before trust is established, the other side may know how to reach, save, forward, or associate you across contexts.Use a private identifier for each connection, so conversations are harder to trace back to one identity.
Messenger (web)Your conversation begins inside your broader Meta/Facebook account identity.Conversation in Messenger inherits the context of your existing account, profile, and social graph, instead of standing alone as a fresh interaction.Connect without pre-registering with a broader platform profile or revealing personal information upfront. Decide what identity context, if any, you want to reveal.
Affinidi Meeting PlaceUser chooses what identity context to use.Enter anonymously or pseudonymously, build trust first, and reveal details only when there is a reason to.Disclosure becomes progressive and consent-based, rather than a condition of entry.

How Meeting Place uses DIDs in a connection

In Meeting Place, a DID is created as part of the connection flow. You do not need to go somewhere else to “get” one before you can start.

A DID is different from a phone number, email address, or social login because it is not meant to be issued and controlled by a single platform account provider. It gives the user a way to control an identity for a specific interaction, instead of depending on an account that a platform owns, manages, or can restrict.

Here is how it works in practice: someone publishes a connection offer, such as an invitation to chat. Another participant claims that invitation and sends a connection request. Once the request is approved, Meeting Place creates the secure channel and generates the DIDs needed for that interaction.

This matters because the identifier does not have to be reused everywhere. A conversation with a recruiter, a community group, and a social space can each use a different identifier, helping keep those interactions separate by design.

“End‑to‑end encrypted” is not the whole story

Meeting Place is built on Affinidi Messaging, which implements DIDComm v2.1 and provides end-to-end encrypted messages.

Messages are routed through a mediator: an intermediary service that helps deliver encrypted messages without being able to read their contents. Think of it like a post office for sealed letters. It can help the letter reach the right destination, but it cannot open the envelope.

The difference is that the mediator does not have to be a single platform-controlled service. Depending on how Meeting Place is deployed, the mediator can be hosted by Affinidi, or self-hosted by an organisation, or run as part of a custom deployment.

That gives builders more control over the delivery layer. They can choose who operates the mediator, how access is managed, and where messages are temporarily handled, while still preserving end-to-end encryption.

From private messaging to private proof

So far, we have talked about how Meeting Place helps people connect and communicate without exposing more identity than necessary. But private communication is only part of the problem.

In many digital interactions, the next step is not just “message me.” It is “prove something to me.”

Prove you are over 18.

Prove you are a member.

Prove you work for a company.

Prove you are a human.

Today, that usually means sharing the underlying data: a date of birth, a membership record, an employee profile, or some other personal detail. Zero-knowledge proofs change that model (read our blog on Zero-knowledge proofs).

A zero-knowledge proof, or ZKP, lets someone prove that a statement is true without revealing the data behind it. Instead of sending “my date of birth is 12 May 1995,” you can send a proof that says “I am over 18,” and nothing more.

Meeting Place does not replace the credential or verification layer. It provides the private connection where proof requests and proof responses can happen securely. The proof itself can be derived from a Verifiable Credential, which is a tamper-evident digital credential issued by a trusted party and held by the user. Affinidi Elements provides building blocks for issuing, sharing, and verifying these credentials, while ZKP-capable credential flows can allow the holder to prove something about a credential without revealing the credential in full.

Meeting Place Flow

The diagram below shows why Meeting Place is a natural place for private proof flows. First, two parties establish a secure DID-based connection. Once that private channel exists, a verifier can ask for a specific proof, such as “Are you over 18?”, and the user can respond with only the proof required. The underlying credential, such as the full date of birth or ID record, does not need to be sent into the conversation.

Meeting Place Human Proof Progression Figure: Meeting Place creates the private connection. Verifiable Credentials and ZKPs make it possible to prove specific claims inside that connection without exposing the underlying data.

The same pattern applies beyond age checks:

  • A community can confirm that someone is an active member without seeing their full membership record.

  • A company can confirm employment status without exposing an employee profile.

  • A service can confirm eligibility without collecting the underlying document.

That’s the value of pairing Meeting Place with Verifiable Credentials and ZKPs: the conversation can move from “send me your data” to “prove only what I need to know”.

The big shift: prove more, share less

Meeting Place changes what a digital conversation can begin with. Instead of starting with a phone number, social profile, or platform account, it starts with a private connection that the user controls.

That matters because trust is not always about revealing who you are. Sometimes it is about proving one specific thing.

By combining DID-based connections, end-to-end encrypted messaging, Verifiable Credentials, and Zero-Knowledge Proofs, Meeting Place creates a foundation for interactions where users can build trust without oversharing.

Connect first. Prove what is needed. Share the rest only when you deem necessary.

Want to see it in action? Try the Meeting Place reference app and experience what it means to connect first,

References

Zero-Knowledge ProofsDigital IdentityVerifiable CredentialsPrivacySelective DisclosureDecentralized IdentityCryptographyIdentity VerificationAuthenticationData Ownership

Build with Affinidi

Start building trust infrastructure with our open-source tools and developer-friendly APIs.

Cookie Preferences

We use cookies to enhance your experience. You can manage your preferences below. For more information, read our Cookie Policy.

Strictly Necessary Always Active

These cookies are essential for core website functions such as security, session integrity, and cookie preference storage. They cannot be disabled.

  • _cf_bm: Distinguishes humans from bots (Cloudflare) · 30m
  • _cfuvid: Ensures secure browsing (Cloudflare) · Session
  • __hs_initial_opt_in: Prevents HubSpot's banner · 7 days
  • _gtm_debug: GTM debug mode (testing only) · Session
Analytics

These cookies help us understand how visitors interact with the site so we can improve content and performance. All data is aggregated and anonymous.

  • _ga, _gid, _gat: Google Analytics · Session – 2 years
  • __hstc, hubspotutk, __hssrc: HubSpot visitor tracking · 13 months
  • __hs_opt_out: HubSpot opt-out preference · 6 months
Marketing & Targeting

These cookies allow us and our partners to serve personalised ads and measure campaign performance.

  • _gcl_au, _gcl_dc: Google Ads conversion tracking · 90 days
  • IDE: Google Display Network personalisation · 1 year
  • _fbp: Meta / Facebook remarketing · 90 days
  • li_gc, _li_fat_id, bcookie: LinkedIn tracking · 1–24 months
  • guest_id, personalization_id: Twitter/X analytics · 2 years