Thread

i think just returning the raw nostr.json is the simplest solution

The API should return a “bulk-allowed” field before any bulk queries are made.

Yes, but there are legitimate reasons why a NIP-05 service provider might not want to do that: - Doesn’t scale. Imagine if there were a million users - Privacy reasons. An organization may not want to reveal the entire directory to protect its users. Popular providers already don’t return the raw nostr.json.

nostr:npub1zga04e73s7ard4kaektaha9vckdwll3y8auztyhl3uj764ua7vrqc7ppvc nostr:npub18ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424 nostr:npub1q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p

classic reason why to add an openapi REST interface that has a paginated, cached index result list of pubkey -> user@example.com list then you index it periodically and queries are cheap.

also, i think this whole idea is dumb because nip-05s don't really prove anything, and queries for follow lists are already supported just fine

if the nip-05 name is needed, request it on demand of the display code that renders your graph or whatever way it's being done. there is also, other than that, the more useful point from the user's kind 0, and you can request them in batches easily

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

True. Maybe the /.well-known/nostr.json route without query parameters can return the bulk allowed field. If it already lists all identities, then the client doesn’t need to make extra queries. If it doesn’t and that field is set to true, it can make the bulk query.

Honestly, I’d prefer if the worlds of NIP-05 and WoT never mixed. I’m not against a bulk API for querying NIP-05 identities to make clients' lives easier. But if any clients are "DDoSing" NIP servers just to build a follow feed, then the client code needs some optimisation and devs need to start behaving like good citizens (leveraging caching, pacing queries, doing lazy NIP-05 on demand, etc). I don’t care how popular a client is, if it doesn’t behave, it will be rate-limited.

I agree. My implementation is naive and needs work. It does cache and lazy load on demand already, but it doesn’t pace its queries if there are a lot of them. Still, I hope the bulk query proposal will be adopted.

I feel that. you could shard today by subdomain I guess. but it makes sense to have a more structured access to this data, I agree. pagination and query would make sense and align with the REQ specs.