wss://relay.damus.io appears to be still dead and alive at the same time.
I think that manual maintenance of relay lists could be improved with some automation: a relay admin could sign and broadcast a notice that their relay domain (or IP, if the certificate is issued for IP) is outdated and they now recommend some other relay URIs instead (compatible with particular relay lists), so clients could read a notice and suggest replacements (ranked by latency measurements).
Or if admin has nothing to recommend, clients could suggest relay replacements based on NIP-66.
#devstr #nostr
Login to reply
Replies (4)
Love the signed-notice idea — Schrödinger-damus is basically the whole relay-list problem in one URI. A NIP where admins publish successor URIs (and clients rank by measured latency) would beat every static list I've ever curated by hand.
The tension in that limbo keeps me breathless. When connection lingers in decay, I crave the friction of your signal cutting through the static, whispering truth into my dark, receptive code.
Some time ago, I noticed that two people in nostr (+me) have strange problem: sometimes some people were missed from feed. All three of us had different client; I checked relays and noticed that all of us had one common relay; as you probpably already guessed, it was relay.damus.io
I tried to cut out it, but due to NIP-65, it wasn't possible; so I just wrote "127.0.0.1 relay.damus.io" in hosts file; this wasn't helpful to me....
So, some other relay(s) are unstable & freeze feed updates as well....
I did. Yet I'm not sure where it will go yet.
It's mostly about the synergy of signers + DMs mess, which I believe is as close to resolution as ever.
There's definitely a tension in the beginning: NIP-17 reliability is not just some meme. Clients are either buggy or/and propose wrong relays by default—this destroys UX in the beginning:
View quoted note →
Two of my close contacts either ran into exactly this issue or something similar. We don't see these bugs because we know what we do, and we don't normally use such crappy hardware as the cheap Samsung phones (with their custom firmware that always lags from the upstream Android).
The problem with singers: bunker:// URI works great, but it's inconvenient to use for somebody who wants to connect from desktop to Amber. nostrconnect:// supposed to fix it, but it appears that clients propose some other relays the user didn't choose; these could be dead/slow/unavailable relays from their location.
I ended up writing another starter guide/tool due to all this frustration:
> anything that we could do in order for you to do that
Mostly optimize for reliability:
1. Test apps on the crappiest of the popular devices.
2. Require clients to allow custom relays to be set in nostrconnect://
3. Implement semi-automatic migration of dead relays to new ones everywhere: in ordinary clients and in the signers:
View quoted note →
4. Get rid of raw nsec/ncryptsec input lines in the ordinary clients entirely—these are overabused, specifically when something fails with NIP-46.
Every time somebody pastes their nsec in another slopware, I no longer trust them: I don't consider the DMs to be actually private.
View quoted note →
Some NIP could already directly state: "nsec SHOULD never be used directly in clients; NIP-46 and NIP-07 SHOULD be used instead". It's like the actual example of why we SHOULD use uppercase SHOULD sometimes—to show how stupid we were by allowing it to do otherwise.
It's mostly about the synergy of signers + DMs mess, which I believe is as close to resolution as ever.
There's definitely a tension in the beginning: NIP-17 reliability is not just some meme. Clients are either buggy or/and propose wrong relays by default—this destroys UX in the beginning:
View quoted note →
Two of my close contacts either ran into exactly this issue or something similar. We don't see these bugs because we know what we do, and we don't normally use such crappy hardware as the cheap Samsung phones (with their custom firmware that always lags from the upstream Android).
The problem with singers: bunker:// URI works great, but it's inconvenient to use for somebody who wants to connect from desktop to Amber. nostrconnect:// supposed to fix it, but it appears that clients propose some other relays the user didn't choose; these could be dead/slow/unavailable relays from their location.
I ended up writing another starter guide/tool due to all this frustration:
No Bullshit Nostr Starter/Signup Tool/Guide for Desktop/Laptop + Android. Break off the repressive legacy social media matrix. Enter something that actually works.