Constant on Nostr: Alex Gleason 's ''insight'' that a Nostr-ID == Bitcoin address, came with the wrong ...

Alex Gleason (npub1q3s…d26p) 's ''insight'' that a Nostr-ID == Bitcoin address, came with the wrong conclusion. The point is not you can send BTC to a Nostr profile, the point is that Nostr already indexes naturally anything that is relevant to Bitcoin.

Yes, this means you can go and create a kind:0 (profile) for a BTC-address, or send BTC to a Nostr profile, sure. But there is a lot of potential (meta) data involved with your Bitcoin Wallet. Address book/contacts, transaction labels, wallet descriptors and scripts. Those things are already tied to a (master)keypair, and as such a very easy query away from fetching if they were stored via Nostr.

The only response i got to this idea was this:

quoting
nevent1q…r4gl

Since nostr is not reliable (best effort only), it should not be used for must-be-available data.

In a way it is a weird and confusing position to me. What system are you supposed to use for "must-be-available data"? What do we use now? What are they planning to use? What makes a server or system adequate for "must-be-available data", the fact it has a sticker that reads "reliable" on its housing? Does one solution exclude another?

Data availability and reliability on Nostr are straight forward, because it does not fool you with false promises: You figure it out.
Redundancy is resilience, decentralization is censorship resistance, paying for a service will probably net you more reliability than something you use for free.

More relays, better relays, migration to different relays over time....thats it, thats all there is to the ''data availability'' story anyway.

Nostr.