The Case for Custodial Nostr: Why Teams Should Stop Fighting the Lost War

原始 JSON

{
  "kind": 30023,
  "id": "9a74c4af754d16c3e5a00dfcd20bf642748d0ff290ddd1b99e3b9cef46ccae17",
  "pubkey": "b7ed68b062de6b4a12e51fd5285c1e1e0ed0e5128cda93ab11b4150b55ed32fc",
  "created_at": 1777543606,
  "tags": [
    [
      "d",
      "da49098b0bf0af5d"
    ],
    [
      "image",
      "https://image.nostr.build/6bf6b553b48bd9850366d87e78efab6d91691a2469be5c2523d9d52e03c26df8.jpg"
    ],
    [
      "title",
      "The Case for Custodial Nostr: Why Teams Should Stop Fighting the Lost War"
    ],
    [
      "summary",
      "Organizations already delegate key custody internally. A server-side Nostr client with permission management would be faster, stabler, and more honest than relay-dependent remote signing hacks."
    ],
    [
      "published_at",
      "1765896380"
    ],
    [
      "t",
      "austrian-economics"
    ],
    [
      "t",
      "freedom-tech"
    ],
    [
      "t",
      "nostr"
    ],
    [
      "t",
      "nip-46"
    ],
    [
      "t",
      "keycast"
    ],
    [
      "t",
      "relay"
    ],
    [
      "t",
      "self-sovereignty"
    ],
    [
      "t",
      "key-management"
    ]
  ],
  "content": "The Nostr community has a problem it refuses to name. Every few months, someone builds another elaborate contraption for team key management, and every few months these contraptions fail to gain traction outside a small circle of enthusiasts. The pattern is unmistakable: NIP-26 delegation got deprecated, nsecBunker remains a niche tool for technical users, Amber works for individuals but requires your phone to be perpetually online for team use, and Keycast, despite being well-engineered, inherits all the latency and fragility of the NIP-46 architecture it builds upon.\n\nThese solutions struggle because they are solving the wrong problem. They attempt to preserve individual self-custody principles in contexts where those principles create friction.\n\nConsider what happens when a marketing team wants to post from an organization's Nostr identity. With current solutions, an employee opens a client, which generates a signing request, which gets encrypted and sent to a relay, which delivers it to whatever device holds the nsec, which decrypts it, signs it, encrypts the response, sends it back through the relay, where the client finally receives permission to publish the event. This round-trip happens for every single action. Post a note, and the round-trip fires. React to something, and it fires again. Update a profile or fetch encrypted messages, and the same relay handshake runs each time.\n\nThis architecture made sense for its original purpose: allowing individuals to use their keys from multiple devices without exposing the nsec to each device. The relay acts as a communication channel between your phone (holding the key) and your laptop (running the client). For personal use with reasonable latency tolerance, it works.\n\nBut teams are multiple people sharing one identity, a different arrangement entirely from one person using multiple devices. The threat model is entirely different. An individual using NIP-46 is protecting their key from potentially compromised clients on their own devices. An organization using NIP-46 is protecting its key from its own employees, which is absurd, because the organization has already necessarily trusted those employees with access to the identity's reputation and reach.\n\nThe honest architecture for team use is custodial: the organization runs a server, the nsec lives on that server, properly secured with standard operational security practices. Employees get accounts on that server with granular permissions: Alice can post kind:1 notes, Bob can post kind:30023 long-form articles, Carol can only react to existing posts. When Alice clicks \"post,\" the server signs the event locally and publishes it to relays. The round-trip disappears. Signing has no relay dependency. Latency reduces to ordinary network propagation.\n\nWhen an employee leaves, the administrator revokes their account. That revocation takes effect immediately because it is a database operation on infrastructure the organization controls, not a token invalidation that must propagate through Nostr's relay network where changes propagate asynchronously.\n\nThe objection writes itself: this is custodial, and custodial is bad, the \"not your keys, not your posts\" axiom applied to publishing. This objection reveals the conceptual error driving current team solutions. The nsec in question does not belong to the employees. It belongs to the organization. The employees never had sovereignty over it. They were always operating under delegation from an authority that could revoke their access.\n\nCustodial access for employees is how every organization has operated since the invention of organizations. When a social media manager posts to a company's X account, they do not hold the account's credentials in a personal hardware wallet. They log into a system that grants them permissioned access to post on behalf of the company. When they leave, their access gets revoked and the company's account continues unchanged.\n\nThe entire corporate social media industry operates this way. Hootsuite, Sprout Social, Buffer, and dozens of other tools provide team management for social accounts, and none of them pretend to offer employees sovereign custody of the accounts they manage. This would be nonsensical. The account belongs to the organization, which delegates operational access to employees and can revoke it.\n\nNostr's architecture makes this pattern cleaner than traditional social media. On X, if a departing employee disputes their termination, there is always the awkward possibility that they retained credentials somehow, or that revocation failed, or that the platform's access control has bugs. On a self-hosted Nostr team server, the organization controls the infrastructure entirely. If an employee is terminated, their database record gets flagged and no subsequent requests from their session tokens will result in signed events. The nsec never left the server, so the attack surface collapses: no credential to leak, no relay-level revocation required, no dependency on third-party systems functioning correctly.\n\nThe speed advantage compounds with scale. Consider a news organization that wants to publish breaking news to Nostr. With current NIP-46 solutions, every publish involves relay round-trips for signing, then additional relay connections for actual publication. Under load, with multiple reporters filing simultaneously, the signing relays become bottlenecks. With a custodial team server, signing is a local cryptographic operation taking microseconds, and the only network latency is publication to content relays, which would be required regardless.\n\nPermission granularity improves as well. NIP-46 was designed for personal use and treats permissions as a binary: either you can sign events of a particular kind, or you lack that permission. A purpose-built team system can implement fine-grained controls: posting only during business hours, mandatory review for posts mentioning certain topics, rate limits per employee, audit logs tracking who posted what and when. These features would be baroque to implement over NIP-46's remote signing protocol but are routine in a server application with a proper permission system.\n\nThe architectural honesty here matters beyond efficiency alone. Current solutions create a false impression of employee sovereignty while requiring trust at multiple points: trust that the NIP-46 signer is correctly configured, trust that relay connections are stable, trust that tokens are properly scoped. A custodial system makes the trust model explicit. Employees trust the organization, which controls the server and holds the key. The trust model is explicit and the indirection is gone.\n\nNone of this applies to individual users. If you are a person managing your personal Nostr identity, you should absolutely use a signer like Amber or nsec.app. Your threat model is real: clients you install might be compromised, and services you log into might be malicious. Your key represents your personal reputation. Self-custody solves your actual problem.\n\nBut if you are an organization, your \"key\" represents a legal entity that already operates through delegation and revocable access grants. Your employees do not have sovereign claims to your corporate identity, and pretending otherwise in your technical architecture adds complexity for no gain.\n\nThe path forward has a clear shape. Someone builds a Nostr team client designed from the ground up for organizational use. The server runs on infrastructure the organization controls. The nsec is stored encrypted at rest with proper key management. Administrators create employee accounts with granular permissions through a web interface, sign events locally, and publish directly to relays. Everything gets logged for audit purposes, and employee offboarding is a single database flag.\n\nThe technical work is tractable. Convincing a community steeped in self-custody ideology that custodial architecture is appropriate for some use cases is the hard part. That ideology emerged from Bitcoin, where the stakes were financial and the custodians were often untrustworthy third parties. Nostr inherited the ideology without examining whether it applied to organizational contexts where the custodian is the organization itself.\n\nThe custody question exists on a spectrum defined by who you are protecting the key from. Individuals need protection from compromised clients. Organizations need protection from departed employees. These are different problems with different solutions.\n\nCurrent Nostr team tools are like using a hardware wallet to manage petty cash. A custodial team server is the obvious tool for the job, and building one would do more for organizational Nostr adoption than any further refinement of remote signing protocols.",
  "sig": "1b27b757a69433b4fc84f9c8ca16e05b1d2685cc5e41cf48afa71adbeecadf1783adbd872969894e3b7af51dc5e5f6530264c8408a1164ba1bcab61a31b691d9"
}