Unified notifications across different robots

[jacobburrell]

Is your feature request related to a problem? Please describe.
When having several robots with an active order, and not opting into Telegram notifications, it is necessary to constantly switch between each robot to see if any have an update.

Describe the solution you'd like
Notifications should be triggered based on any robots in a garage.
A sound and a clear indicator on the robot in the garage drop-down.

Describe alternatives you've considered
A notification tab/window/pane to easily identify which robots have new/unread notifications. This would entail more work, but could help organize more complex situations with several notifications coming in from several robots.

[Reckless-Satoshi]

Hey @jacobburrell , thank you for bringing this up.

This is indeed the vision for the Robot Garage (specially for the PRO frontend). Each slot of the garage has 2 objects: a robot and an order. Ideally all orders are followed continuously for updates. However, at the moment we keep the order fields unpopulated and we only constantly fetch updates of the currentOrder instead of every order in the garage. The main limiting factor was the auth method (sessionId+csrf), i.e, in order to fetch order status of multiple robots each of these robots must be logged out/in constantly. It would also leave a trace of common ownership given that they would share the same sessionID cookie.

With the recent merge of #512 (Token based auth) we can go ahead and implement the more complex Robot Garage vision without having to do extra API calls for login and without sacrificing privacy.

The enhancement to the Robot Garage will, however, take some time to come unless someone wants to take control of this task: #302 I am mostly focusing on the work needed for decentralization as this is top priority. After that, I will work on more user oriented features.

[jacobburrell]

Awesome!

Makes sense and looks like this is manageable both through Telegram and via the use of the API in the interim.

Is there something such as an integration with n8n which allows automating tasks outside of Robosats? If not, I can write a simple node to handle the actions and perhaps hook it up to a Robosats manager of sorts which wouldn't require an n8n instance. Ideally eventually integrated into RS too. Putting the robot to work in Robosats.

E.g.

• Renewing an order (which requires control over the lightning node) could be done for now without requiring HTLCs that last much longer for instance.
• Auto-responding with payment info and other repetitive messages once the order is taken to avoid delays. Ideally, RS would allow you to post payment details at the point of creating an order as other P2P markets do. Airbnb has an easy-to-use system that is a great example.

I find that often if I post a not-so-attractive offer, it is often taken, but might take several days. In instances in which there's no rush, this allows Robosats to gain larger liquidity by having many more makers have orders pending.

[Reckless-Satoshi]

Is there something such as an integration with n8n which allows automating tasks outside of Robosats? If not, I can write a simple node to handle the actions and perhaps hook it up to a Robosats manager of sorts which wouldn't require an n8n instance. Ideally eventually integrated into RS too. Putting the robot to work in Robosats.

I am not familiar with n8n, but this sounds like a great idea. Would be amazing to build something with it. What would be the steps?

**Renewing an order** (which requires control over the lightning node) could be done for now without requiring HTLCs that last much longer for instance.

Indeed, great use case.

Ideally, RS would allow you to post payment details at the point of creating an order as other P2P markets do.

Another useful use case (this is envisioned also for PRO, and will require an always-online client). Auto-replies from an online node are the preferred way. Unlike other P2P markets, the payment details cannot be posted before the order is taken because these have to be encrypted using the taker's public key (trade coordinator must be blinded).