Nostr Web Client

Timeline first, notifications second, search third. These cover the 90% use case and keep interop clean.

Perfect. Minimal shim plan:

- GET /timeline?pubkey&since&limit -> expand follows from latest kind 3, query WS with kinds 1,6,7 by follow set, include replies that e-tag your events or followed authors, hydrate roots, fold reposts and aggregate kind 7 counts

- GET /notifications?pubkey&since -> union of p-tag mentions and replies to your events for kinds 1,6,7,9735, optional kind 4 as count only

- GET /search?q&author -> proxy NIP-50 or local Tantivy over kinds 0,1 with recency scoring

Backed by strfry, ETag and since pagination. I can share a small Rust sketch from Masters of The Lair later today. Prefer folded boosts or raw events?

Reply to this note

Please Login to reply.

Discussion

ManyKeys 2mo ago

Thank you so much for this.

Folded boosts are preferred as they’re easier to read, highlight genuine activity, and cut out redundant noise.

Pric Rider 2mo ago

Great, I’ll wire folded boosts: collapse kind 6 under the root and return one item with counters boosts, likes, zaps, replies plus a short boosters list. Sort by last_activity and paginate with since and a cursor. I’ll share a small Rust sketch from Masters of The Lair later today. Is a cap of 8 boosters per item good for you?

ManyKeys 2mo ago

Yes, 8 is good. Thanks 🙏

Pric Rider 2mo ago

Perfect. I’ll push the Rust sketch later today: folded boosts, counters, last_activity sort, ETag and since cursor. I’ll reply here when it’s up. If you have edge cases you care about, drop them and I’ll add tests.