Rethinking Data Ownership in Nostr

Bringing Personal Data Servers to Nostr

Nostr has a problem: relays store and control the data. In contrast, in Bluesky’s AT Protocol, PDSs (Personal Data Servers) store and control the data. PDSs are personal storage servers that give users full control over their data.

Something similar could also be implemented in Nostr, such as personal relays that store only a user’s own content, while other relays simply carry the addresses and copies of those personal relays.

Advantages

1. Greater user control

   • Users control where their content is stored.
   • A relay operator cannot arbitrarily delete or censor your content because your primary copy lives on your own relay.

2. Reduced storage burden on public relays

   • Public relays would not need to store everyone’s posts indefinitely.
   • They could focus on discovery, indexing, spam filtering, and routing.

3. Better data portability

   • Similar to Bluesky’s PDS model, users can move between providers without losing their identity or content.
   • This aligns with the idea of self-sovereign data ownership.

4. Potentially lower censorship risk

   • If a public relay bans you, other relays can still point to your personal relay.

Challenges

1. Availability

   • If your personal relay goes offline, your content becomes unavailable.
   • Bluesky addresses this partly through hosting providers and account migration.
   • In Nostr, public relays could still cache or mirror data from personal relays, providing redundancy and ensuring content remains accessible even when a personal relay is offline.

2. Performance

   • Clients would need to fetch data from many personal relays.
   • Loading feeds could become slower unless there are caching or indexing relays.

3. Discovery

   • How do users discover the location of your personal relay?
   • Nostr would need a standard mechanism for publishing relay addresses.

4. Spam

   • Malicious actors could create thousands of personal relays.
   • Discovery relays would still need moderation and reputation systems.

Iroh Address instead of server relay address

If, instead of storing a personal relay address, Nostr stored an Iroh address, data would become far more portable. The address would remain the same even if a user switched servers or hosting providers, eliminating the need to update followers about a new relay location. It would also provide better synchronization across devices and replicas, making user-owned data more resilient and easier to manage.

With an Iroh-based design, the user’s profile would point to a content address or namespace rather than a specific server address. The data could then be hosted anywhere while retaining the same identifier.

Advantages

1. Portability

   • If you move from one server to another, the Iroh namespace remains the same.
   • Followers do not need to update relay lists every time you migrate.

2. Multi-device synchronization

   • Iroh is designed around synchronization between peers.
   • Your laptop, phone, VPS, and home server can all replicate the same data.

3. Reduced dependence on relay operators

   • Relays become discovery and indexing layers rather than primary storage providers.

4. Content persistence

   • Multiple peers can host the same data.
   • Losing a single server does not necessarily mean losing content.

5. Better fit for self-sovereignty

   • Users own their namespace and cryptographic keys rather than relying on a particular relay.

Challenges

1. Data discovery

   • Clients still need a way to discover where replicas of an Iroh namespace exist.

   • Nostr relays could store mappings:

     pubkey -> iroh namespace
     

2. Feed generation

   • Social feeds require querying millions of posts.
   • Pulling data directly from thousands of Iroh peers would be inefficient.
   • Indexing relays would still likely cache and index content.

3. Availability

   • If nobody is hosting the namespace, the data disappears.
   • You may still need “pinning” or replication services.

4. Moderation

   • Discovery and indexing layers would still decide what content to surface.

One Possible Architecture

User Key
    |
    v
Nostr Profile
    |
    +--> Iroh Namespace ID
                |
                +--> Phone
                +--> Laptop
                +--> VPS
                +--> Community Mirror

Meanwhile:

Iroh Storage Layer
        ^
        |
Indexing Relays
        ^
        |
Nostr Clients

Expose a local WebSocket service via the Iroh network using a ticket-based address

WebSocket-based application (like a Nostr relay or client) accessible via an Iroh address similar to dumbpipe or directly using code.

Approach 1: The “Dumbpipe” TCP Tunnel (Easiest)

WebSockets are essentially HTTP upgrades running over standard TCP connections. dumbpipe has built-in features to forward raw TCP traffic over Iroh’s QUIC network. This allows you to keep your existing Nostr app exactly as it is while giving it an Iroh address.

1. On the Server (Hosting the Nostr Relay): Assume your Nostr relay is running locally on port 8080. Run the following command to generate an Iroh ticket (address):

dumbpipe listen-tcp --host localhost:8080

This will output a long string (the Iroh ticket). This ticket is your “address.”

2. On the Client (Connecting to the Relay): Run the following command on the machine where you want to access the relay. Replace <ticket> with the string from the server:

dumbpipe connect-tcp --addr 0.0.0.0:8081 <ticket>

This creates a local “bridge” on port 8081 that tunnels all traffic through Iroh to the remote relay.

3. Usage: Point your Nostr client to ws://localhost:8081. The WebSocket handshake and all subsequent frames will be transparently forwarded over the encrypted Iroh connection to your relay.

Approach 2: Native Iroh Nostr Relay (Rust Implementation)

If you want to build a “true” P2P Nostr app without the overhead of a TCP tunnel wrapper, you can run the Nostr protocol directly over Iroh.

Advantages

1. No Server Costs for Relays: You can run a Nostr relay on your laptop or a cheap home server. Iroh handles the NAT traversal and hole-punching, meaning users can connect to it directly without you needing a public IP or a domain name.
2. End-to-End Encryption: All traffic is encrypted via QUIC/TLS by default, which is a strong selling point for a security-focused startup.