Notify makers on Nostr when an order is taken

Goal

As a RoboSats user I would like to be notified on Nostr as soon as a trade has taken place.

Briefing

Currently, makers need to keep a browser tab open to know when their order has been taken in RoboSats or link a Telegram user id to their Robosats trade offer. If a taker is found, the browser will play a tone to notify the maker or the telegram bot wil notify the telegram id. The browser tone works well on desktop, but it is not practical on mobile devices where the screen turns off and the sound notification never plays. Telegram notification includes privacy issues and encourages reusing the same Telegram id for multiple RoboSats trades.

As an alternative to Telegram notifications, there should be an option to receive notifications as Nostr direct messages using NIP-04. Nostr DMs are encrypted per design.

What is Nostr? A decentralised network based on cryptographic keypairs and that is not peer-to-peer, it is super simple and scalable and therefore has a chance of working. https://github.com/nostr-protocol/nostr

Implementation Possible implementation by using python-nostr, see "Send a DM" for an example.

Meta: Credits for this feature request This feature request has been written by by the nostr user HiP0 due to my 23k sat bounty for creating such a feature request published on nostr. Because of GitHub account flagging, HiP0's issue #353 has never been released to the public here on GitHub and I agreed to repost this issue on behalf of HiP0. HiP0 got the 23k sat bounty as a Zap attached to this nostr note.

A part of this feature request is taken from nostr user patrickulrich which released his toughts on this in this nostr note.

My addition which is addressing privacy concerns, due to the fact that nostr notes are public (direct messages included, which are encrypted to just one pubkey but visible to everyone as "meta data" on relays):

Implementation suggestions for privacy

The message receiver can be specified by npub and the sending nsec will be generated by random every time from robosats. As advanced setting, the sending nsec can be choosen by the robosats maker.
A small (between 0-30 seconds) random time delay between taking the offer and sending the nostr note should be added to avoid doxing because of timing analysis concerns.

Discussion

❓ I'm not totally sure about how the npub and nsec thing should be handled. Does anyone have another privacy friendly approach or thoughts about this?

For example I could think of forced random nsec AND random npub receiver (for which robosata displays the nsec). Then nobody would come to the idea to use their main nostr identity but have to use a dedicated nostr client with this burner nsec's to receive notifications. However this approach gets complicated if an user wants to have multiple offers open as a maker at the same time. Interferes with #177 .

Meta Taken from this nostr note.

Hello @alaznem happy to see this topic on Robosats, let me try to share here my knowledge, because despite I believe it's a good idea and lots of user would prefer nostr over Telegram, using the wrong design on this would lead to bad scenarios for Robosats and users.

I'll try to categorize all the features, scenarios and technical issues we might find:

Privacy

As you mention, DMs are not entirely private, it's really easy for anyone connected to the network to spot to who, when and how often a pubkey has been using DMs.

Robosats might generate a single private key per robot and use it to send DM to a provided pubkey. By not having a kind:0 event associated to it ,3rd parties will only see a pubkey sending a DM to other. It's possible that someone flags this pubkey as made by Robosats, but that will expose only that robot. Expecting this to be done by a 3rd party is as likely as figuring out the robot's token.

Bad actors with big relays can also spot Robosats IP and tag all DMs events coming from it. A solution for this can be to have a relay on Robosats acting as proxy of a chunk of big relays and sending events to other chunk. With a good implementation (most importantly one NOT accepting subscriptions), Robosats can include his own events all together, doing really difficult to spot the ones generated internally.

Alternatively, we can wait a bit until this NIP is accepted into the protocol https://github.com/nostr-protocol/nips/pull/260

Consensus

Or more specifically, the lack of it. Unlike Bitcoin, the nostr protocol does not ensure or regard universal consensus. So we cannot assume a DM sent to the network will reach his destination.

A solution would be to enforce users to share with Robosats the nprofile (https://github.com/nostr-protocol/nips/blob/master/19.md#shareable-identifiers-with-extra-metadata) which includes a list of relays the user is connected to. Robosats would then connect to those relays and make sure the events are available there. The only problem I see is that not all clients generates nprofile but npub instead, which does not contain any kind of relay information.

Another but less pretty solution would be to ask the user to manually include a relay url, but I believe that would have bad side effects like depending on the availability of the relay and the privacy issues mentioned above.

Decentralization

I don't see this as an issue for today's Robosats but should be taken into consideration for the federations project. Once again, unlike with Bitcoin (where a regular user is passive with the grade of decentralization of the network), users should be really pro-active on ensuring the decentralization of their data.

This is just a heads-up, a federated Robosat's network will always require to have an eye on their nostr connections (and relays).

Technical problems

Nostr works 100% over websockets. If the communication layer nostr -> Robosats -> nostr stays in the backend, I see no problem with it. You can use github.com/fiatjaf/noscl or one of the thousands of other nostr libraries. But if for some reason you want to use it in frontend, remember we had a lot of problems with websockets on the Android app and we ended up doing a workaround with HTTP requests to avoid using them.

I hope this will help you to bring nostr to Robosats! As I said, despite all the difficulties I mentioned having nostr messages on Robosats would be a huge win for everyone. If you decide to go on and really start with the project, count with my keyboard 😄

:eyes: Thank you @KoalaSat for your well elaborated thoughts on this issue. I learned a lot and it opened my eyes to the underlying complexity of this feature request.

Due to this complexity for implementing "notifications over nostr" into 3rd party services the right way, how do you think about generalizing what is needed for 3rd party services and create a new repository for this? And if someone is dedicating her work to this, she could take the robosats service as reference for the implementation.

Furthermore we could think about if doing work on the protocol level in the form of NIP's could pave the way for a robust notification system over nostr.

In detail from my POV, waiting until https://github.com/nostr-protocol/nips/pull/260 is finished should be the way to go to tackle privacy.

Thank you for this PR @alaznem

I believe this needs more research. I have some concerns with regard to privacy. We have alternatives planned that are seemingly better for privacy and reliability that we have not yet implemented.

While third parties will have a difficult time figuring out that a some pubkey just received a RoboSats notification (given that the coordinator will not reuse his privkey), it will still be obvious for the Coordinator that many robot identities belong to the same user (same privacy concern as linking Telegram, only that the rest of the activity of the user is also public!). I believe this is an issue and if we do not want to break the beauty of not re-utilizing robot identities, then the user also cannot reuse his Nost pubkey. This is very hard for UX, I do not think any Nostr client at the moment has the feature to let you cycle through many "burner Nostr" identities (maybe this is a cool feature-niche feature for Nostros?).

The torified notifications via RoboSats Android APP is a better solution in this regard. Both because they are truly private and because the user can make sure the communication channel is UP (notifications do arrive always, on Nostr you might not have that luck). We simply have to get around to implement them :D

RoboSats / robosats