Nostr Bookmark Backup Without Ever Touching a Private Key

Nostr breaks the sign-up pattern the other three networks share. There's no OAuth flow to build, because Nostr doesn't have OAuth. Identity there is just a keypair: an npub you can hand out, and an nsec that's meant to stay private. So Nostr support in Birdfeeder starts differently: sign up with X or Bluesky first, then paste your npub, the public half only, into Settings.

From there Birdfeeder reads your bookmark list off a handful of relays. Under NIP-51, that list is a single replaceable event, kind 10003 or 30003 depending on the client that wrote it, which means there's no pagination to walk through like there is with X or Bluesky. One fetch gets the current list as it stands right now, full stop, and every future fetch just gets whatever that same event looks like at that later moment.

The list itself is made of tags pointing at other events. Most of what I've seen in testing are e tags, direct references to a specific note, and those are what Birdfeeder imports today. a tags exist too, for addressable events like long-form articles, but they need a differently-shaped relay query than e tags do, and the one account I tested against never produced any, so support for those is logged and skipped rather than implemented against an untested case.

There's also a private variant of the same bookmark list: NIP-51 lets the content field carry an encrypted payload instead of plain tags. Birdfeeder doesn't decrypt that payload. Doing so would require the user's nsec, and Birdfeeder never asks for or stores a Nostr private key. An encrypted list is treated as empty and logged, not attempted.

Once the notes are in, they get the same treatment as everything else: full text stored in your archive, media pulled in, full-text search, and export to CSV, Excel, TSV, or JSON whenever you want a copy outside Birdfeeder entirely.