Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
feat: wot core service #642
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
base: main
Are you sure you want to change the base?
Uh oh!
There was an error while loading. Please reload this page.
feat: wot core service #642
Changes from all commits
46a6e18a104d9b65977a847b2fc6File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this dedup in memory is unbounded, so for a popular user following many other usrs this can cause Nostream to get OOM-killed
In these scenarios, we are better off using a bloom filter, and use streams to process the information so the amount of memory used is manageable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking on a more robust stream based approach to keep memory bounded as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the amount of memory used by this function will also be quite significant, would it be a better choice to try and build the graph using PostgreSQL and use queries instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One option to bound the in-memory footprint without switching to PostgreSQL: cap the
followerCountMap at a configurable max size (e.g. 100k entries). Once a pubkey's count reaches minimumFollowers we stop incrementing, and once the map hits the size cap we stop adding new keys entirely. At 100k entries that's ~15 MB worst case, predictable and manageable. The tradeoff is that pubkeys encountered after the cap is hit get silently excluded, but for most relay operators that's acceptable since the most-followed pubkeys in the network will naturally appear first (only consideringfollowerCountMap because Bloom filter + streaming is being implemented to make dedup memory bounded).That said, the PostgreSQL approach is architecturally cleaner, event_tags already has kind-3 data normalized and indexed, so a GROUP BY + COUNT query runs entirely in the DB and returns only the final trusted pubkey list to Node. Zero accumulation on the Node side and exact dedup via DISTINCT.
The one tradeoff with PostgreSQL: it can only trust pubkeys whose kind-3 events have actually been relayed through this nostream instance, whereas the external relay fetch pulls from damus.io, nostr.band etc. regardless of what's been published here.
Happy to go either direction!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should go with PostgreSQL (or Redis for caching) so that we don't have potential OOM issues, introduce artificial caps (100k limit), or surprises (silently excluding a pubkey). Imagine a new pubkey who is just followed and falls outside the cap: this user will remain outside, and the operator will think the relay isn't working.
If the kind-3 events from seed relays are inserted into our database this trade-off goes away. By the way, we have a static mirroring working implementation. Can it be re-used for WoT? It already connects to other relays and fetches events.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.