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

Is Clave the only #iOS NIP-46 singer published on AppStore/AltStore today? #asknostr And why do we still allow pasting a raw nsec/ncryptsec into the clients? Why? Something is still not working with these signers? Somebody believes that all clients actually securely store the secrets, properly zeroize memory after exiting, and so on? Properly managing these secrets was never an easy thing to do. It should never be delegated to some random vibe-coded stuff, that was not designed specifically for that; very few normal users are capable of understanding the significance of that, yet we happily provide them an input field for nsec like it's something acceptable! This is, BTW, the only signer I'm aware of that hardens memory with `mlock`; there's nothing close to that in normal clients and probably never will be there:

Gitea on NOSTR

n_signer

nsigner is a single statically-linked program that holds signing key material in locked memory and signs on request.

I've recently had an experience of explaining why pasting nsec should never be practiced with ordinary clients, why it's not the same thing as a changeable password—yet this person pasted it anyway to "fix" something: Armada Android client was failing to publish a NIP-65 relay list. This will never change: if there's a wrong button, it will be pressed for stupid reasons, many times. I think the "nsec SHOULD never be used directly in clients; NIP-46 and NIP-07 SHOULD be used instead" should be written in some NIP already. With blood. #security #devstr View quoted note →

I've made some tiny progress since I wrote this article: it appears I respond to tone better now. View article → I'm not happy, though. I suck at identifying in time when the other side has started to respond from the 3rd lowest level of the Graham's Hierarchy of Disagreement. Self-development is a bitch. #grownostr #meditations #leadership It's not a usual case in my debates: I do my best so the other side would never need to respond to my tone. Do my best to keep my vibes, directed to the other side, in control. I'm interested in rational discussions, not the discussions that turn into emotional drama, where either side has to respond from stress. This case was unique: the other side had a reason for responding to my tone because I was rude towards the third, the discussed side. Which was not some object; it's a group of people. A group of people that never responded to my initial friendly inquiries to them. What I've learned this time: identifying a response to a tone is not easy; it's not obvious because it doesn't feel offensive. It feels just like some normal, valid, routine kind of argument when it's a part of an already ongoing debate. While it should always be used as a marker for putting the discussion on pause instead. It's not yet an unrecoverable stage of discussion, but being too late with this totally kills it. Keep nostr weird, folks. But don't overdo it: notice that any side may be in stress already. That's not the point of debating; the point is truth.