You are advertising something that most senders didn't know it was possible and most receivers didn't want to use.
This should be opt-in to signal the desired receiving method.
🫂
Login to reply
Replies (27)
It's also the only method that actually works around here... Lightning fails in about 30% of the time. Cashu even more. So, it's really the only stable method to send zaps we have currently.
My big lesson from this is that the past 10 years of Bitcoin development has been a massive lie. Nothing after 2014 really works well and people that claim it's working are massively delusional.
Failing to receive it's much worse than failing to send.
If the user doesn't signal his desire to receive onchain, he will probably fail receiving, and that's a massive fail, imo.
Like everything else on Nostr, if you send something and the receiving user doesn't have a client to see it right away, it doesn't fail.
Because there are so many clients that implement various things in different ways, there is no way on Nostr for you to reliably say that you don't want something. Your keys can be put anywhere the sender wants and I actually think that is what defines Nostr.
For instance, we all might have received transfers from many shitcoins out there. We all might have money waiting for us in several Cashu mints, etc.
You cannot block any of that from happening.
Just to give you a proof point, we tried this idea of blocking people from sending things on the NIP 17 spec, where if the receive doesn't have a DM relay list, the client is not supposed to send the DM.
Virtually every client ignores that rule. So much so that I had to change Amethyst to find nip 17 DMs in other relays just to see those clients DMs.
I think we are the only ones that still block it if the receiving user doesn't have a DM relay list. But I might change that soon to avoid the friction.
Sorry, but sending and receiving Bitcoin is not like sending a nostr note.
And it's not about blocking something to happen, it's about being able to signal a preference on receiving method.
It's such a meaningful difference, user-wise.
🫂
Being able to signal the preference for DM would be nice too, imo.
🫂
We already have that, but nobody uses it, and clients just ignore it. So it not effective. it just adds to the confusion and friction when using Amethyst... :(
Why not? I think people think it is different because it has clear nominal value, but information is far more interesting and valuable than money in social networks. There is no point on applying different standards for them.
Remember that our largest trillion dollar companies are based exclusively on the idea of tracking and selling your social interactions, not your financial transactions.
Bitcoin and Nostr are two different protocols and networks (though undeniably complementary) because money and information are different beasts.
They could compliment each other (and I honestly think they do it very much), but they both exists on their own.
Nobody is saying information has no value, don't try derailing the conversation, please.
🫂
That's because, unlike Bitcoin, Nostr doesn't need consensus. It builds beyond it.
That's why I still think preference signals are very useful.
🫂
We can do preference signals... But people don't even set their outbox relays right.. so not even that crucial part of nostr is working correctly... :(
I am not trying to derail. And I agree that they are complementary to each other. But I also know you cannot separate them from each other.
The point of a zap is to link your social and financial information in a single pubkey.
You don't get to "separate" two different things.
Many Bitcoin users don't even know Nostr exists, and a lot Notr users don't use Bitcoin.
Zap (linking social and financial) was meant to be opt-in.
But you've made it on by default and not even able to opt-out.
But you already know that. The problem is that you consider it a feature, when it actually isn't.
It's not a feature in my mind.. it's just not an opt-in process at all. Youd socially linked transactions will always be public as long as you send them through any Nostr client. Lightning, no lightning, it doesn't matter.
The only way to opt out is to have a Bitcoin wallet that no client sees. And never link the two. You can opt to not use the zap features on a Nostr client but all off those features are there and those wallets are all public.
The recommendation I make to anyone is to have two separate wallet groups. Public and private ones, regardless of the tech stack. Never put your private lightning or cashu wallet on Nostr. Similarly. Never mix your Nostr on-chain wallet with your private on-chain wallet. Never transact between any of them. If you do it once, your private setup is already exposed.
Again, it's not what I chose to use. It's about signaling others my preference, if they decide to interact/zap with me.
Like I am trying to say, we can code your preference... But historically every client just ignores it.
Sorry, but that's not what you are doing.
Showing upfront the zap-onchain option to every user, what you are actually doing is pushing the users into the dangerous path of mixing their "nostr public wallet" and their "private onchain wallet".
You are not helping the user, not at all.
🫂
Maybe I am not making myself clear, we can add this, but seeing how every company in our space just adds bullshit to pretend that things are solved when they are not.... I don't want to participate in that disinformation campaign...
Your client could start by taking it into consideration, if you think it could be a good idea.
But we have lots of warning messages when putting money in and removing from it. As long as they receive in Nostr and send in Nostr, everything is fine.
The disinformation campaign is showing onchain option to every user, knowing that most of them using other clients will never know about this option.
Just my opinion, ofc.
I mean, if we had to remove features that we have but other clients don't see it, we would only have one feed and nothing else.
The funny part is that I had the exact same discussion when doing pronouns in people's profiles and some users wanted me to hide it...
Actually, I have this discussion in virtually every feature we add. There is always somebody asking me to hide things without understanding that it doesn't change anybody else's view of you.
The best place to put those warnings would be in the opt-in option, imho.
That would be the best option to protect the user into a possible future privacy leak.
Again, as I said, you think this is a feature, but it's not if it's not opt-in.
It will never be opt in. It doesn't matter what we do. Hiding it doesn't make it opt in. In this case, nothing ever will.
Added but it's just hiding it... 
GitHub
feat: add setting to hide the on-chain (Bitcoin) wallet by vitorpamplona · Pull Request #3481 · vitorpamplona/amethyst
Some users don't want the on-chain wallet surfaced. Add a showOnchainWallet
UI preference (default true, so behavior is unchanged) that hides i...