Which app are you using? 0xChat is free to use, while KeyChat charges ecash to send messages, but I think you can also choose free relays
I see, I see, an idea: send a nutzap (nip61 kind 9321) event to the relays when sats are received. This way, your service would require almost no trust, and you wouldn't need to handle token storage or claim operations.
Is it possible to generate the P2PK token only at the time of the claim/withraw?
The nsec bunker is not very suitable for 0xchat client. The DM requires a large number of frequent encryption and decryption operations, and using remote nsec would severely impact the performance.
Thx for installing and trying out the app. Currently, we do not support communities. For public channels, we use the latest NIP-51 list standard, which might not have been used in Amethyst? nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
However, you can search for your channel by using the channel ID in the discovery-channel.
I think you missed the point. Kind1059 (kind1) has a problem where the recipient can broadcast kind1 without exposing any keys. However, kind1059 (kind13 (kind14)) requires exposing the share key, right? And kind4 (kind4) leaks metadata and is not even within the scope of discussion.
Moreover, I don't think the leakage of kind14 requires poor code. Even very rigorous code can have bugs and be subject to hacker attacks. What we need to do is not to hope for no bugs or leaks, but to ensure security even in the event of a leak.
By the way, the zap store is not working on my end. Once I click "Updating on device," nothing happens.
Let's continue. Even with a shared key, if it gets exposed, all conversations between the two individuals will be leaked. Furthermore, I can identify who exposed the key. (For the person who exposed the privacy: This person is untrustworthy, and I can choose not to communicate with them.)
Additionally, the inner event might not be exposed by the recipient; it could be leaked due to client-side storage or other reasons. An inner event that includes a `sig` is much less secure.
Yes, kind13 is signed, but kind14 event is encrypted and placed in the content. If you want to expose the encrypted content, you must reveal your private key, which you obviously won't do.
But if you don't reveal your private key, then you can only expose a kind14 event that does not contain a sig. Without the sig, it cannot be proven that this event was sent by the sender.
Not your sig, not your event. This is how Nostr works.
As long as the other party receive the giftwrapped event, if the innerevent contains the sig, the innerevent can be broadcast by the other party to relays, and this will be a verified event.
The sig was removed from the kind14 event to prevent leaking the inner event to public. Therefore, it needs to be encrypted once into a kind13 event and then gift-wrapped again.
No, during a nut zap, it will swap to one of the user's trusted mint. But compared to a lightning zap, it only requires 3-4 steps instead of a complex 12-step process.
The relay nostr.coinfund.app seems to be not working properly, but you can try other relays, which won't affect the use of the app.
Regarding the discovery channel issue, are you unable to see this page? 
Are you using the latest v1.3 beta?