The moment Nostr was created to be compatible with Bitcoin, is the moment you can send and receive onchain. If one is concerned about their saftey because of this (and it is a valid concern), then they shouldn't use nostr and throw away their keys, or Nostr should've not been compatible with Bitcoin in the first place. Would I normally reuse my address, and make it publicly known? Aside from specific use-case, no, of course not. But on nostr? I'm not allowed to make that decision after I start using it, because that is its bedrock, whether I like it or not. This isn't a new "problem", everyone (well, at least advanced users and devs that looked into it and realized it) chose to use Nostr knowing that this would be a thing from inception. Criticising a dev for implementing onchain transaction on nostr is misplaced, the criticism should be towards the protocol itself, not those that advantage of it. Discouraging devs from utilizing this is wasted effort. Rather than doing that, it would be more wise to figure out ways of warning of potential dangers that come with it, guiding them how to handle their public funds, or even develop new implementations to have a more private/safer option (What I'm doing with Nostr Silent Payments (NSP)). It's also better than good developers have started doing this (onchain transactions) where we can do these kinds of good danger-reducing efforts, rather than a malicious individual/dev hitting everyone from their blind spots. One mustn't be fearful of potential issues, but rather be encouraged to see how it can be solved or mitigated. Whatever can be done with the tech, do it, and if it turns out there's something bad with it, good thing it was discovered so we can see how to fix it or best-effort educate/guide people, or if the damage is too much then the protocol should be abandoned (if it will be that's another matter) and the protocol would have failed.

Damn, i like, but i need to up my gaming talk x3 View quoted note →" target="_blank" rel="noopener">https://image.nostr.build/691bfd8aaf5c65750bd7899e5bb4bd2fdf7058c955758c71c35704bdffa001cd.jpgNOSTR_0

@ABH3PO hey, i imagine you were seeing a bunch of garbage text as a poll event here and there, this was from an implementation into a new client, that's a encrypted group chat, so polls are published through it but encrypted. There was no mention of a private poll flow, so that's how it is implemented in that client right now. I can keep it as is, and we'll see a bunch of polls that are gibbers with clients not being able to render them properly without a sort of check if it can be rendered, or perhaps the nip would be updated to consider something like a 'visibility' tag of sorts so clients can what to render or what not to render (not to render ones where the value would be 'hidden' for example, under the assumption that poll would be encrypted), or perhaps a whole new kind specifically for private-encrypted polls. Thoughts?