Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local Relay Model (nostrdb) #2041

Open
jb55 opened this issue Mar 12, 2024 · 2 comments · May be fixed by #2121
Open

Local Relay Model (nostrdb) #2041

jb55 opened this issue Mar 12, 2024 · 2 comments · May be fixed by #2121
Assignees
Labels

Comments

@jb55
Copy link
Collaborator

jb55 commented Mar 12, 2024

To switch to a local query model, we need to move away from trusting remote relays.

There are many issues with what we are currently doing:

  • We don't check to see if the results returned from the relay actually match the query we sent. This enables rogue relays to inject ads or other bad data. This is particularily bad in the gossip model, since users can force clients to make requests to evil relays outside of the user's configured relay pool.

  • Since we don't check signatures on all note types (only profiles), this would enable users to spoof DMs. This is technically possible today but is mitigated by some level of trust in the current mega-relays.

  • We have to spin off async processes parse note contents once we get them off the wire. Swift's concurrency model is decent but it is still kind of annoying to delay timeline insertion based off a bunch of asyncronous tasks.

  • Since we're currently inserting data into nostrdb already we technically are doing twice the amount of processing work for no reason

Switching to a nostrdb for local queries fixes all of these issues:

  • All notes in nostrdb are validated, so we don't have to worry about spoofing

  • We don't have to worry about relays sending bad data, because we only ever query the local relay which we know will always match the query we are executing.

  • Local subscriptions are notified only after we parse note contents, so we don't have to wait for async processing to render the note.

  • nostrdb is much more efficient at ingesting notes, so we will save CPU and battery.

  • Having notes locally will allow us to use negentropy for keeping nostrdb nodes in sync.

This is already implemented in Damus notedeck and android, now we need to overhaul Damus iOS to support this model. This issue is for tracking this!

Once we switch to this model we can begin work on adding support for the gossip model!

@jb55 jb55 added this to the 1.8 post Madeira milestone Mar 12, 2024
@jb55 jb55 added the nostrdb label Mar 12, 2024
@jb55 jb55 self-assigned this Mar 12, 2024
@jb55 jb55 linked a pull request Apr 8, 2024 that will close this issue
3 tasks
@jb55 jb55 changed the title Switch query pool to use nostrdb directly instead of remote relays Local Relay Model May 6, 2024
This was referenced May 6, 2024
@alltheseas alltheseas added tracking Tracking issues labels May 20, 2024
@alltheseas
Copy link
Collaborator

@jb55 to use this as iOS nostrdb tracking issue

@alltheseas alltheseas changed the title Local Relay Model Local Relay Model (nostrdb) May 20, 2024
@alltheseas
Copy link
Collaborator

@jb55 commits to "thursday & friday from now on to this"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

2 participants