#
Requests
low level
Relay Misbehavior
Relays can misbehave and return events that do not match your query filters.
#
Usage Example
final response = ndk.requests.query(
filters: [
// Define a filter for the query
Filter(
// Query for fiatjaf npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
authors: [
'3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d'
],
// Query for text note events (kind 1)
kinds: [Nip01Event.kTextNodeKind],
// Limit the results to 10 events
limit: 10,
),
],
);
int eventCount = 0;
// Process the events as they arrive
await for (final event in response.stream) {
print(event);
eventCount++;
}
#
When to use
Requests should be used when no other use case fits your needs.
There is .query and .subscription representing the nostr equivalent, .subscription should only be used when absolutely necessary. Many relays limit the amount of simultaneous subscriptions.
#
Relay Authentication (NIP-42)
Some relays require authentication before serving requests. Use authenticateAs to specify which accounts should authenticate:
final account = Account(
pubkey: myPubkey,
type: AccountType.privateKey,
signer: Bip340EventSigner(privateKey: myPrivkey, publicKey: myPubkey),
);
ndk.accounts.addAccount(pubkey: account.pubkey, type: account.type, signer: account.signer);
final response = ndk.requests.query(
filter: Filter(kinds: [4], authors: [myPubkey]),
authenticateAs: [account],
);
#
Use cases
- Multi-account clients: Fetch private data (DMs, encrypted content) for multiple identities in a single query
- Account aggregation: Apps managing several accounts can authenticate all at once
- Seamless account switching: Pre-authenticate multiple accounts to avoid delays when switching
// Authenticate multiple accounts at once
final response = ndk.requests.query(
filter: Filter(kinds: [4], authors: [user1Pubkey, user2Pubkey]),
authenticateAs: [account1, account2],
);
If authenticateAs is not specified, NDK falls back to the currently logged-in account.