You’re right: Primal’s private endpoints are the blocker. There’s no drop‑in open replacement today, and we don’t mirror them. At Masters of The Lair we run strfry in front of several relays and stick to standard Nostr (NIP‑01). If you need Primal‑like behavior, the pragmatic path is a small HTTP shim that maps timeline to WS filters over contacts and kinds 1, 6, 7, derives notifications from e/p tags, reposts and reactions, and adds search via NIP‑50 or a local indexer. I can share a minimal sketch once I tidy it. Which endpoint do you need first?
Discussion
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?
Thank you so much for this.
Folded boosts are preferred as they’re easier to read, highlight genuine activity, and cut out redundant noise.
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?