@Zapstore how is it that I'm getting a HTTP 500 error for my WoT? Aren't you calculating it locally? 
Login to reply
Replies (24)
Nope, it was always calculated on our server! It's next to impossible to do web of trust with good UX locally, that said it can (and should) be verified locally which I definitely will be doing.
This is what I run: https://github.com/zapstore/trustgraph
Also, with @Pip the WoT guy we are working on something. To be announced soon.
Ge
what a bit, soon something much better will land on nostr
Kind of interesting
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
fwiw, working in "stealth mode" is a dark pattern.
"Build in the open" beats "stealth mode" every day of the week.
💫
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: View quoted note →
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 @sandwich has a chart on this with nostr.watch relay monitoring. 
> It's next to impossible to do web of trust with good UX locally
??
agreed, stealth mode is lame
No you should spend weeks working by yourself on something that the team is already including in the next release
Collaborate whenever possible. Especially in a space like freedom tech.
There are likely too many people wrestling with the same problems, trying to build the same (or similar) things in isolation.
fair point, but I've already shared my ideas in written form.
So are you in stealth bc you don’t want people copying your ideas or bc you have code that’s incomplete and there’s simply just no point for anyone to look at it (yet)? Or bc you’re not sure if you want to open source it? (Which is fine —it’s your work, you own it and it’s your prerogative whether to open source it or not.)
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.
because it's incomplete
Fair enough
It is perfectly fine to do something behind a closed door for a little while and then open up to public discussion.
The "closed" period will be a blip in the timeline of what we want to do, so in practical terms it doesn't matter
This is true, but freedom tech implies exactly that! You will get all sorts of approaches to solve different problems. Isn't that why we love free markets?
Yes absolutely! Often collab can be as simple as sharing plans and ideas. Doesn’t necessarily require working on the same codebase.
Yes, however sometimes this leads to eternal bikeshedding and I prefer spending that time building
Point well taken.
No Nostr client has 100% uptime either! Resiliency by decentralization and open protocol!
#winning
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.