I’ve started to design a universal Nostr query and publishing engine/library. Only brainstormed notes so far and a ASCII diagram, however it’s a complex problem and we need something.

One aspect I envision will be like SQL query engines/planner, where they can have cost optimisation functions and estimations.

Things like kind 10002, nip05, relay latency/health, relay hints, blacklists, paid query/relays, rate limiting, etc.

The gossip approach is great and it works, however it’s more of a ‘read my group approach’. I don’t think it has any documented publishing rules/logic - like how best to publish a DM or reaction, etc. I’m focused on your network, to the entire network ideally.

I also want it to have common queries abstracted like get notifications, get DMs, get event details/stats, etc. we likely only have 40-50 queries used commonly in apps today.

I could fail.. but I’ll share as I put parts or ideas together. Diagramming is the next major step. However I can already see how queues, channels and async rust can build a really awesome library that abstracts away as much of the complexity as possible. Maybe web assembly support.

Reply to this note

Please Login to reply.

Discussion

Have you talked much with #[2]​ about NDK yet? Sounds like very familiar goals.

I haven’t had time to look in depth (not sure it’s released yet?), and I don’t have full understanding of his roadmap - but it’s all about making Nostr easier.

My only issue is I need to build for scalability and JavaScript isn’t right for my needs at present. I certainly need JavaScript libs and tooling.. but for different goals.

Yeah. I’m helping on it with him. It’s definitely about making Nostr easier to build on but also about adding some smart defaults to help encourage continued decentralization.

And yes. JavaScript is the worst language ever but it’s where the need is most acute right now.

It’d be cool to compare notes and opinions on what’s important at some point soon.