NIP-05 for Brands

Domain identity starts the trust chain

A public key is powerful but hard for normal people to recognize. NIP-05 lets a domain map a readable name to that key. That means a profile can show something like a domain-backed identity instead of only a long string of characters.

For a brand ecosystem, that is useful. We can use domain-backed identities for official pages, venues, operators, creators, association roles and project surfaces. It gives you a better first clue about who is speaking.

The clue is not the whole trust story. It only says the domain made the connection. You still need to ask who controls the domain, what the identity grants and whether the surrounding governance is credible.

Brands need more than one verified account

A single brand account is not enough for Crays. The ecosystem can include Crays.org, Crays.net, Crays World, Crays Club, Crays Coffee, Crays Award, venues, local operators, creator campaigns and partner projects. Each may need a separate identity.

NIP-05 can help people distinguish official from fake, local from global and project from personal. A verified venue account can publish events. A creator campaign can point to the right award identity. An operator can prove connection to a Crays domain before handling local context.

This matters most when value or access is involved. A fake creator vote, venue offer or payment link can damage trust quickly. Domain-backed identity reduces that risk when users learn to check it.

NIP-05 is not a badge of virtue

Do not overread NIP-05. It does not guarantee good behavior, legal authority, investment rights or customer service. It is a domain proof. That proof can be strong when the domain is controlled carefully and weak when the domain policy is loose.

We therefore combine NIP-05 with badges, role descriptions, public source pages and clear issuer policy. A venue identity should say what it can do. A creator identity should connect to a campaign. A project identity should connect to the relevant public page.

The user experience should explain this without making people memorize standards. Verified means domain-linked, not automatically trustworthy in every possible way.

Revocation and changes matter

Brand identities change. Operators leave. Venues close. Campaigns end. A domain proof needs a maintenance process. We need to update, revoke or replace mappings without leaving stale identities in circulation.

Governance and product design meet here. The association can define who can request an identity. The app can show status. The domain can serve the mapping. The relay and badge layer can show additional context.

If revocation is ignored, verification becomes theater. A good NIP-05 system is alive enough to remove trust when it no longer belongs.

How you should use it

When you see a Crays-related Nostr identity, check the domain first. Does it point to a recognizable Crays domain? Does the profile link back to a public page? Does the role make sense? Does a payment or access request match the identity?

That habit is simple and powerful. It stops fake profiles from getting a free pass and it keeps the brand accountable for the identities it publishes.

NIP-05 is not glamorous, but it is one of the small standards that makes a real-world Nostr ecosystem less confusing.

How domain proof actually works

NIP-05 is simple in a good way. A domain serves a file at a known path, usually /.well-known/nostr.json, and that file maps a human-readable name to a Nostr public key. A client can check the mapping and show you that this key is connected to that domain-controlled name. That is the core. It does not say the person is honest. It does not say the venue is excellent. It does not say the account has authority to collect payment. It says the domain operator published a mapping.

That distinction matters because people often treat a verified-looking name as a trust badge. It is not. It is a domain proof. The trust comes from the surrounding chain: who controls the domain, what the page says, which role the account claims, whether a public source page confirms it, whether a badge issuer reinforces it, whether the app shows scope, and whether revocation is handled quickly when something changes. In a Crays ecosystem, NIP-05 is a starting point for judgment, not the end of judgment.

For you, the useful part is readability. A raw public key is not something you can remember at a club door, coffee counter, award campaign or investment conversation. A domain-backed name gives you a first clue: this identity is connected to a real web domain. If the app also shows the official page, role and issuer, you can decide faster whether the profile belongs in the context you are looking at.

For us, the useful part is structure. We can connect official project accounts to official domains, venue accounts to venue pages, creator campaign accounts to award pages, staff roles to limited authority and local relay accounts to the infrastructure they describe. That structure can make a complex ecosystem legible without forcing everyone to inspect long keys. But the structure only works if we stay strict about naming, scope and maintenance.

NIP-05 also reduces impersonation pressure. A fake profile can copy a logo, bio and photos. It cannot easily serve the official domain file unless it controls the domain. That does not make impersonation impossible, but it gives the app a strong signal to show you. The product should highlight that signal without overselling it. The right wording is closer to domain verified than trustworthy.

Domain proof can fail in boring ways. DNS can be misconfigured. The JSON file can be stale. A domain can change hands. A project can rename. An operator can leave. A creator campaign can end. A client can cache an old mapping. A subdomain can be forgotten. These are not exotic security scenarios; they are normal web operations. That is why a brand ecosystem needs a maintenance playbook rather than a one-time setup.

