I've been thinking about using https://github.com/mmalmi/nostr-social-graph in gitworhshop.dev. Perhaps downloading / refreshing dataset as a background task. I've not looked into the performance implications yet.
Discussion
what a bit, soon something much better will land on nostr
My gut feeling tells me that this stuff should be done in a nostr-native way, ie with DVMs or similar.
Each server we add is just a cobblestone of the path that will eventually lead us back to hell, so we either have to do it locally or with stuff that's easily and dynamically replaceable.
Thoughts? CC nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0dv4ph5 nostr:nprofile1qqsfnw64j8y3zesqlpz3qlf3lx6eutmu0cy6rluq96z0r4pa54tu5eqpz9mhxue69uhkummnw3ezuamfdejj7q6hdgd nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpr3mhxue69uhhxct5v4kxc6t5v5hxs7njvscngwfwvdhk6tcpzfmhxue69uhkummnw3e82efwvdhk6tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsk7wj75
Calculating a wot takes some time (can be done by DVM, yes) but sending a wot via native nostr event might turn to be too big in terms of size... Most relays have a max limit for a single event.
Completely agree.
No bitcoin mine has 100% uptime. That's impossible. Yet bitcoin has 100% uptime.
No nostr relay has 100% uptime. That's impossible. Yet nostr has 100% uptime.
If you, or a proprietary API you use, is in your critical path, you're doing it wrong.
#taoofnostr
#YESTR
Proton outage: nostr:note14l8raz93a2rug397wrmnpkh0nn0cv5yp2ezqs32rwudu2pta807qujfye4
Crowdstrike & MSFT outage.
On nostr we have sometimes NB outage, maybe primal aggregater outage (are there non-primal aggregators?), single relay outage, damis notification api outage, e.g. minibits zap failure to route, alby node etc..
Nostr uptime, LN uptime is 100% due to law of large numbers. Maybe nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx has a chart on this with nostr.watch relay monitoring. 
No uptime charts because I don't use an API or a database, only relays. So everything takes 100x as long, but is worth it in the end.
No Nostr client has 100% uptime either! Resiliency by decentralization and open protocol!
#winning
I agree. My intention was to build the graph client side, downloading the follow lists via relays slowly overtime as a background task. starting with the logged on user. It's potentially quite a lot of follow lists to cache and keep up to date. So maybe the idea of outsourcing it to a DVM has potential.
Once you allow people to target/publish 1 event in multiple communities (i.e. relays), you get a super high signal graph of your network for free, in the most efficient and targeted way.
An example, to answer some use case questions:
Danny the dev publishes a photography app release in a set of photography communities + a community that's all about using Kotlin for cool FOSS apps.
❓ What replies should an app display by default?
👉 the ones one the relays (communities) were this app release was targeted (and accepted!)
❓ What's a efficient and useful way to define and calculate the npubs in "Your Network"?
👉 following + contacts + active npubs in communities you yourself are active in.
You don't save everyone from every telegram group you're a part of as a contact, but that doesn't mean those profiles aren't epic useful for quick and targeted filtering use cases.
❓ What (photography) books should a book app recommend to Danny the dev?
👉 the books that are valued by his photography Network
How do you know what his photography network is? Danny can select the relevant communities in two clicks or you can fairly detect topics based on the tags/categories of the communities themselves.
How do you know what's valued? It's whatever is being zapped/replied to OR literally is being stored in the communities (relays) themselves.
❓ What apps should Zapstore recommend by default?
👉 similar to the previous use case, but with an extra focus on the app releases that are stored in the communities he's a part of
the efficiency in all of this is that all/most the info needed is stored (or is at least highly incentivized to be stored) by the communities (relays) the user is already connected to;