Nostr Web Client

nostr clients always have this tension between:

✅ verifying signatures (bad performance)

🙃 "trust me bro" (no checking)

I INTRODUCE TO YOU... FRACTIONS! 😂

Next version of NDK is shipping with SO many performance tricks and improvements that I have zero chance of remembering what they were when I write the release notes.

But one of them is that.. fractions.

Developers will be able to configure a ratio of events to verify on a per-relay basis. For example, you could say "only verify 10% of events coming from each relay"

The cool part is that I can also compare signatures coming from different relays for the same event so evil relays can be detected even faster and kicked out.

I will make it possible later to save state of the "reputation" each client perceives of a relay, so that a client can start talking to a new relay with a higher ratio (e.g. 1.0 = "verify everything") and slowly transition to trusting the relay more (i.e. verify 1% of events).

Reply to this note

Please Login to reply.

Discussion

elsat 1y ago

👀

Dan 1y ago

The best features are the ones that seem obvious after the fact. Well freaking done

PABLOF7z 1y ago

🫡🫡🫡

kuiperbelt 1y ago

fractional reserve relaying

walker 1y ago

Well, that’s neat.

the axiom 1y ago

Another thing you could do is load a bunch of events first and then later perform a BIP-340 batch signature verification on all of them together.

PABLOF7z 1y ago

that's a very cool idea; I just added async signature verification for performance, this fits great in that setup

🔥

fiatjaf 1y ago

I guess that's not a very big idea:

ismyhc 1y ago

Sounds cool! Have you measured the performance difference between checking signature and not?

In my nostr swift lib I did a quick test and seems like verifying signature takes an extra 2 milliseconds. I guess this can add up, but if it’s all done on background thread it shouldn’t be that big of a deal. Or maybe I’m just being optimistic. 😅

PABLOF7z 1y ago

yeah, I've done a lot of tests; it's, by FAR, the most expensive part of any full client I write.

fiatjaf 1y ago

Wrong: the most expensive part is getting yarn to work.

fiatjaf 1y ago

2 milliseconds is already too much I think, that's already worse than pure JS. With Wasm things drop a lot, native C + Swift should be even faster.

jb55 1y ago

verification so fast in nostrdb on multiple threads the perf hit is so small its no longer a concern. those poor js souls 🥲

fiatjaf 1y ago

The next step should be writing a browser engine in nostrdb so you can do everything in JS inside it.

jb55 1y ago

you joke but i’m already hooking up my C wasm interpreter to talk to nostrdb so you can script access to the local relay 😆

fiatjaf 1y ago

Have you thought about generating predefined UI components from wasm scripts? Simple things like input boxes and buttons that then trigger some action which then outputs a table?, I don't know. What I have in mind are the simple UIs you can write programmatically for Telegram and Discord bots, for example. They are very limited and yet people can very easily write powerful apps (bots) in them.

Could be standardized between different clients and then the actual layout would be different everywhere but the functionality would be the same.

fiatjaf 1y ago

But maybe this gets too complex too quickly and it's not worth doing. Or the scripts would be huge? Not sure if that's a problem.

jb55 1y ago

I have thought about these things but there are so many directions you can go with it. Just going to keep it simple right now: provide a simple way to query and provide the results to… something. Maybe a list. I dunno. Its more of an idea playground at the moment

Dawlat Moustafa 1y ago

Sounds a good idea.

ismyhc 1y ago

Yeah my initial test was run just via swift test case which doesn’t do any optimizations. Working on an actual benchmark. Will post soon.

fiatjaf 1y ago

Are you telling me we will have a big repo with reproducible comparable benchmarks between all Nostr libraries and languages for all the basic Nostr tasks TOMORROW?

ismyhc 1y ago

Ummmmm. Haha. No. But I will work towards building benchmarks for my swift nostr core lib.

mrclownworld 1y ago

This is the basic premise of auditing used in accounting and you can actually drop that number even lower to 1-2%

You might also add a list of “high priority” users based on follows or whatever where you verify all messages (the equivalent in auditing of testing everything over $10k or some similar amount)

bootlace 1y ago

Consider configurable faster, though reasonably acceptably situationally specific tiny bit less secure, verification algorithms?

Pedro 🧨 1y ago

Interesting!

Matt Terenzio 1y ago

I'm curious in what case that a relay with less than 100% verification would be acceptable or is that a normal occurence even for reputable relays?