Brand architecture

Crays is not one tiny product with one account. It has the public home, association logic, app surface, world layer, club, coffee, award, finance, real estate, hospitality, technology routes and future venue or project identities. If every role used one account, the account would become too broad to trust. If every team invented names freely, the ecosystem would become messy. NIP-05 helps only when the naming architecture is intentional.

Think in layers. A root domain can represent the public brand. A project domain can represent a specific product or operating route. A venue identity can represent one physical place. A creator campaign identity can represent one time-bound campaign. A staff identity can represent a person with limited authority. A relay identity can represent infrastructure. A finance-related identity can represent a restricted communication channel with extra disclosure requirements. Those are different jobs. The names should make that difference visible.

A good brand identity answers three questions before you click anything: who is speaking, in what role, and for which scope. “Crays” alone is too broad for sensitive actions. “Crays Coffee Palma rewards” says more. “Crays Award campaign vote” says more. “Crays World venue node” says more. The product should encourage specific names because specificity reduces confusion.

Official domains also need a hierarchy. The public site can explain the ecosystem. Crays.net can handle app identity and daily product actions. Crays.world can explain venues and local nodes. Craysclub.com can explain private member and club context. Crays.coffee can explain the coffee layer. Craysaward.com can explain creator and award flows. Each domain can carry NIP-05 mappings for the identities that belong to that surface. The user experience should make the relationship obvious.

Brand architecture is also about restraint. Not every temporary campaign needs a permanent domain-backed identity. Not every staff member needs public verification. Not every partner should receive a Crays-branded name. The more identities we issue, the more maintenance and abuse risk we create. A strong system issues names where they clarify authority, not where they merely look impressive.

The public web should reinforce the Nostr identity. When you open a profile, you should be able to reach the relevant public page. When you open the public page, you should be able to identify the relevant Nostr identity. When you inspect the domain proof, you should see the same role logic. This triangle gives you confidence: app, web page and protocol proof are pointing at the same thing.

Venues, creators and staff

Venues need NIP-05 because place identity is easy to fake visually. A scam account can copy photos of a club, hotel, rooftop or coffee node and start posting offers. Domain-backed identity gives you a first check: is this profile mapped from the official domain or official venue page? The product should make that check visible before you book, pay, accept access or follow a local instruction.

A venue identity should not only say official. It should say what it can do. Can it post public events? Can it issue access? Can it accept payments? Can it publish room updates? Can it represent a local relay? Can it answer support? Can it create partner offers? A NIP-05 name by itself does not answer those questions. We need role labels, badges, source pages and app UI to show authority.

Creators need a slightly different proof chain. A creator may have their own NIP-05 identity, a Crays Award campaign identity, a venue event identity and a payment recipient identity. Those should not be blurred. If you vote for a creator, you should know whether the vote is tied to the creator's own key, a campaign key, a Crays Award issuer or a venue-hosted event. The product should show the chain before value moves.

Staff identity is more delicate. A host, bartender, concierge, operator, community manager or support person may need authority inside a venue, but not broad public authority. A staff identity can be domain-backed or badge-backed with a tight scope. You should know whether a person can check you in, approve a guest, resolve a payment issue or speak for the brand. Staff roles should be easy to revoke when someone leaves.

Operators need their own lane. A local operating partner may run a venue, but that does not mean they own the whole brand. The identity should show operating authority and limits. If the operator can issue local access, show it. If the operator can publish offers, show it. If the operator cannot collect investment-related funds, never let the interface imply that they can. Role precision prevents social trust from leaking into financial risk.

Payments require the strictest identity language. A NIP-05 proof should not be enough to send money. The app should show the merchant, venue, campaign, invoice purpose, wallet permission and support route. If a payment receiver is different from the public profile, the difference should be visible. If a creator payout is routed through a campaign, say so. If a venue payment is processed by a partner, say so. Money turns ambiguity into conflict.

Local relays can also have identities. A relay for a venue, a relay for a creator campaign or a relay for a private group can publish metadata and policy. Domain proof can help connect the relay to the official context. But again, the proof is not policy. The app should show what the relay does, what it stores, who operates it, whether authentication is required and how long local events remain available.

Issuer policy and proof chains

