NIP-17 messages in noStrudel
Another noStrudel update, and this time I managed to finish it in less than 6 months unlike all the previous updates.
The only big feature in this release is support for NIP-17 messages and a rebuilt direct messages view (less bugs)
NIP-17 messages and NIP-59 gift wraps
The big feature of this release is support for NIP-17 messages and NIP-59 gift wraps. this makes noStrudel compatible with Amethyst, 0xChat, Coracle, Flotilla, Coop, and other clients I’m forgetting.
Personally I still think NIP-17 isn’t a good spec for direct messages since its built on NIP-59 gift wraps which are pretty complex and have no resistance to spam attacks (see section below)
The added support for groups makes it even harder to implement in a transparent way to the user since sending a single message to a group of 4 other users requires you to encrypt, sign and publish 4 gift wraps to all users inboxes (fan out). Most of the time this works but I’m already seeing cases where some users will receive a message and some wont due to connection issues with their specific inbox relays.
Normally I wouldn’t implement a NIP that I think it flawed or overly complex, but in this case a lot of users were asking for it and I thought it would be a good challenge for myself and a good opportunity to see how far I could push the applesauce SDK I’ve been working on.
Spam attacks
I haven’t seen any of this yet, but in theory NIP-59 gift wraps have no protection against spam due to the way the events are encrypted and the sender is hidden.
This means that the users client has to download and attempt to decrypt all spam messages along side legitimate messages.
Normally decrypting the messages isn’t that much of an issue if the client has full access to the users nsec
but this becomes increasingly more expensive depending on the signer that the user is using (NIP-07 or NIP-46)
There is also the potential that a spammer could make it very difficult for a user to receive messages by constantly sending fake gift wraps to their inbox relays and effectively DOSing a client by making it constantly download new gift wraps to check if they are legitimate messages. I don’t see any way to mitigate this since the author of the gift wrap is hidden and the client has to download all gift wraps in order to not miss a message. The relay could mitigate this by using IP blocking (traditional method) or requiring e-cash to publish (making spam expensive) but at the end of the day this just mitigates spam and does not eliminate it.
Contrast that with Martti Malmi‘s double ratchet spec which has clients sending messages over a rotating shared key. this allows clients to selectively download and decrypt messages for specificity groups instead of needing to download and decrypt all messages sent to their inbox relays. Also since the groups are using a shared key there is no opportunity for an outside spammer to create fake messages, only someone inside the group could create spam.
Disclaimer: I have only briefly read NIP-117 and have not built an implementation. so I may be wrong on a few things
Manual and automatic decryption
Based on everything I said above I thought it would be best to support two flows for the client to receive gift wrapped messages. manual and automatic decryption
In manual mode, messages need to be decrypted in the inbox (Messages -> Inbox) or by selecting a user and decrypting them one at a time
This allows you to selectively decrypt and read messages without giving the app unlimited access in your signer or having to click “approve” on 100+ popups as soon as you open the messages view.
The downside to this approach is you need to keep an eye on your inbox for any new messages received.
In automatic mode messages are decrypted as soon as they are received. which means you will be asked to decrypt 100+ events when the app first loads. but you won’t have to keep an eye on the inbox for new messages. This should be a better user experience for users who completely trust the app and have given it full signing and encryption permissions.
Message cache
Since NIP-59 gift wraps require the signer to decrypt two events (gift wrap and inner seal) for each message received it makes sense to cache these decrypted events for performance reasons. This ensures that the app only needs to decrypt messages once instead of every time the app is opened.
There are a bunch of new options in the Settings -> Messages view to allow you to customize the message cache. by default it will be encrypted using a password, but you can disable that if you want less hassle and are okay with having the plaintext messages stored in your browser.
There is also the option to completely disable the cache but then you will be required to decrypt all messages every time the app opens
NIP-42 authentication
Since most inbox relays require NIP-42 authentication to read gift wraps or NIP-04 messages I added some warnings to the UI when one of your inbox relays is requesting authentication.
What this looks like is a small alert popup in various places in the UI that asks you to authenticate once with the option to automatically authenticate in the future.
Applesauce v2.3
Since noStrudel is built using the applesauce SDK there is also new versions of the packages that support NIP-59 gift wraps and NIP-17 messages.
I’m sorry there isn’t any good documentation for it yet on the docs site but if your really interested you can find the new features in the TypeScript reference or you can look at the messages / gift wrap example
Other small changes
There are a few small improvements and bug fixes in this release
New profile editor
There is a new slightly more fancy profile editor in the app now. it has a preview and descriptions for each field
Removed threads and replies in direct messages
As part of rebuilding the direct message view I removed support for threads and replies to specific messages. This doesn’t mean the feature is gone forever but Ill have to re-implement it in the next few updates if I get the time
Disappearing messages
The app now supports using NIP-40 expiration timestamps on NIP-04 and NIP-17 direct messages. This WILL NOT protect you against other users reading your direct messages if your private key is leaked but in some cases it will allow old messages to disappear from relays after a set amount of time.