At Block, we are exploring various ways to integrate with Nostr, which stands for Notes and Other Stuff Transmitted by Relays. It's an open protocol for publishing data on the internet that is decentralized, verifiable, and censorship-resistant.
We currently have two types of Nostr accounts associated with Block:
- Company accounts
- Employee accounts
Examples of company Nostr accounts include:
These are official accounts that post social content about Block and its brands.
We also have several employees who use Nostr. These are generally personal accounts that may or may not choose to publicly represent and post content about Block.
So how can you look up these accounts? Even if you find these accounts, how can you trust that they are actually associated with Block?
Identity
Each Nostr account is represented by a public-private keypair. In human-readable bech32-encoded form, these are 32-byte strings that look like:
npub1...(public key)nsec1...(private key)
The public key is a publicly shared identifier used by others to identify the account and verify that published events are signed with an associated private key. The private key is a secret known only to the account holder(s).
Looking up accounts by public key can be difficult because it consists of a long series of characters that are hard to remember or verify at a glance.
Events
A Nostr event is a JSON object that has a kind number, tags, content, and other fields. Events can be published to one or many relays (simple servers), and others can fetch events from these relays. An event kind is a number that specifies how clients should interpret the meaning of the event.
For example,
kind 0 is a user metadata event, which can contain the name, description, profile picture, and other attributes of the account.
json1{ 2 "id": "a64b4dd0cbac27f16ce769be872e16a04b3fccfae0c540c24b29bbeed210eda1", 3 "pubkey": "c7617e84337c611c7d5f941b35b1ec51f2ae6e9f41aac9616092d510e1c295e0", 4 "created_at": 1746479681, 5 "kind": 0, 6 "tags": [], 7 "content": "{\"name\":\"CashApp\",\"picture\":\"https://cash-f.squarecdn.com/static/nostr-cash-app-logo.jpeg\",\"nip05\":\"_@cash.app\",\"banner\":\"https://cash-f.squarecdn.com/static/nostr-cash-app-banner.png\",\"display_name\":\"Cash App\",\"website\":\"https://cash.app\",\"created_at\":1677527417,\"lud16\":\"\"}", 8 "sig": "63f60ba266c0e5358e1206f0a297a73f9990a26903136ebfb776a2e2ad827ace13e55aebb950654718baee44460ff73ae2cdaf776128d0bc461b8f5236979fe9" 9}
kind 1 is a short text note.
json1{ 2 "id": "01141b5b97b58dbe6448332dd3e0d32215c85efa11f54c7ceb167fa326afc6fc", 3 "pubkey": "c7617e84337c611c7d5f941b35b1ec51f2ae6e9f41aac9616092d510e1c295e0", 4 "created_at": 1684357652, 5 "kind": 1, 6 "tags": [], 7 "content": "Running Nostr ⚡", 8 "sig": "801c7386433ac4471873cb88ea086264a8d38784cf0dd1200b2ad234f27452bcbdbc7d55c568fb879dfa6c38f843531952086e5423fef9d8aea43612766fcd69" 9}
Impersonation
Any person or machine can generate as many keypairs as they want and publish profile metadata without needing to verify with any central authority because Nostr is a decentralized protocol.
This feature provides censorship resistance to the protocol, but it's also an attack vector because a bad actor can impersonate others to mislead users.
Anyone can generate a keypair and impersonate the Block Open Source account by copying its name, description, and profile picture in a kind 0 event. If someone queries for accounts by the name Block Open Source, impersonators may come up as names are not unique.
Some centralized platforms may conduct identity verification in order to verify that you are who you say you are. This does not exist on the Nostr protocol.
There are different methods for detecting impersonation, including web of trust, impersonation reports, and internet identifiers. This blog post focuses on the use of domain-associated internet identifiers as a form of trust.
Identification, not Verification
The NIP-05 specification provides a way for a domain to associate with one or many public keys by providing them with a Nostr internet identifier, an email-like address: <name>@<domain>.
It's important to understand that NIP-05 provides identification (linking a pubkey to a domain) but not verification (proving someone's real-world identity). This distinction is crucial:
- Identification answers the question "Which pubkey does block.xyz associate with opensource@block.xyz?"
- Verification would answer "Is this person really who they claim to be?"
For example, in the case of the Block Open Source account, the company attests that the account can be trusted because https://block.xyz/.well-known/nostr.json?name=opensource returns its public key (in hex format). This identifies that specific pubkey as being associated with block.xyz, but doesn't inherently verify anything about the real-world entity operating it.
Nostr clients can easily look up the Block Open Source account by using the opensource@block.xyz identifier without needing to enter its public key. The trust in this system comes from trusting the domain itself. If you trust that block.xyz is the domain of Block, Inc., then you can trust that those public keys are associated with the company. Therefore, the content signed by those accounts can be trusted as legitimate.
NIP-05 as a Service
Internally, we built a NIP-05 service where:
- Administrators of the service can register custom
<name>@<domain>Nostr identifiers for company accounts - Employees can reserve their own
<username>@block.xyzNostr identifier that maps to their public key - Nostr clients on the public internet can query
/.well-known/nostr.json?name=<name>on Block domains to fetch the corresponding public key
Nostr accounts can reciprocate by setting the nip05 field of their kind 0 profile metadata to <name>@<domain> so that others know that the domain is not lying about the association, and know where to look to perform the identification.
With this service, we have registered Nostr identifiers for several accounts, including:
- Block Open Source: opensource@block.xyz
- Cash App: _@cash.app
This ensures that those who subscribe to their content can trust that they are associated with Block and its brands.
A similar level of trust applies to employees who have registered a <name>@block.xyz identifier and have set the identifier on their Nostr profile metadata.
Conclusion
We encourage other organizations to have a presence on Nostr. Those that do should consider implementing the NIP-05 specification by serving /.well-known/nostr.json from their domain so that trust in their company Nostr account(s) can be established with their customers.
