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 @PABLOF7z @Don't Believe The Vibe ๐ฑ๐๐ @hzrd149
Login to reply
Replies (3)
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
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.
I am building @Vertex with @Pip the WoT guy to provide nostr profile and relationship information ("web of trust") in a usable and actionable format for clients to enhance their applications, such as spam prevention, ordering by relevance, getting follow recommendations, etc.
Every single service is a DVM and I am finishing drafts for a DVM-NIP that I want to propose, and get community feedback. @david
This is the way - not proprietary APIs.
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 @PABLOF7z @Don't Believe The Vibe ๐ฑ๐๐ @hzrd149
View quoted note →