Thread - Nostr Hypermedia

the nostr relay model is a double-edged sword, especially if your client needs to aggregate data from a bunch of pubkeys: dump pipes makes writing and running relays a breeze but dumps all the complexity to clients. now you don't need a backend but you do have to implement caching, storage and indexing on the client side with subpar primitives (at least on the web) just to get a half decent UX. i'm convinced that clients centered around relays are the sanest way to build apps: @Jumble and @chachi embrace this idea.

Replies (5)

il_lost_ 🛡️ 4 months ago

Is this for kind1 or in general? Is it easier for long form?

verbiricha 🛡️ 4 months ago

↩ replying to il_lost_

good question. it's the same problem for every app that tries to show content from the pubkeys you follow, regardless of the kind.

il_lost_ 🛡️ 4 months ago

↩ replying to verbiricha

so get the author kind 3, and the tagged ones kind 10002 (if it's microblog), after that you have to do something smart in the selection, you can use only the author ones for a short introduction, and after that recover

Niel Liesmons 4 months ago

+ @Zapchat + @Zapstore + ...

Garbage nsec 🛡️ 4 months ago

Also the question of why does Nostr even have relays in the first place. If you abstract away relays in the UI and your Nostr app still makes sense then chances are it should have been built on a traditional stack. But if abstracting away relays in the UI would make your app fall apart then you might be on to something.