Portable Social Graph
A portable social graph is the promise that your identity, follows and reputation do not have to live inside one app. In Nostr, that promise is real, useful and still limited by relays, clients and trust.
What portable means
A portable social graph means the people and relationships around an identity can outlive one application. On a platform, the graph usually belongs to the platform. You can export fragments, ask followers to move or rebuild elsewhere, but the platform controls the main database. In Nostr, the graph can be expressed through signed events tied to a public key.
That does not mean perfect portability. A client has to find the events. Relays have to store or serve them. Other clients have to understand the relevant NIPs. Spam and trust problems still exist. But the architecture changes the default. The graph is not born as a private asset of one company.
Identity is the anchor
The public key anchors the graph. People follow a key, not a username inside one app. A profile can change. A display name can be copied. A NIP-05 identifier can help recognition. But the public key is the identity line that clients can verify against signatures.
That anchor is powerful and unforgiving. Lose the private key and the graph cannot be signed from that identity. Leak the private key and the graph can be abused. Portability makes key management more important, not less.
Follows as data
A follow list can be a signed event. Clients can read it, interpret it and use it to build a timeline, discovery view or trust calculation. This is one of the most concrete ways Nostr differs from a platform graph. The list is not only a row in one private database.
Different clients can still make different choices. One client may show a pure following feed. Another may rank by web-of-trust signals. Another may emphasize communities, lists or recommendations. Portability gives them the raw social data; it does not force one user experience.
Relays as reachability
A graph is only useful if clients can find the events that describe it. This is where relays enter the story. If a follow list is published to relays nobody queries, it may be valid but practically invisible. NIP-65 relay lists and outbox discovery help clients learn where to look.
This is why portability has an infrastructure side. The graph is not locked into one client, but it still needs reachable relays, good hints and client behavior that respects those hints. The social graph is portable because of signatures and standards; it is usable because products do the discovery work.
Clients as interpretation
Clients interpret the graph. They decide how to show follows, mute lists, labels, trusted circles, recommended relays and profile context. This is where Nostr can feel richer than a single platform and messier than a single platform. There is no one graph experience. There are many ways to render signed relationship data.
For readers, that means a client switch is also a product switch. The same key and follow list can feel different through a different app. One client may make the graph social. Another may make it technical. Another may use it for search quality or spam defense.
The limits of portability
Portability is not the same as completeness. Deleted events may linger. Missing relays can hide history. Private messages have separate safety questions. Media may live outside relays. Some clients do not support every event kind. Some social meaning lives off-protocol in reputation, context and human memory.
There is also no universal guarantee that a new client will render an old graph well. Standards help, but product care matters. A sloppy client can make a portable graph feel broken. A careful client can make it feel natural.
Why it still matters
Even with those limits, the portable graph is one of Nostr's strongest ideas. It changes the bargaining position between user and app. A client has to keep earning attention. A builder can create a new interface without asking a platform for the graph. A community can move tools without asking members to abandon identity.
That is the real promise. Not that every move is effortless. Not that every relay keeps every event forever. The promise is that identity and relationship data can be signed, shared and reinterpreted outside a single owner. For an open social web, that is a major shift.
What portability feels like in practice
In practice, portability feels less dramatic than the slogan. You open a new client. The client asks for your public key or signer. Your profile appears. Some follows appear. Some posts load. Some replies are missing. The interface has a different mood. A feature you liked may not exist. A feature you never understood may suddenly make sense.
That partial continuity is still important. The identity did not begin again from zero. The app did not have to own the entire graph to show you something meaningful. The missing pieces also reveal the work still needed: better relay discovery, better event support, clearer media handling and more consistent client behavior.
A portable graph is not a teleportation device. It is a shared social data layer that independent tools can interpret. The more the ecosystem matures, the less the user has to notice the seams.
Why follow lists are not enough
A follow list is a powerful piece of the graph, but it is not the whole graph. Social meaning also lives in replies, mentions, zaps, lists, communities, mute choices, recommendations, profile context, NIP-05 domains, event history and reputation that people carry in their heads.
This matters because platforms often reduce portability to exporting a list. Nostr can do more because signed events can represent many relationship types. But even Nostr cannot make every social signal portable by default. Private context, deleted material, media files and off-protocol trust remain complicated.
The right expectation is layered portability. Public identity travels first. Follow lists and profiles travel next. Relay hints improve reachability. Richer social context travels when clients and standards support it. Human trust always needs human interpretation.
How portability affects moderation
A portable graph changes moderation because the app is no longer the only social boundary. Users can carry mute lists. Clients can interpret labels. Relays can enforce policy. Communities can choose specialized infrastructure. Web-of-trust tools can rank or hide based on social distance.
That distributed model can be healthier than one platform policy for every human context. It can also be confusing. A person hidden in one client may appear in another. A relay may accept events another relay rejects. A labeler may be trusted by one community and ignored by another.
Portability therefore needs visible controls. Users need to know which layer is acting: client filter, relay policy, mute list, label, trust score or missing data. Without that visibility, decentralization feels like randomness.
The business meaning of a portable graph
For a business or venue, a portable graph means customer identity and social proof do not have to start inside one app silo. A member can appear through a Nostr key, carry reputation, receive messages, connect a wallet, sign an action or join a community surface across tools.
That does not mean every business needs a public Nostr feed. The deeper opportunity is portable access. A profile, membership badge, event ticket, local relay, wallet connection or community list can become part of a broader identity layer.
The hard part is trust. Businesses need readable keys, clear signers, domain verification, privacy boundaries and excellent UX. The portable graph is valuable only when ordinary users can understand what they are carrying.
What a client reconstructs
When a user opens a client, the client is reconstructing a social world from signed pieces. It may fetch the profile event, follow list, relay list, recent notes, replies, reactions, reposts, long-form events and other supported kinds. It may use relay hints, defaults, indexes or search services to find them.
That reconstruction is why two clients can feel different without either one being fake. One client may fetch more relays. One may support more event kinds. One may rank replies differently. One may hide spam better. One may have better media handling. The public key is stable, but the view is interpreted.
For a reader, this is the practical meaning of the portable graph. It is not a screenshot that looks identical everywhere. It is a set of signed social facts that different tools can rebuild into useful experiences.
What happens when a relay disappears
If a relay disappears, the user does not automatically lose the key. They may lose access to events that existed only there. Other relays may still have copies. A personal archive may still have copies. Clients may have caches. The damage depends on how widely the data was published and whether it was backed up.
This makes relay diversity practical rather than ideological. Publishing to more than one suitable relay can improve reachability. Keeping a personal or trusted relay can improve resilience. Using relay lists helps other clients know where to look. None of this means every event is permanent everywhere.
The portable graph is strongest when identity, relay selection, backups and client discovery work together. A key without good relay strategy can feel lonely. A relay without key portability becomes another silo. The value comes from the combination.
Why reputation is harder than following
Following is easy to represent. Reputation is harder. A person may be trusted because of old posts, code contributions, conference talks, zaps, references from respected people, domain names, project history or behavior across years. Some of that can be signed and queried. Some of it is social memory.
This is why Nostr cannot simply "port reputation" as if reputation were a file. It can port many signals that help reputation travel. It can let clients and communities interpret those signals differently. But human judgment remains part of the system.
A healthy portable graph gives readers better evidence, not automatic certainty. That is a more modest claim and a more durable one.
What portability does not promise
Portability does not promise that every app will support every feature. It does not promise that a deleted relay will keep serving old data. It does not promise that private groups become public exports. It does not promise that media files hosted elsewhere remain online. It does not promise that a lost key can be recovered by customer support.
These limits matter because slogans can overpromise. The right promise is narrower and stronger: the identity and signed public data are not owned by one client. Other tools can read, verify and build around them when the relevant data is reachable and the standards are supported.
That narrower promise is enough to change the social web. It gives builders and users a real escape hatch from app lock-in while keeping enough technical honesty to avoid disappointment.
Why the graph is not a file export
A portable graph is often misunderstood as a file export. Exporting contacts from one platform is useful, but it is still a platform action. Nostr changes the model because follows, profiles, lists and other social objects can be signed events that clients read directly from relays.
That does not mean the graph is a single neat file. It is distributed across events, relays, clients, caches and human context. A client has to reconstruct it. A relay has to serve it. A user has to maintain it. The power comes from shared signed data, not from a perfect download button.
This distinction matters for product design. The better client does not merely import and export. It helps the user see where their social data lives, how to republish it safely and how to recover the graph when one relay or interface fails.
Why relay lists are part of the graph
A follow list tells a client who matters. A relay list helps the client know where to look. Without relay hints or outbox discovery, a client may know the author but fail to find the author events. This is why relay metadata is part of practical portability, not just infrastructure trivia.
The reader can think of it like this: the public key says who, the follow list says whom, and relay information says where. All three improve the chance that a client can rebuild the social world in a new interface. Missing one of them makes the switch feel less reliable.
NIP-65 and related discovery work matter because they turn relay choice into portable metadata. That is a quiet but important step from "I have a key" to "my clients can actually find my world."
Portability and privacy tension
Portability is most straightforward for public data. Public profiles, public notes, public follows, public lists and public articles can move because clients can fetch and verify them. Privacy complicates the picture. Private relationships, hidden mutes, encrypted messages, local drafts and sensitive communities do not become safely portable just because they use Nostr.
This is a healthy tension. A graph that exposed everything would be dangerous. A graph that moved nothing would be useless. Good Nostr products have to let users decide which parts of identity and social context travel publicly, which parts stay local and which parts require stronger encryption or selective sharing.
For readers, the practical rule is simple: do not assume portable means public, and do not assume private means portable. Ask which event is being created, who can read it, where it is stored and whether another client can understand it.
Portable identity for creators and venues
For creators, the portable graph changes audience risk. A writer can build an identity that is not trapped inside one publishing interface. A podcaster can collect followers, zaps and replies across tools. An educator can be cited through public keys and long-form events instead of relying only on platform accounts.
For venues and communities, the same idea becomes local identity. A guest, member or customer can carry a public profile, payment capability, badge, event ticket or community relationship across different surfaces. This does not make every interaction public. It means the identity layer can be shared where it is useful.
The business opportunity is not a giant public feed in every lobby. It is portable recognition. A venue can know a returning member without owning the entire social account. A creator can know a supporter without begging one platform for reach.
Why portability needs boring reliability
Portability sounds exciting, but it becomes real through boring reliability. Clients need to fetch the right data. Relays need uptime. Signers need predictable prompts. Links need to resolve. Media needs to load. Backups need to work. Search needs to find known profiles. None of that is glamorous, and all of it matters.
This is where Nostr will either mature or remain a niche. The protocol gives the possibility of a portable graph. Product and infrastructure teams have to turn possibility into a feeling ordinary users can trust. A user does not celebrate portability when half the page is missing.
The reader should judge Nostr products by this standard: does the identity travel without drama, and when it does not, does the product explain why?
The graph as a set of claims
A Nostr graph is best understood as a set of signed claims. This key published this profile. This key follows these people. This key recommends these relays. This key reacted to that event. This key wrote that article. Clients assemble those claims into a social surface.
That framing is useful because it separates evidence from interpretation. The signed claim can be verified. The meaning of the claim still needs context. Following someone may mean friendship, research, curiosity, professional interest or a temporary test. A reaction may be serious or playful. A zap may be gratitude, promotion or support.
Portable social data gives clients better evidence, not automatic wisdom. Good products help readers interpret that evidence without pretending the protocol knows human intention.
Why graph portability affects search
Search becomes better when the graph is portable because social context can travel into discovery. A search tool can rank people closer to the reader, surface authors followed by trusted accounts, hide obvious spam or connect articles to the public keys that wrote them. The graph becomes a quality signal.
This is very different from a global keyword box with no social memory. Nostr search can use public events, relay hints, follows, zaps, labels and web-of-trust distance to make results feel less random. The danger is opacity: if the user cannot tell why a result appears, a decentralized search product can become another black box.
The best search layer will expose enough of the graph logic to earn trust. It will say, in effect, "Here is why this result matters near your network."
How portability can fail politely
Portability will sometimes fail. A client may not support an event kind. A relay may be offline. A media server may disappear. A profile may have stale relay hints. A list may be private or malformed. The question is whether the product fails politely.
A polite failure explains the likely layer. It offers a retry, alternate relay, raw event view, source link or next action. It avoids making the user feel as if their identity vanished when only one piece of retrieval failed. This is basic product dignity in an open protocol.
Nostr does not need to hide every failure. It needs to make failures readable. Readable failure is part of portability because it helps the user keep moving when one path is blocked.
