You mean the person creating the pack would already know and add them as nprofile during creation... Hmm I don't think most people can do that
Discussion
The pack would have to store that info then...
when you paste an nprofile to add it to the pack, it would get a relay from inside the nprofile and add it as a hint to the p tag. nprofile is pubkey + relays bech32 encoded.
If the user is adding an npub you could attempt to fetch their relay list from a bootstrap relay list. You then would take one of their relays and add it as a hint
If the user types a nip05, you can try to get a relay from their nip05 data and use that as a hint (my nip05 has a demo of this). If there are no relays on their nip05 you could try to fallback to the method in the previous paragraph
Then as a client i have a diverse set of relays based on everyone in the follow pack to start with. This would naturally decentralize the network as groups onboard their friends to different corners of the nostrverse.
Thoughts nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 ? Seems like this could be the way to scale outbox ?
You can have a relay hint for each tag in kind:3 follow lists, some clients have it there, there is no reason why you can't have the same for the tags in the follow pack.
But you can't just add all these relays indiscriminately into a flat list and start querying them all -- or maybe you can, but that's very inefficient. It's better to have always a handy list of 2 or 3 relays that are "optimal" for each pubkey and only query their posts from those.
The best way I came up with (well, more reasonably I stole the idea from nostr:nprofile1qqswuyd9ml6qcxd92h6pleptfrcqucvvjy39vg4wx7mv9wm8kakyujgua442w) is to have a local database (see https://github.com/nbd-wtf/go-nostr/blob/master/sdk/hints/interface.go) that associates relays with pubkeys that tracks the last timestamp we saw a hint from for that specific pubkey on that specific relay. Hints can come from other people's event tags, nprofile and nevent codes seen in the wild, nip05 and nip65 relay lists, then there is also a timestamp for the latest successful event fetched from and the last attempt.
There are different weights for each of these hints such that when we add them all up the nip65 list will get a higher score, but failed attempts will get heavily discounted so if a person stops publishing on a relay but we keep trying to get their posts from there eventually that relay will lose score.
The nprofile or event tag hints have very little weight but they serve at least to point to relays we can target briefly if the others stop working so clients can recover even from the most brutal forms of censorship.
I tried to illustrate that process at https://how-nostr-works.pages.dev/#/pathological
I like this