Skip to content

Feature/vanish optimization#446

Open
vikashsiwach wants to merge 6 commits intocameri:mainfrom
vikashsiwach:feature/vanish-optimization
Open

Feature/vanish optimization#446
vikashsiwach wants to merge 6 commits intocameri:mainfrom
vikashsiwach:feature/vanish-optimization

Conversation

@vikashsiwach
Copy link
Copy Markdown
Contributor

This PR introduces a new is_vanished column on the users table to support a more efficient way of handling NIP-62 (request-to-vanish) checks.

Related Issue

Currently NIP-62 query the events table for active kind-62 records on every check.

Fixes issue #436

Motivation and Context

The relay have to check every pubkey for an active request-to-vanish by querying events.As events volume grows ,this becomes less efficient. So we introduced a is_vanished flag in users table for faster checks.

How Has This Been Tested?

  • Build/type check:
    npm run build:check
  • Unit tests:
    npm run test:unit (504 passing)

Types of changes

  • Non-functional change (docs, style, minor refactor)
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my code changes.
  • All new and existing tests passed.

@cameri
Copy link
Copy Markdown
Owner

cameri commented Apr 10, 2026

Are we missing the code refactor to use the new flag on the users table?

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a database-level optimization for NIP-62 “request-to-vanish” checks by introducing a persisted users.is_vanished flag and backfilling it from existing kind-62 events, reducing reliance on repeated events table lookups.

Changes:

  • Add is_vanished boolean column to the users table (default false, not nullable).
  • Backfill is_vanished = true for users with non-deleted kind-62 events and insert missing users rows for pubkeys that have active kind-62 events.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +15 to +29
await knex.raw(`
INSERT INTO users (pubkey, is_admitted, balance, is_vanished, created_at, updated_at)
SELECT DISTINCT e.event_pubkey, false, 0, true, NOW(), NOW()
FROM events e
LEFT JOIN users u ON u.pubkey = e.event_pubkey
WHERE e.event_kind = 62
AND e.deleted_at IS NULL
AND u.pubkey IS NULL
`)
}

exports.down = function (knex) {
return knex.schema.alterTable('users', (table) => {
table.dropColumn('is_vanished')
})
Comment on lines +9 to +12
FROM events e
WHERE u.pubkey = e.event_pubkey
AND e.event_kind = 62
AND e.deleted_at IS NULL
@vikashsiwach
Copy link
Copy Markdown
Contributor Author

Hey @cameri ! I made migration reversible (removed user inserts from events) and optimized backfill query using EXISTS. Also missing users issue is solved by adding lazy hydration for is_vanished

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants