{"id":"26b9f112961462cc49102d74de6385948d1850f850ed91abfb08bcbc1da4a2fb","pubkey":"b22b06b051fd5232966a9344a634d956c3dc33a7f5ecdcad9ed11ddc4120a7f2","created_at":1780912468,"kind":30817,"tags":[["d","address-book"],["title","Address Book"],["k","38522"],["client","nostrhub.io"]],"content":"# Address Book\n\n`draft` `optional`\n\nThis document defines a portable, private address book.\n\nThe goal is to let mail clients, contact apps, phone/call apps, calendar apps,\nand other personal information tools share the same contact cards without being\ntied to a single application.\n\n## Motivation\n\nNostr already has NIP-02 follow lists, often called \"contact lists\", but those\nlists describe Nostr profiles a user follows. They are not a general address\nbook.\n\nA general contact may contain names, email addresses, phone numbers, postal\naddresses, organizations, notes, avatars, Nostr public keys, and other contact\nmethods. This protocol defines a Nostr-native storage layer for that broader\naddress-book use case.\n\n## Event Kind\n\nContact cards are stored as addressable events.\n\n```text\nkind: 38522\n```\n\n## Addressing\n\nEach contact card event MUST have a `d` tag containing the vCard `UID` of the\ncontact:\n\n```json\n[\"d\", \"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6\"]\n```\n\n## Contact Card Format\n\nContact cards MUST be encoded as vCard 4.0 objects as defined by RFC 6350.\n\nClients MAY import older vCard versions, jCard, or other contact formats, but\nthe canonical payload stored in contact card events MUST be vCard 4.0.\n\nEach card MUST contain a stable `UID`. The `UID` MUST match the event `d` tag.\n\nClients creating a new contact SHOULD generate a UUID-based `UID`, for example:\n\n```text\nurn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6\n```\n\nExample vCard value:\n\n```text\nBEGIN:VCARD\nVERSION:4.0\nUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6\nFN:Alice Example\nN:Example;Alice;;;\nEMAIL;TYPE=work;PREF=1:alice@example.com\nTEL;TYPE=cell,voice:tel:+33123456789\nIMPP:nostr:npub1example...\nREV:20260607T120000Z\nEND:VCARD\n```\n\n## Privacy\n\nContact cards SHOULD be private.\n\nThe event `content` SHOULD contain the vCard 4.0 payload encrypted to the\nauthor using NIP-44 self-encryption.\n\nClients MUST NOT publish contact cards in plaintext unless the user explicitly\nasks for that.\n\nClients SHOULD generate opaque UUID-based `UID` values so the public `d` tag\ndoes not leak personal information.\n\n## Event Structure\n\nExample contact card event:\n\n```json\n{\n  \"kind\": 38522,\n  \"tags\": [\n    [\"d\", \"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6\"]\n  ],\n  \"content\": \"<nip44-encrypted vCard 4.0>\"\n}\n```\n\nThe decrypted `content` MUST be a single vCard 4.0 object.\n\n## Adding a Contact\n\nTo add a contact, publish a contact card event with a new `UID`.\n\nApplications MAY create a minimal contact when the user saves a domain-specific\nrecipient. For example, a mail client can create a vCard containing only `UID`,\n`FN`, `N`, and one `EMAIL` property.\n\n## Updating a Contact\n\nTo update a contact, publish a newer contact card event with the same `UID` in\nthe `d` tag and in the decrypted vCard.\n\nApplications SHOULD preserve unknown vCard properties and parameters when\nediting a contact.\n\n## Deleting a Contact\n\nTo delete a contact, clients SHOULD publish a NIP-09 deletion event for the\nlatest known contact card event id.\n\nPublishing a newer non-deleted card with the same `UID` restores the contact.\n\n## Private Media\n\nContact cards MUST remain small enough for ordinary relay limits.\n\nClients SHOULD NOT embed large binary media, such as contact photos, directly\ninside vCards.\n\nPublic media MAY be referenced with vCard `PHOTO` URI values.\n\nPrivate media SHOULD be stored as encrypted blobs outside the contact card. The\ncontact card SHOULD contain only the URI and the metadata required to retrieve\nand decrypt the blob. Nostr clients SHOULD prefer user-controlled media storage\nsuch as Blossom when possible.\n\nIf a client does not implement encrypted private media, it SHOULD keep private\ncontact photos local instead of publishing them in plaintext.","sig":"1452722444aa3cb44537bf1b4e36fd524b2cd2433fa6209bcbf4eef7c3ebc6ecd51291b620f09dffec04baf8d5925f7601052458ede9d692f56613e82f108e40"}