NIP-05 works best when issuer policy is visible. If the association maps an official identity, what criteria did it use? If a venue maps staff identities, who approves them? If an award campaign maps creator identities, how are creators checked? If a partner receives a public identity, what happens when the partnership ends? You should not need a legal memo for every profile, but the product should show enough policy to understand the strength of the proof.

Badges can add a second layer. A domain proof says the domain mapped a key. A badge can say an issuer granted a role. For example, a venue operator could have a domain-backed identity and a role badge issued by the association. A creator could have their own NIP-05 proof and a campaign badge issued by Crays Award. A staff member could have a local staff badge issued by the venue. These layers are stronger together because they separate identity from authority.

Source pages add narrative proof. A profile can show a NIP-05 name, but a public page can explain what the identity is for, which project it belongs to, which actions it can take and which sources confirm it. This matters for normal people. You should be able to open a page and understand the role without decoding event kinds. The best trust architecture is technical enough to verify and human enough to read.

Issuer policy should also describe limits. A verified venue profile may publish events and accept local bookings, but it may not represent a finance offering. A creator campaign profile may collect votes, but it may not speak for the entire award organization. A coffee node may issue rewards, but it may not issue club access. Limits are not bureaucracy. Limits are how the interface protects trust.

Proof chains should be short where possible. If you need six hops to understand whether an account is official, the product is failing. The app should assemble the chain: domain proof, issuer badge, source page, role, scope and revocation status. That can be shown as a simple trust panel. You do not need to see every raw object unless you choose to inspect deeper.

We should treat identity issuance like operations, not marketing. Every identity needs an owner, purpose, source page, review date, revocation path and support route. If nobody owns an identity, it will become stale. Stale trust is worse than no trust because it looks official while being unmanaged.

Revocation playbook

Revocation is where domain identity becomes serious. A mapping can be added quickly, but trust depends on how fast and clearly it can be removed. Staff leave. Venues change operators. Campaigns close. Domains move. Keys are compromised. Partnerships end. A Crays identity system should assume change and design for it from the start.

The first revocation layer is the domain file. If a key should no longer map to a name, the mapping should change. That sounds simple, but clients may cache results, screenshots may circulate and people may not notice. The product should show current verification status, not only the last known name. If a mapping changed recently, sensitive actions should receive extra caution.

The second layer is issuer badges and role claims. If a staff role ends, the badge should be revoked or expire. If a venue loses operating rights, role claims should be updated. If a creator campaign closes, campaign-specific rights should stop. Expiring credentials are often safer than permanent ones because they force review.

The third layer is public communication. When a meaningful identity changes, the relevant public page should explain it. This is not about drama. It is about preventing confusion. If a domain-backed venue account is replaced, guests and partners should have a canonical place to check the current identity. Source trails reduce rumor.

The fourth layer is product enforcement. A revoked identity should not keep issuing access, receiving payment, publishing official offers or appearing as current in search. Revocation has to affect the app, not only the documentation. Staff tools, venue mode, wallet permissions and campaign pages should all respect the current authority state.

Compromise handling needs its own path. If a key is suspected to be compromised, the app should warn before sensitive actions, rotate mappings where possible, publish replacement guidance and preserve a record of what changed. A clean compromise playbook protects the brand and the user. Silence creates the worst outcome: official-looking keys that nobody trusts.

Product language

The product should not say verified without context. Verified by whom? Verified for what? Verified until when? Domain-verified, venue-approved, campaign-issued, association-backed and payment-ready are different claims. The interface should use different labels because language shapes behavior.

A good identity panel might say: domain proof active, role issued by Crays Association, scope limited to venue events, payments handled by this merchant account, last checked today. That sounds longer than a blue check, but it is far more useful. The product can make it elegant, but it should not make it vague.

For normal flows, the language can be short. Official venue. Staff host. Creator campaign. Wallet recipient. Local relay. Access issuer. Public source. Each label should open into a deeper explanation when you need it. Everyday use stays calm; serious decisions get more detail.

Payment language should be especially strict. Never let a profile look payment-ready because it has a domain proof. Show recipient, purpose, amount, fee expectation, refund or support path and whether the receiver is the same identity you are viewing. If a wallet permission is persistent, show duration and limit. If a creator vote has rules, show them before payment.

Brand language should also avoid ego. The goal is not to make Crays identities look prestigious. The goal is to make authority legible. A polished trust mark that hides scope is worse than a plain label that tells the truth. In a premium ecosystem, restraint is part of design.

The Crays domain map

