Pushed some updates to fix the downtime. Made some modifications to the table and the detail pages. Detail pages are undergoing a full overhaul to be seen in 0.3 release
Hey! Haven't written any guides during alpha, things change too quickly to maintain guides.
run `yarn docker:build && yarn docker:tag && docker-compose up`
Whoa, just checked the API access logs for the first time. Holy shitballs.
Anyways, the API is down for maintenance. ~5 minutes
Why use relay "aggregators" or "proxies" if you can just use the https://nostr.band/ relay that has everything?
single point of failure perhaps?
I've spent today refactoring `nostrwatch-js` and combing the logs on the daemons.
1. I found an bug in `nostrwatch-js` that caused problems for slow relays which would result in a latencies not being calculated correctly. This is an edge case, but I found 6 relays affected by this in production.
2. I found a bug in `nostrwatch-js` that caused write checks to fail for slow relays. (this is **not** related to paid relay write checks, those should fail)
3. I found a pretty big issue in the daemons, where the jobs overlapped after ~7 days of running. I haven't been able to identify if this caused any issues with data yet, but it definitely caused the daemons the crash periodically.
4. It is possible the improvements to `nostrwatch-js` mentioned above will resolve issues that some relay operators have reported related to Uptime, but cannot confirm with certainty at this moment in time.
I have long wanted to refactor `nostrwatch-js` (formerly `nostr-relay-inspector`, and have spent part of yesterday and today doing so. I also added features that are in line with the goals of `nostr.watch@0.3`. `0.3` provides more data to operators and completely refactors the relay detail page.
The improvements to `nostrwatch-js` will be rolled out to the daemons tomorrow and will be rolled out to nostr.watch with the `0.3` release or possibly as a patch to `0.2` if `0.3` takes longer than anticipated.
It shouldn't happen often. Nostr.watch manages hundreds of connections to relays client-side. It's tricky.
Actually, it is possible, just not yet.
😆
I am trying WalletOfSatoshi for now. I will still be using Alby for nostr web apps though.
Wish I had more time to take care of my node. Just checked and it's disconnected from my network and no quick fix it seems, I have to decide between nostr.watch and risk of closed channels (which are already paltry)
Honestly, it's amazing it took them this long.
My favorite part is that magnetic apparatus that is clearly affixed as insurance.
I'm getting a number of messages from operators of paid relays essentially asking how to game the system and have "write" indicators appear as green. A "green" indicator isn't earned, it's an objective measure of capability. If your relay isn't open to a random user, your relay cannot be written to. If a user of your paid relay logs in to nostr.watch, that indicator will turn green.
Gaming the results is not the solution, as your relay is not public. The results being shown are for users. If a random user shows up to nostr.watch, selects your falsely writable relay and cannot write to it, this will result in casting blame that my results are inaccurate.
The purpose of nostr.watch is to help a diverse range of user personas. By misleading a user, likely a new user, I would actually be negatively impacting the user experience of nostr by facilitating fudging the results for paid relays.
That said, there are some enhancements that need to be made, and are being made, to clarify what the indicators mean.
I'm open to suggestions here, so please let me know if you have some ideas that do not create the perception of being "punished" as a paid-relay while simultaneously also respecting the purpose of the tool, and the end-user: AKA the reason we should all be here.
