Giszmo
commented
2 years ago When a profile is selected, the following should happen:
- update the in-group store
- add the selected profile's follows into the first level
- add those profiles' follows that are not the selected or first degree follows into the second level
- ...
The store probably needs a function to return the degree of a pubkey so it can display it quickly.
This is an idea of mine and not used in any other nostr client so far. My thesis is that we can store the 10k most relevant profiles (later we might have to tweak how to find them but so far there are no 10k profiles in total in all of nostr) and show the user only what happens in his proximity. If he follows 10k accounts, the follows of his follows are irrelevant. If he follows just one user who himself follows just two, he might see 8th degree follows' as in-group, too.
So #13 is just about compiling this list and keeping it ready, probably as a store. Downloading events is not required in this scope. Just work with what's downloaded already. The code for downloading events doesn't work account by account but considers all own accounts at startup and gets updated with every startup, so just assume the follows lists in IDB are up to date.
You might want to re-use part of the code from the logic that downloads relevant events as it constructs the n-th degree follows list already.
louishuddleston
Currently all own accounts get assigned a degree:0, their follows that are not own accounts get assigned a degree:1 and their follows are degree:2 etc. This logic is relevant for the SharedWorker to know which events to download from relays but follows might be distinct between own accounts.
It's probably most efficient to implement a store of relevant accounts aka "in-group" where other components can quickly lookup which author to prioritize over another or which to disregard completely.