The domain map matters because the Crays ecosystem uses several public doors. Crays.org is the broad public and association-facing home. Crays.net is the app and daily interaction surface. Crays.world is the physical venue and destination layer. Craysclub.com carries private club and member atmosphere. Crays.coffee carries the everyday hospitality node. Crays.fund and finance-related routes point toward capital context. Crays.life connects lifestyle and real estate imagination. Craysaward.com belongs to the creator and culture route. Each domain can support different identity claims.

That separation helps you read authority. A profile mapped from Craysaward.com should not automatically be treated as a hotel operator. A coffee identity should not automatically become a finance identity. A club host should not automatically speak for the association. A public brand identity should not be used casually for local service actions. The domain tells you where the claim starts, and the role tells you how far it goes.

The app should turn that map into interface behavior. If you are viewing a venue, show the venue domain, public page and local operating role. If you are viewing an award campaign, show the campaign domain, creator identity and voting rules. If you are viewing a finance-related page, show stronger warnings, source links and support channels. If you are viewing coffee rewards, show the coffee node and redemption rules. Context is the real value of multiple domains.

Subdomains can help, but they can also confuse. A clean system might use role-based names, project-specific paths or controlled subdomains. The important part is consistency. If every project invents a naming pattern, you will stop trusting the pattern. We need a naming policy that can survive growth: readable, scoped, documented and easy to revoke.

Domain ownership itself has to be protected. Registrar access, DNS control, deployment access, source files, redirect rules and emergency contact paths are part of identity security. A NIP-05 mapping is only as strong as the operational security around the domain. That is why brand identity belongs in governance and technology conversations, not only marketing.

Abuse scenarios

Imagine a fake venue account offering a private dinner. It copies the right images, uses the right tone and sends a payment link. Without domain proof and role clarity, a guest may believe it. With a good NIP-05 implementation, the app can show that the profile is not mapped from the official venue domain and does not carry a venue-issued role. That warning can stop real damage.

Imagine a fake creator vote during an award campaign. The account looks like the creator, but the vote goes to the wrong recipient. The product should show whether the creator identity is domain-backed, whether the campaign is issued by Crays Award, whether the payment recipient matches the campaign rules and whether the action is public or private. A creator campaign without provenance invites fraud.

Imagine a former staff member whose old identity still looks valid. They may not be malicious; the system may simply be stale. But stale authority can still cause trouble: guest list changes, private invites, support promises, payment instructions, venue posts. Expiring roles and regular review prevent this. A permanent-looking staff identity should be rare and carefully justified.

Imagine a partner account trying to use Crays trust for a finance pitch. This is where identity boundaries become legal and reputational protection. A partner may be approved for events, hospitality, technology or local offers without being approved to discuss capital. The app should not let a general identity imply finance authority. Domain proof plus scope language can stop the social halo from turning into financial confusion.

Imagine a compromised key. The profile still maps to the domain until the mapping changes, but the attacker may act quickly. The system needs emergency revocation, warnings on sensitive actions, replacement identity guidance and support escalation. Users should see current status, not only a pretty name. Recovery speed matters more than looking calm.

These scenarios are not paranoia. They are normal consequences of putting identity next to access, culture, venues and money. The more valuable the ecosystem becomes, the more attractive impersonation becomes. NIP-05 is one layer of defense. It works best when the product, governance and support teams treat it as living infrastructure.

The operating model

A good NIP-05 system needs an operating model. Someone requests an identity. Someone checks the role. Someone approves the mapping. Someone publishes the domain file. Someone tests it in clients. Someone records the owner. Someone reviews it later. Someone revokes it when the role ends. Without that workflow, the identity graph will look clean for a month and decay for years.

Start with an identity register. It does not have to be public in full, but the system should know each identity's domain, public key, role, owner, issuer, source page, creation date, review date, revocation path and support contact. Sensitive identities should have stronger review. Payment-related identities should have extra checks. Staff identities should expire or require renewal. Venue identities should be tied to operating agreements.

Then define request lanes. A creator campaign identity is not requested the same way as a venue relay identity. A staff role is not requested the same way as an association identity. A partner account is not requested the same way as a finance route. Separate lanes reduce mistakes and make approvals faster because each lane has its own evidence requirements.

Testing should be part of issuance. After a mapping is published, test it in more than one client, check cache behavior, verify the public page link, inspect the profile display and test revocation in a staging path where possible. Many identity mistakes are boring formatting errors. Boring errors still break trust when the user sees them.

