Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 1
Generated: 12:21:20
avatar
hoppe2 npub1pt4q...eera
Questions about nostr:npub1h0uj825jgcr9lzxyp37ehasuenq070707pj63je07n8mkcsg3u0qnsrwx8 * Direct Message Sorting: When I receive DMs through Keychat, the messages are often out of order, not sorted by the correct chronological time. This seems to be due to sorting by the randomly chosen time for metadata protection, following the NIP-17 standard. However, doesn't the encrypted data inside the seal contain the true timestamp of when the message was written? * Duplicate DMs: The DMs I receive are consistently displayed twice, as duplicates. I have no idea why this is happening. * Signal Protocol and NIP-17: I understand that Keychat uses the Signal Protocol, yet I still receive DMs from clients that do not support it. Does this mean that while sending messages uses the Signal Protocol, receiving messages supports both NIP-17 and the Signal Protocol? * Transaction Fees and Refunds: I saw in the documentation that sending a message (adopting a "postal system" model) consumes 1 sat via ecash. However, it seems to be immediately refunded. What is the reason for this refund? Could it be because I sent a DM to someone using a client that doesn't support the Signal Protocol, and the message therefore couldn't be delivered? In other words, does Keychat have a system to refund the sat if the message delivery fails?
2025-11-17 00:24:25 from 1 relay(s) 1 replies ↓
Login to reply

Replies (1)

avatar
Keychat npub1h0uj...rwx8
Thanks for the feedback. The first two issues are bugs and we will fix them. For the third issue: if you log in to Keychat using your own microblog ID, you can receive NIP-17 and NIP-4 DMs in Keychat when others send them to you. You can already reply to NIP-17 DMs in Keychat, but replying to NIP-4 DMs is not yet supported. For the fourth issue: some mints charge fees. If Keychat receives one ecash token at a time, it becomes inefficient, so we batch multiple tokens into a single receive operation. We will improve the receive-stamp mechanism later. “As an example, we construct a transaction spending 3 inputs (Proofs) from a keyset with unit sat and an input_fee_ppk of 100. A fee of 100 ppk means 0.1 sat per input. The sum of the individual fees is 300 ppk for this transaction. Rounded up to the next smallest denomination, the mint charges 1 sat in total fees, i.e., fees = ceil(0.3) == 1. In this case, the fees for spending 1–10 inputs is 1 sat, 11–20 inputs is 2 sat, and so on.”
2025-11-17 02:29:49 from 1 relay(s) ↑ Parent Reply