𤯠relays are trusted? This seems like a huge oversight.. they should not trusted at all. All it takes is one bad relay and you're saying damus will just show the content with no validation? Mind blown.
Discussion
It is not a huge oversight, it is a tradeoff that I made because rogue relays are non existent and the reduced battery drain and non-laggy scrolling performance is more important for most people. If a relay starts sending fake data people would quickly notice and you can just disconnect from that. I can trivially make this an option but I guarantee noone will enable it because its terrible unless we have a multithreaded refactor of the incoming events pipeline
I would never use a client that doesn't check sigs. It's the whole point of nostr messages is you verify them and you don't trust relays. I think this deserves a PSA. There are so many relays now I don't see how you can claim there are no rogue relays.. does amethyst do this too?
#[4] says its really taxing on phones.
might be ok once i have a multithreaded event ingress setup, but its a non trivial refactor and would definitely use more battery. Not saying I don't want to verify everything but i had it on before and you could barely even scroll the view.
In fact you already have to trust relays for a bunch of stuff.
But not even validating what you can seems a very bad idea.
If validating sigs is too hard for phones â then the protocol doesnât work for whatâs supposed to do â or at least phones arenât ready to support it yet.
I donât think it would be that easy to find out for end users. Esp. if most people are using Damus.
It should at very least check a random sample of sigs and have UI for verifying individual notes.
Are sigs really expensive to check, even with Schnorr batch validation?
Quite frankly I wouldnât have shipped the app without validating sigs. Kinda embarrassing.
Are all clients the same? The android one too?
And the web ones?
If thatâs the state of Nostr, then you shouldnât use it on mobile.
I always said Nostr relays were trusted third parties â and the trust model is essentially the same as with existing centralized platforms.
But not even checking sigs removes the one thing Nostr improved.
If you donât validate sigs youâre much better off just using Twitter.
Ya the thing is, you don't need to trust relays, you get a message from them and you verify the sig. Case closed. All the relay can do is send or not send, accept your event or not accept. Even if the relay has a man in the middle it doesn't matter, the sig won't match if there is any tampering.
BUT without signature validation this all goes out the window and we are back to square one. I am very surprised by this and I just looked at amethyst code and I don't see it checking either.. 𤯠doesn't take much imagination to see how easy it would be to fool the masses during this adoption phase and assume anyone's identity.
The web clients, they gotta be checking this right?!... Guess it's not very sovereign of me to not be aware of this, not read the code, and just assume it's a basic nostr principle in all clients to check sigs. Got some catch-up to do..
Quite frankly it makes it feel like a scam.
All the people hyping how Nostr uses tamper-proof messages and is decentralized, censorship-resistant yadda yadda, recommend you use apps that donât even check relays arenât lying about authorship of messages.
About trusting the relay for sending or not itâs a bit more than that.
Relay might seem to accept your event but only forward it to some people, or delay it, etc. there are numerous less obvious forms of manipulation.
This is so dramatic, i am not against adding this as an option. Whoever wants to turn it on can do so.
Sure. Nostr is going to change the world with JSONs with digital signatures.
But not validating the signatures is no biggie.
They are validated by the relays.
I'm sorry man, I'm not trying to rain on your parade. I don't even have an iPhone. I am just personally floored by this as signatures are what attracted me to nostr in the first place. It's like that PGP moment, we all finally have signatures, we finally convinced people to use them!! Am in the only one thinking this?
Mobile is very hard and I have no doubt someone will have to centralize an app to really provide a good mobile experience with push notifications and low bandwidth usage. What I did not expect was for the heavyweight clients we have now to skip sig checks. Half the clients I use connect to relays that I didn't even pick when they start.
I'm not even against it, it will just take some time to make it performant. Damus only connects to a set of relays you trust/vet and does not connect to random relays. It is not an unreasonable tradeoff in those settings and the perf/battery life gain is noticeable. I had it on originally until the perf hit was too bad to justify when the servers are already validating sigs. People should PR this if they think its a huge issue, I do not at this time but obviously this will not be true forever.
If you get a duplicate event that's already validated, you can toss it and skip validation. I don't know if that improves performance or if you were already doing that.
This looks relevant but also looks hard (unless some library already does it): https://bitcoin.stackexchange.com/questions/80698/schnorrs-batch-validation
Iâve been wondering why my batteryâs been draining so quickly lately đ
I added nostr event signature verification toggle in settings (verify, don't trust) feature request in Damus github board: https://github.com/damus-io/damus/issues/617
Added more long term multi-threaded refactor as well https://github.com/damus-io/damus/issues/618
What about having an optional signature check that users could initiate? A âVerify Message Signatureâ option when you tap into the details of a message.
Thatâs a good idea. Ideally should display a serious warning if the check fails auto-remove the relay that sent it, and resync everything.
Could also just automatically validate the sig when you interact with a note in any way (like, reply, repost, etc)
Fewer UI changes.
Adding a warning about adding non-trusted relays is also a good idea.
Related to the untrusted relays suggestion, Damus has a recommended relays box in settings.
Yes. But when you add non-recommended ones there could be a text explaining the risks.
The downside is most people will get scared and never add other relays. Well most people will never add relays manually anyway.
What would you tell the user who is adding a non-recommended/non-trusted relay?
E.g. âWarning, this is a non-trusted relay. You are trusting the relay to not alter nostr events transmitted to you. Cancel/Got it. Click to learn more.â
How many times do you display this pop-up - e.g. every time a new non-trusted relay is added?
Youâre still trusting relays to store and deliver the messages. Posting an invalid message is pretty easy to verify, itâs the crimes of omission that are harder to verify.
idea: make it verifiable on request (user taps a button to verify)
Everything comes down to trade offs.
Important that it is ultimately verifiable, and that if you require it you could use another client (if the option doesnât exist to turn it on/off).
An option to turn on signature verification for the people a user follows may be a good way to do it. That way mobile phones donât need to verify every signature on the global feedâŚ
In Nostr 2.0, users will be able to tell when a profile has been tampered with since hashing all the posts together matches the on-chain merkle root of that profile.
Instead of verifying the signature of each post, users can take a hash of the entire profile and make sure it matches the on-chain merkle root.
Computational Requirements: users become lightwallets, nostr relays becomes full-nodes.
Weâre already at nostr 2.0?
Things happen fast around here.
Apa itu bro?
That was quick đł
I just wanna post to you as my first post on Nostr! Yew
wait, I just got here
a.k.a The Bitcoin Web⌠đ¸ď¸đŠď¸
Itâs like Web5 on the frontend and Nostr on the backend. Users download merkle trees from nostr nodes and load them up as normal files into a browser or mobile app.
The on-chain merkle roots provide tamper-resistance for entire websites rather than just for profiles. Updating an entire website with an on-chain merkle root and tree hash is smaller than inscribing a single NFT. đźď¸
Essentially, itâs Web3 compressed on layer 2.
A few hashes in the taproot section underneath a normal bitcoin transaction can decentralize your entire website with user-verifiable tamper-resistance that doesnât require verifying the signatures of every individual action. â¤ď¸
Letâs face it, weâre LARPing if we arenât verifying signatures. This method will provide verifiable security for mobile without the costly burden of verifying one post at a time.
Our team will release this general purpose tool with the code for the Nostr GitHub. đ
Itâs like batched verification but even more compact.
#[7]
Posts are arranged in a merkle tree. You can validate the contents of someoneâs profile one merkle branch at a time, or you can verify the contents of the entire profile/tree at once if youâre not missing any of its posts.
That makes sense!
I was actually wondering whether its enough to batch Schnorr verify every N events to resolve performance issues on low-end hw. Strikes me as simpler (or are we doing this already?)
With this method, you donât need to verify the signatures of every post. It verifies the content of all the profileâs posts in one swoop with a hash that matches a tiny on-chain merkle root.
Well, #[8] added sig verify in amethyst today, and my phone hasn't melted yet. Very cool. đĄđ°ď¸âĄđ¤