> you don't even need an extension to connect to a bunker

Unless a client doesn't (properly) support NIP-46 but still supports NIP-07.

I think we've got too many ways to sign in to web clients right now; it's confusing to users and complicated for testers. I personally found that having a single NIP-07 extension with a single NIP-46 connection is great, while establishing a NIP-46 connection per each client is painful.

For those browsers that disallow non-TLS connections to localhost, NIP-42 auth-only relay works well. Or just a relay with a private URL (with a long random path).

That's not how I see acceptable NIP-07 extensions: I don't accept those that store keys at all but accept those extensions that connect to a NIP-46 bunker (Bunker46 extension in particular).

> only because

I strongly believe that browsers we know today, with their whatever isolation techniques, shouldn't be trusted to read private keys in any way.

The browsers are too huge and too rapidly changing for anyone to adequately audit them.

Also, there are proprietary browsers that normies like; who knows how these can be exploited, especially in combination with proprietary extensions. I'm sure we'll keep hearing a lot of creepy news on these in particular.

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:



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:

https://codonaft.com/nostr-no-bullshit.html

> 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:



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.



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.

Nostr is dead. Again.
Bitcoin is dead. Again.

sftp is usually slow.

Either vanish or become overpriced or something like that; become unavailable in some way, through enforced KYC to some absurd level, for example. This is why we still could benefit from a censorship-resistant layer for the normie DNS that could give full control to an authentic domain owner based on Nostr to fight this unfairness.

I've just learned what was happening to the .org in 2019 from the HN comments. So weird. I'm still unaware of so many events that happened during this period.

Dead Mail, I guess.

@Rizful.com ironically, your bot attempted to zap a scam bot:

NIP-59 gift wrap currently requires NIP-42 auth on clients (but not on relays), yet I don't see any reason to not require the auth on relays too if gift wrap was requested (at least by default).

NIP-42 also needs to require support for requesting events from relays by either "authors" or "p"-tag, at least for gift wraps, for Concord compatibility.

Thanks! I still don't get how PREEMPT_RT would help; forgive my retardness.