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.
Five
npub16p…kfhdw
2025-01-31 21:04:35
in reply to nevent1q…guk9
Author Public Key
npub16p8v7varqwjes5hak6q7mz6pygqm4pwc6gve4mrned3xs8tz42gq7kfhdwPublished at
2025-01-31 21:04:35Event JSON
{
"id": "47f6d2f40f5e26b99482e223876a79fd40015ec9557c0235ed55199cb44adea3",
"pubkey": "d04ecf33a303a59852fdb681ed8b412201ba85d8d2199aec73cb62681d62aa90",
"created_at": 1738357475,
"kind": 1,
"tags": [
[
"p",
"e3aefda887252a72cee3578d33b2dcd90e9fe53b8bed6347ef5e26f74211adbb",
""
],
[
"p",
"d04ecf33a303a59852fdb681ed8b412201ba85d8d2199aec73cb62681d62aa90",
""
],
[
"e",
"e58b4d09b57f1e9241dc9318cebe7b55b937ca15bb51d3cbd44b0cf741f073ad",
"wss://nproxy.kristapsk.lv",
"reply",
"e3aefda887252a72cee3578d33b2dcd90e9fe53b8bed6347ef5e26f74211adbb"
],
[
"e",
"4a2b8ac5c2aed589f6e10074f497b7f73a26e78a952b264346cd164cabc03946",
"wss://a.nos.lol",
"root",
"e3aefda887252a72cee3578d33b2dcd90e9fe53b8bed6347ef5e26f74211adbb"
],
[
"t",
"e"
],
[
"t",
"n"
]
],
"content": "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.\nOn 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).\n\nWhat 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.\n\nNot everyone uses web of trust so you can even just rely on direct follows, its up to you.\nSo 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. \n\nThe takeaway is, there is no global on nostr so you need to adjust your app design and expectations to reflect this reality.",
"sig": "0ce5b56ca424cf118775dd51f3bcf42b44494335b6310db19006926fbed3e6263378495fab3479a98d6f09d6a00c65ad52ba38da994b4831968873a10c41e853"
}