So started wanting to use nostr:nprofile1qydhwumn8ghj7emvv4shxmmwv96x7u3wv3jhvtmjv4kxz7gpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qqgrcrg2jwp2lwnqlwq3s7ypcgcymx32glz4k5znv4f6qykp8l876u5t77atk then discovered #MStack then starting diving into coding structure best practices on my own. And here i am after few hours of trying to build the best #NChat (Trying to build the best Nostr Messenger out there).

🚧 Building Nchat = a cool simple and also privacy Nostr messenger!

Nchat is a fully decentralized chat app powered by the Nostr protocol. Fast, minimalist, and built for humans with real Inbox/Sent folders, voice messaging, dark mode, RTL (Arabic) support, and local relay config.

🧠 Features so far:

📥 Inbox & Sent views

🔍 Search & sort messages by time/sender

🎤 Voice messages

🌘 Dark/light mode

🗣Arabic, Japanese, Chinese, English/Latin-Languages (RTL supported)

🌐 User-defined relays (localStorage) + Default Recovery

Coming up next:

🔐 E2EE with NIP-04/NIP-44

📡 Real-time relay sync

🧩 Full NIP-compliant messaging

👥 Contacts from mutual follows

Built with React + Tailwind + cryptographic rigor.

Will be releasing everything openly once it starts functioning decently.

Any ideas/heads-up/feedback from just this is appreciated #asknostr.

Thanks for the inspiration #nostr nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq37amnwvaz7tmwdaehgu3dwfjkccte9ejx2un9ddex7umn9ekk2tcqyqlhwrt96wnkf2w9edgr4cfruchvwkv26q6asdhz4qg08pm6w3djg3c8m4j nostr:nprofile1qyxhwumn8ghj7mn0wvhxcmmvqyehwumn8ghj7mnhvvh8qunfd4skctnwv46z7ctewe4xcetfd3khsvrpdsmk5vnsw96rydr3v4jrz73hvyu8xqpqsg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q8dzj6n

nostr:nevent1qvzqqqqqqypzpwy9rgrdl4uafr7ry535590f534r9gyc92prk4xdlqj3fwd3yzapqqsvq0uzmwdgwyuk433g8sy9y9e4nzrsuujfkkhctvgugffsxd3gwkszccuvd

Did you manage to get kind 17, private “Gift Wrap” encrypted DMs working with that … or just “legacy” kind 4 DMs?

If you do gift wrap … how do you handle if the user doesn’t have gift wrap relays ?

These problems aren’t hard to solve… but not a lot of implementations in the wild either for AI to scrape from … and when it does it might just “not work”.

Vibe coding “bleeding edge” apps is difficult in this way … but Stacks templates promise to make this easier. nostr:npub10qdp2fc9ta6vraczxrcs8prqnv69fru2k6s2dj48gqjcylulmtjsg9arpj

I authored some GiftWrap DM modules to handle this for NDK … I’ll look into making a Stacks template out of it. 😉

Reply to this note

Please Login to reply.

Discussion

just checked and got this:

DM Encryption Analysis - Key Findings:

nchat implements NIP-59 Gift-Wrapped DMs (NOT NIP-17) as the primary encryption:

Uses kind:1059 events with double-layer NIP-44 encryption

Ephemeral keys and timestamp randomization for metadata protection

Automatic fallback to NIP-04 (kind:4) for relay compatibility

No special "gift wrap relays" required - works with standard Nostr relays

User-configurable encryption modes in Settings

Fallback Mechanisms:

Automatic detection of relay capabilities

Seamless fallback to NIP-04 if NIP-59 unsupported

Per-relay encryption selection based on compatibility

Visual indicators showing encryption type used per message

Delivery confirmation with timeout-based fallback

I stopped using stacks and now vibecoding on rust and wasm with best security best practices. let's see how it goes. i cant wait to share it with you for testing when i get it there.

Sooly that’s awesome! Let me decode some of that AI speak for you … and add my thoughts:

- NIP-17 “implements” NIP-59 Gift Wrapped events (which in turn implements NIP-44 encryption) providing “kind 14” Private Direct Messages. It’s a number jumble, but bottom line is that this is the “preferred” way for sending and receiving “no metadata leak” private direct messages.

- “double-layer NIP-44 encryption … Ephemeral keys and timestamp randomization for metadata protection” (blah blah) just means that its NIP-59 Gift Wrap compliant.

- “Automatic fallback to NIP-04…” is a nice touch, for decrypting incoming messages. But NIP-04 DOES NOT support group messages (only one to one) AND leaves metadata exposed.

You want to do everything you can to keep this “NIP 04 fallback” from being implemented. Here’s some things to consider :

- Gift Wrap compatible relays (required because NO METADATA is available for relays to assure that any gift wrapped messages is not spam … so many will reject them outright) is the only reason this fallback is needed.

- you can setup a compatible “gift wrap relay” for use by your app (don’t worry about limiting access quite yet, just get the relay and use it) This can be easily spun up and configured from http://relay.tools (made by nostr:npub1qqqqqqz2gq6drwdc6fzc8c38djw8f28nlv76qt44rw5snrzcqnhsh8zmzc )

- for the “receiving user” using your app … well if your user does NOT have a ‘kind 1059’ event published to specify preferred relays relays for Gift Wrapped DMs , your app can offer to “add your relay to the user’s ‘kind 1059’ DM relay list”.

- in the case that your app receives “kind 04” messages, or if your app user wants to send a “kind 14” mesaage to a user without gift wrap relay specified … it MAY BE possible for your app to offer the external user usage of your app’s DM relay. Implementing this would definitely be off standard … and I’m personally working on some sensible UX flow for this … something like : you app sends a “kind 04” DM indicating that “so and so user wants to send you private DMs” and offering some links to supporting apps and relays … or something. This part is a bit more tricky.

I hope this long message was helpful and not too verbose. Last thing I’ll say is that transparency is key. Always indicating to the end user what kind of message it is and their publishing options will go a long way to making this whole mess less confusing for you and your app users.