Nostr Web Client

Alright nostr devs. I need a little help. How do you all go about searching for user/display names? What kind of filters would that need to be in the req? Is it a multi-faceted approach? I have confused myself now on this one.

I know a note has a display_name. I want to pull down any and all notes within X date or parameters with display name of ODELL or whatever...

#ASKNOSTR

Five 11mo ago

Filter:

Nip01 describes how to construct such a filter with kind 0, since and until fields. After that you just match content of downloaded events.

A different approach is to search for human readable strings on relays which support [nip50](https://nostr-nips.com/nip-50) but that is not yet widely adopted afaik. You could try nostr.band relay e.g. See nostr.watch for nip support and other metrics of different relays.

Relays:

You can't strictly get _any and all_ notes in nostr because you would have to go to and access each and every relay there is, which is unfeasible. You have to select some reasonable relays to your use cases.

In your case I would hit some well-known metadata relays like purplepag.es .

Fields:

As to the name and display_name, there are different nostr apps using different conventions for this. Best-off you check both. Also you can check well-known sdk-s like [NDK](https://github.com/nostr-dev-kit/ndk) or [rust-nostr](https://rust-nostr.org/) how they go about this and other fields/tags of nips.

Reply to this note

Please Login to reply.

Discussion

Liberty Farmer 11mo ago

Thanks! It appears I am doing it correctly, just must have an issue somewhere.

I think an issue I am having issues is how to grab all profiles on a relay without being insanely taxing.

Unless I am reading this wrong, I would need to grab all profiles from the relay, then sort one by through the profiles for display_name matching?

That doesn't seem feasible from a relay, maybe I am still confused?

Five 11mo ago

You are right assuming it is not very efficient to try to find _all_ profiles matching one name(e.g. odell). In the metadata case you cannot use a tag in your filter which leaves you the only option to use kind 0 and that is a lot of events even from one relay to sift through.

On the other hand, tag filters are restricted to one letter (e.g. "#e") type of queries for obvious indexing performance reasons. There is no "#n" tag to query for because it doesn't have a special treatment in profile metadata fields, I don't know the reason why(maybe it's there in some nips discussions).

What most devs do is that they have a logged-in current user in their app usually which means they can by default grab a follow list of this user and perhaps also extend that with some web of trust algo into an extended network of trusted pubkeys. This could be on the order of 10 thousands of pubkeys. If you only grab metadata for these (and maybe defer some fetching into the future to gradually download these after login with time and also use some caching) and that will be most likely a feasible task to do.

Not everyone uses web of trust so you can even just rely on direct follows, its up to you.

So it is important in nostr to do smart queries related to the context your user needs or might soon need, because you can be drowning in events or get substantial lags and disconnection issues pretty soon if you make wrong/unreasonable decisions.

The takeaway is, there is no global on nostr so you need to adjust your app design and expectations to reflect this reality.

Liberty Farmer 11mo ago

Appreciate it. I get that there is no one source on relays, etc.. I am just confused at how the major clients perform this search in a blink of an eye. Amethyst, damus, primal, etc.. It literally takes less than a half a second.