Skip to content

Instantly share code, notes, and snippets.

@blakejakopovic

blakejakopovic/nostr_client_anti_patterns.md

Last active March 22, 2023 09:15
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save blakejakopovic/1dbc1f0c51fa317594b23633d6c93988 to your computer and use it in GitHub Desktop.
Save blakejakopovic/1dbc1f0c51fa317594b23633d6c93988 to your computer and use it in GitHub Desktop.
Download ZIP
Nostr Client App Anti-Patterns
Raw
nostr_client_anti_patterns.md

Nostr Client App Anti-Patterns

With Nostr being an open protocol, and client apps being able to be developed by anyone, it's important that the client apps design around best supporting relays by minimising their client app impact. Remember, if your app has 10,000+ users, and the app's relay interaction code makes relays slower - everyone suffers.

Below are some anti-patterns (things not to do), that can help with relay performance, and ultimately make your client apps faster!

Please help build upon this list - we can move to a repo.. just add comments for now.

  • Updating a subscription too often (triggers new SQL queries)
  • Connecting to a relay multiple times (use a single websocket)
    • How can we best manage this with multiple open web app tabs?
  • Opening a websocket and not creating at least one subscription (instead connect on-demand)
  • If you disconnect from a relay, don't instantly reconnect (add random wait with some kind of increasing backoff time)
  • Gracefully disconnect (this helps servers free file descriptors faster, and allows for more new connections)
  • Overlapping subscription queries (you'll get dupe data - from each relay. Plan your subscription filters based on context)
  • Using Until and updating the subscription's until every x seconds/minutes (if you didn't use until and just used client logic to show events, you wouldn't trigger a server query and just stream the data instead)
  • Using the same relay list for all subscriptions and event publishing (e.g. home feeds, global, general queries, DMs, notifications, etc)
  • When implimenting a 'follow user selection' feature, not waiting until the user is finished before sending contact (kind 3) events. Instead, please wait until a user confirms their selection and send one event with updates.
  • Clients trusting relay subscription ids in responses (e.g. ["EVENT", "!!THIS_HERE!!", {EVENT}]). Instead clients should ignore the subscription id in messages received from relays and locally re-check which local subscriptions match the event, and process them. This prevents relays from sending extra data you don't want - like injecting ads or similar.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment