Why your Nostr identity is portable (and why it matters)

If you have used Mastodon, Discord, Twitter, or any centralized social platform, identity portability is not the default. Your account belongs to the platform. Moving it means asking the platform to cooperate with the transfer; often they do not.

Nostr flipped this. Your identity is yours, on your device, and moves with you because it never lived with a service in the first place. This article explains what that actually looks like in practice.

TL;DR. Your Nostr identity is a cryptographic key pair you own. Every Nostr client accepts the same keys. Switching clients is paste-the-key, done. Your followers, posts, profile, and reputation all follow the key because they are indexed by the pubkey, not by any client.

When you are ready, grab your @nostr.blog address →

What "portable" means concretely

Five specific properties.

1. Your keys work everywhere. Any Nostr client can use them. Not "most" clients; every protocol-compliant client. Paste your nsec into a new client and you are logged in. No conversion step.

2. Your followers find you automatically. They follow your public key, not your client or your username. When you switch clients, they do not have to do anything. Your next post from the new client appears in their feed like any other post.

3. Your profile metadata travels. Your display name, bio, avatar, banner, NIP-05 identifier, Lightning address: all signed events on relays. Any client reads them from relays when it sees your pubkey, regardless of where the profile was originally created.

4. Your post history persists. Every post you have ever made is stored on the relays you published to. Those relays serve them to anyone asking for events by your pubkey. A new client connected to the same relays immediately sees your history.

5. Reputation is pubkey-scoped. If you are known as a thoughtful commenter with 500 followers, that reputation attaches to your pubkey. Switching clients does not reset it.

What is not portable

For completeness, the boundaries.

App-specific settings. Your mute list and theme preference might be stored differently in different clients. Some clients use NIP-51 to sync mute lists across apps; some do not. Individual client preferences usually do not port.

Draft posts. If you have a half-written post in Client A, it does not magically appear in Client B. Drafts are local.

Cached UI state. What you scrolled past, what you marked as read, what conversations you expanded. Each client maintains this independently.

Lightning wallet balance. Your wallet is a separate system from Nostr. If your Nostr client has a built-in wallet, the wallet does not follow your key to other clients; you would need to withdraw and redeposit or use NWC pairing.

Notifications. Your push-notification setup is per-client. Moving to a new client starts fresh notification registration.

Some of these are legitimately not portable (local drafts are always local). Others are portable in theory and not in practice because the NIPs exist but adoption is uneven.

What portability enables

Three practical workflows that portability makes possible.

Run multiple clients simultaneously. Daily driver on mobile, long-form writing on Habla, occasional desktop use on the web. Same identity everywhere. Post from any one; the post is "yours" everywhere.

Switch clients when a better one arrives. A new client ships with features you want; you try it without losing anything. If you like it better, you migrate your primary use. If not, you go back. Zero switching cost.

Test clients before committing. Try five clients in a week. No waiting for imports, no friction, no lost content. The cost of exploration is essentially zero.

Survive a client dying. If Damus shut down tomorrow, every Damus user would switch to another client in five minutes. The network would not lose users; only one client would lose users.

None of these are possible on centralized platforms without friction. All of them are trivial on Nostr.

The mechanism, briefly

Identity portability works because three things are true.

The identity is a cryptographic key pair, not a database entry. There is no platform database to migrate from. The keys exist on your device.

Events are signed by the pubkey, stored on relays. Any client asking "give me events from pubkey X" gets them. The client is interchangeable; the pubkey is canonical.

Follow lists are also signed events. Your follow list (kind:3 event) is published to relays like any other post. A new client fetches your kind:3 event from a relay, reads your follow list, and displays the timeline based on it. The follow list is not stored in the client; it is stored on the network.

These three together make the client a thin layer on top of the network. Replacing the layer does not replace the network.

Switching clients: the concrete steps

A universal procedure.

1. In your current client, find "Account settings" or similar.
2. Look for "Export private key" or "Show nsec." Reveal and copy the 63-character string starting with nsec1.
3. Open the new client.
4. On the welcome screen, choose "Log in with existing account" or "Sign in."
5. Paste the nsec.
6. Your identity, followers, profile, and posts appear immediately.

Step 5 might require a passphrase in some clients (optional password for the stored nsec). Step 6 might take a few seconds as the new client fetches your data from relays.

Total elapsed time: under two minutes for a user who knows where to find the nsec.

Portability across platforms

The portability is not only across clients on the same platform. It works cross-platform too.

• Start on iOS Damus, switch to Android Amethyst: paste the same nsec.
• Start on a web client, switch to a desktop client: paste the same nsec.
• Start using client A from your phone, log into client B from your laptop: same identity on both.

The operating system does not matter. The device does not matter. The key does.

What this means long-term

The implication over years is significant.

You can commit to Nostr without committing to any specific client. The clients compete for your use; they do not trap it. If the best Nostr client in five years has not been written yet, that is fine; you will switch when it ships.

You can also not lose your reputation when a client dies. Platforms go through lifecycle events; Nostr clients will have their own. Your account's value does not depend on any one of them.

This is a durable property that compounds over time. Users who have been on Nostr for three years have tried five different clients; their accounts are unaffected by the churn.

The closest analogy: email

Compare to email.

Your email address is alice@gmail.com or alice@yourcompany.com. You read it in Gmail's web interface, Apple Mail, Outlook, Thunderbird, or a dozen other clients. Same email; different programs.

Switching email clients is unremarkable because the protocol (IMAP/SMTP) and the identity (your email address) are separate from the client. The client is a view on the inbox.

Nostr is the same pattern applied to social. Your identity is the key pair; the protocol is Nostr; the client is a view. Switching clients is as routine in Nostr in 2026 as switching email clients was in 2003.

What portability does not solve

Honest counter-list.

Key loss is still permanent. Portability means your identity moves with your key. It does not mean the identity survives without the key. Losing your nsec loses the account; no client portability saves you.

Audience growth still requires posting. Portability lets you change tools; it does not give you followers. Building an audience is the same work on Nostr as on any other social network.

Content discovery is client-dependent. Switching to a client with weak discovery does not magically teach it where to find your content. You might see different things in different clients because they query different relays.

These are not failures of portability; they are properties of the rest of the system.

The rule to remember

Your key is the account. Everything else is a view on the key. Back up the key; everything else is replaceable.