Skip to main content

Legacy Identity Providers (LIDP)

A Legacy Identity Provider (LIDP) is any traditional identity or telecommunications service that an Identity Authority queries to verify user identity.

By binding LIDP accounts to Nostr public keys, the protocol opens Lightning payments to traditional identities — anyone with a Discord, X, or Email account can receive payments, even if they've never interacted with Nostr or Lightning before.

Supported LIDPs

Example supported LIDPs:

LIDPIdentifier FormatVerification Method
Discorddiscord_id (Snowflake)OAuth 2.0
X@handleOAuth 1.0a/2.0
Emailuser@example.comOne-Time Password (OTP)
Phone+1234567890RCS One-Time Password (OTP)

The Privacy Model

Binding a Nostr public key to a real-world identity introduces privacy considerations. The protocol limits data leakage through two primary models:

1. The Hashed Privacy Model (High Privacy)

For sensitive identifiers like Phone Numbers and Email Addresses, strict cryptographic hashing is used.

  • The raw identifier is never published to the Nostr network.
  • The d tag (the Connection Key) is dynamically generated as SHA256(lidp_name:identifier).
  • Senders resolve these identities by locally hashing the target email/phone and querying the network for the resulting hash.

2. The Public Model (Social Discovery)

For inherently public profiles like X handles and Discord IDs, the identifier is often directly visible or easily reversible. This enables global search and social discovery features on implementing clients.

Verification: OAuth vs. OTP

LIDPs generally fall into two verification flows:

OAuth Identity Providers (Discord, X): The IA redirects the user to the provider, receives an access token, and queries the user's profile. Crucially, the IA can wrap this token in an encrypted evidence payload, meaning the robust evidence of ownership can be securely shared with other IAs.

OTP Providers (Email, Phone via RCS): The IA sends a one-time code directly to the user's inbox or device. Because there is no persistent "access token" returned by an external authority, there is no portable evidence payload. If a user wants to prove their Email addresses to a different IA, that IA must natively send its own OTP to verify ownership.