Review should be scheduled. A quarterly review for public project identities, more frequent review for staff and payment roles, and immediate review after partnership changes would be more credible than a one-time verification ceremony. The review asks simple questions: does this identity still exist, does the role still match, does the key still belong, does the source page still explain it, and does the revocation path still work?

Finally, make support visible. If you see a suspicious identity, you should know where to report it. If a venue changes keys, staff should know how to answer. If a creator's proof fails during a campaign, support should have a current source of truth. Identity support is not glamorous, but it is what makes the trust graph feel real when something goes wrong.

The trust UI

The trust interface should not look like a security audit pasted into a lifestyle product. It should be calm, visual and expandable. At the first level, you see a short label: official venue, creator campaign, staff host, wallet recipient, local relay or association-issued role. At the second level, you can open the proof panel: domain proof, issuer, scope, source page, last check and support route. At the third level, you can inspect raw details if you want: key, event, relay, badge issuer and timestamp.

The product should adjust detail to risk. Browsing a public event needs a light trust cue. Accepting venue access needs issuer and scope. Sending a payment needs recipient, amount, purpose and support. Joining a finance-related conversation needs stronger source links, disclaimers and role boundaries. The same NIP-05 proof can sit underneath, but the interface should become more careful as consequences increase.

Color and icon language should be restrained. A bright badge that screams official can create false confidence. A quieter status row with specific wording is safer: domain proof active, role issued, scope limited, payment verified for this invoice. The goal is not to make you stop thinking. The goal is to give you enough information to think clearly.

Errors need friendly language too. If a domain proof fails, do not show a cryptic technical message. Say the identity cannot currently be confirmed and suggest what to do: avoid payment, check the official page, contact support or wait until the mapping is restored. If a role is expired, say expired. If a key was replaced, show the replacement path. If a domain is similar but not official, warn clearly.

Staff tools need their own trust UI. A host should see whether an account can issue access. A manager should see whether a staff role is current. Finance should see whether a payment recipient is approved. Support should see the source chain and revocation history. The guest-facing UI can stay elegant only if the operational UI gives staff enough truth behind it.

Mobile matters most. NIP-05 checks will often happen at a door, counter, event or chat screen. The proof panel has to work in one hand, under pressure, without tiny technical text. If the interface is hard to read at the moment of action, the trust system becomes decorative. Good trust design is not only cryptographic. It is ergonomic.

The NIP-05 checklist

Use this checklist when you inspect any Crays-related identity. First, does the name map to a domain you recognize? Check the spelling, domain and route. Similar-looking domains are a classic impersonation trick.

Second, does the public page explain the role? An identity should not float without context. Official brand, venue, creator, campaign, staff, relay, partner and payment recipient are different roles.

Third, does the app show scope? You should know what the identity can do. Publish, issue access, receive payment, host an event, operate a relay, manage a venue, represent a campaign or provide support.

Fourth, does the proof chain include issuer and status? Domain mapping, badge issuer, source page and revocation state should reinforce each other for sensitive actions.

Fifth, does the identity have a support route? If something goes wrong, you need a human path. Identity without support is weak in hospitality, payments and access.

Sixth, does the identity avoid overreach? A coffee node should not look like a finance office. A creator campaign should not look like the whole brand. A staff role should not look permanent. Specificity is safety.

Seventh, can the identity be removed cleanly? If the answer is unclear, the system is not mature. Every issued identity should have an owner, review cycle and revocation path.

Eighth, does the product tell you what to do next? A confirmed identity can invite normal action. An unclear identity should slow you down. A failed proof should stop payments, access grants and sensitive messages until the source is checked. A recently changed identity should show the replacement path. Trust UI should guide behavior, not only display status.

Ninth, does the language match the context? At a coffee counter, “official coffee node” may be enough. At an award vote, you need campaign and payment context. In a finance conversation, you need stronger source pages and human confirmation. The same domain proof sits underneath, but the decision changes with the stakes.

Tenth, does the identity respect your time? A good proof system should make safe choices faster and risky choices more obvious. If checking a name feels like detective work, normal people will skip it. We need the proof to live where the action happens: beside the profile, beside the payment, beside the venue, beside the vote and beside the support path.

When these checks pass, NIP-05 becomes useful in the Crays ecosystem. It gives you a readable bridge from domain to key, from key to role, from role to action and from action to accountability. That is much stronger than a vanity username. It is the beginning of a trust graph you can actually use without slowing down the room, the counter, the campaign or the conversation where trust has to be earned quickly and kept clean over time, even under pressure and public scrutiny online.