Zapstore

ClipRelay — Zapstore

Automatically syncs clipboard between your devices. All communication goes through Nostr relays, encrypted with NIP-44. Authentication via NIP-46 b...

I had Claude build me a clipboard sync tool using Nostr. I've always found it extremely cumbersome to copy something on one device and paste it on another by having to open a messenger app, find the chat-with-self room, paste it there, then on the other device open the same messenger, go to that chat room, tap on the message, and copy it again. Sure, similar tools probably exist out there, but these days with Claude around, it's so quick to just ask an AI to build it—so I went ahead and made one. Here are the app's key features: - Supports only NIP-46 login (direct use of private keys is not supported. Aside from security concerns, the problem remains of how to transfer that private key to another device. Isn't it ridiculous if you still have to use a messenger just that one initial time to send it over?). - Tracks in real-time the relays and Blossom server specified by the user, and transmits data through those servers. - Text is encrypted using NIP-44 self-encryption; images are encrypted with an AES-GCM one-time key, then the encrypted binary is uploaded to Blossom, while the SHA-256 hash and decryption key are sent via NIP-44 encryption. General file types (beyond images) are not currently supported. - Supported on Windows, Linux, Mac, and Android; iPhone is not supported. - Usage: On desktops, after installation and login, there’s nothing else to do—copy on one device, and it automatically appears on the other's clipboard. On mobile, there is a persistent notification—after copying, tap the persistent notification to send it to the other device. When receiving, a separate incoming notification appears (distinct from the persistent one), and tapping it copies the content to the clipboard. - Currently free. I'm considering a payment system for the future—specifically when large file support is added, I'm thinking of passing charges directly through the Blossom server (not that I intend to collect payment directly). Enabling economic incentives for Blossom server operators was actually one of my motivations for building this app. I plan to support it once a smoother payment standard emerges. - On mobile, the app attempts to stay running continuously unless explicitly closed by the user (though this cannot be guaranteed). - Care has been taken to ensure plaintext is never stored outside the app’s own storage (e.g., in notification systems), though this cannot be fully guaranteed. - Clipboard history is stored plaintext on the device itself. - Logging out deletes authentication data along with the history. - The NIP-46 communication private key is stored in the OS-specific secure key storage. I’ve put effort into encryption, but given my own technical limitations, I can't be certain there are no data leaks somewhere. I do not recommend using this app for highly sensitive or critical information. It’s intended only for everyday, routine use—something that replaces the kind of casual content you’d previously share over messenger apps.

CTO wants to have a 1-on-1 meeting on Monday. It seems like the time has finally come. If I get laid off, I should take a good two-month break to rest.

Nostr client developers really need to make it easier to add friends via QR codes — especially when meeting users in person, not just following them online. Many clients are quite inconvenient in this aspect, and some don't even have this feature at all. It's unreasonable to expect users to manually type long public keys, and given that Nostr is decentralized, search functions are already limited. It’s frustrating that even when you meet someone in real life, adding them as a contact can be such a hassle.

I was using Zeus Wallet and thought I wouldn't need Alby anymore since it supports NWC, so I uninstalled Alby. But it turns out Zeus isn't as reliable for payments—while it works fine when using Zeus directly, it often fails when connecting through apps via NWC. Probably because Zeus runs locally on mobile, whereas Alby operates via server. Looks like I'll have to reinstall Alby.

I'm currently using @Minibits mint through @Keychat , and I'm reaching out with a question. I'm personally developing a service that requires payment via hold invoice, and during development, I was testing the expiration/cancellation behavior by paying a hold invoice using the Keychat Cashu wallet. The payment attempt initially seemed to fail—although the payment did reach the recipient side, it remained in a "pending" state since it wasn't settled, which is expected. I didn't mind the unclear UI indication, since most wallets don't clearly display pending states anyway. However, the next day, after the invoice expired as intended and the payment properly failed, I noticed that the deducted balance in my Keychat wallet wasn't restored. Normally, when a hold invoice is canceled, the mint's Lightning node should recover the funds and reflect that credit back to the user's balance. If this were my own Lightning node, the balance recovery would have happened automatically. But with the Cashu wallet, since I had already paid ecash to the mint to initiate the payment, my balance was deducted up front. From the mint’s perspective, once the ecash was spent, the balance was marked as spent—even though settlement never occurred. And since the control had already been effectively transferred, the mint likely considered the payment as completed on its end. It doesn’t appear to track the subsequent cancellation status. Moreover, due to the anonymous nature of ecash, the mint likely can't identify who made the payment—even if they wanted to issue a refund, it might not be possible. I can provide proof of the hold invoice and confirmation that it was ultimately canceled (via DM). Surely a refund shouldn’t be impossible? I understand it might not be easy to verify, and while I understand if no refund can be issued (it's only 5,028 sats, not a large amount), this highlights a bigger issue: going forward, such payments need to be properly handled. Otherwise, it effectively means users permanently lose funds to the mint even when payments fail. This isn't just an issue with Minibits, but likely all #cashu mints. A proper mechanism needs to be developed to handle these cases.

There's a feature in Keychat wallet where sending "pay ecash" returns an ecash token, but sometimes it comes with a QR code and sometimes it doesn't. What's the difference? I'd like to provide a smooth experience where users can simply pass along a QR code, but when it only returns a token, I have to send it via DM, which is a bit inconvenient. #asknostr @Keychat

Sometimes, while using a VPN, Nostr-related apps occasionally fail to work properly. Since they always start working again as soon as I turn the VPN off, it's nearly certain that the VPN is the apparent cause. I initially thought the VPN might be blocking WebSocket connections to relays, but since the apps often work perfectly fine even when the VPN is on, that doesn't seem to fully explain it. What's more puzzling is that @Amethyst always works without any issues, regardless of whether the VPN is active or not. I can't figure out the reason for this inconsistency.

I believe providing economic incentives to relay operators is essential for the nostr ecosystem, and among the possible approaches, attaching e-cash when publishing events seems optimal to me. I’ve been skeptical of subscription-based payment models, and more importantly, with standards like NIP-17, users send their DMs not from their main pubkey but a temporary one—making subscription models fundamentally incompatible. Recently, I noticed increasing spam accumulating on my personal relay, which became quite unpleasant. I thought there must already be a NIP addressing this, so I went looking—but found nothing. Hmm? I decided to try implementing a solution myself, even if just according to my own idea. But immediately after starting, I understood why such a standard hasn’t emerged yet. It turned out to be too complicated. When publishing an event, devs familiar with the nostr ecosystem typically use an outbox model, publishing across different sets of relays dynamically. However, most clients don’t publish to individual relays one by one, but broadcast to all target relays via nostr-tools(or something like that). This means if we want to attach e-cash to a *specific relay only*, implementation complexity spikes dramatically. Moreover, what happens if the relay’s price changes? How should the relay behave if it receives the same event again (e.g., due to a re-synchronization or backfill)? Should already-sent e-cash be refunded, and if so, how? And if refunded, must that e-cash be redeemable again? When you dig into all these edge cases one by one, the feasibility of such a system becomes questionable. The most practical implementation so far might be keychat approach, but even that was designed for a messaging app rather than a social network—and still doesn’t integrate well with the idea of an inbox-relay model for DMs.