Ability for the maker to send message to specific takers

[da-kami]

Give the maker the possibility to send arbitrary messages to a specific taker. This is not supposed to be automated, but more a feature for the maker UI.

In the past we thought about giving users the ability to contact a maker, however, issue like #1617 have shown that it would be great to "ping" specific users in their itchysats app when a maker notice that something went wrong.

We don't have to build in chat functionality, it would be good enough to show a message from maker to contact the maker. This helps takers to understand that something did not go as expected and the maker can provide more information.

[thomaseizinger]

The ability to send free text messages will result in spams and scams. I would strongly suggest to not implement this on a protocol level.

This sounds to me like it can be solved purely client side by monitoring for problems (like failed rollovers) and alerting the user in one way or another.

[da-kami]

Why would a maker want to spam the taker?
This is about problems that are detected by the maker, but the taker actually does not know there is a problem. It's not the first time we run into this issue.

[thomaseizinger]

This is about problems that are detected by the maker, but the taker actually does not know there is a problem. It's not the first time we run into this issue.

But that is not true. With #1617, the client could have detected that the rollovers are failing. It did not detect the actual problem but it certainly would be able to detect some symptom of it.

Why would a maker want to spam the taker?

It is not about wanting but providing the capability to. My point is that a on a message protocol level, it is better to design specific messages instead of free-form text. Next minute, you will find yourself using this free-form text field for all kinds of stuff, essentially drafting up ad-hoc protocols that never get properly specified and cause weird bugs.

When designing protocols, you have to assume that a provided capability will be used in all ways possible which is why the act of designing protocols is about actively constraining yourself in what you can do with it, just enough that it covers your usecases. The consequence of that is that you can build systems that are easy to reason about.

[thomaseizinger]

Meta: Converted this to a discussion because it needs more thought on how it should be implemented.

[thomaseizinger]

Here is an alternative idea:

We could extend the UI to allow the user to optionally "register" their instance with an email address. We could do that by generating a signed message (with their identity private key) that the user can email to an address of ours which allows us to reach out to a taker with a specific ID.

[da-kami]

This is definitely a nice idea, but I am not sure it is related to what I propose. I feel this would be a different feature.
I would love to have the possibility to interact with user while using the product.

Besides that, we can also add the "registration" via email if we want, but I see this as something else. For the specific problem with the one taker in question communication via email might have been useful. I think it might be a good idea to ask users what hey would prefer.

[thomaseizinger]

It is a different feature yes. It is a more privacy-friendly alternative to actively pushing messages that allows you to more or less achieve the same overall call: Talk to a taker with a specific ID.

[klochowicz]

It is a really nice idea. We could also add a note suggesting using some one-shot email addresses, so that users privacy is preserved.

[thomaseizinger]

I would love to have the possibility to interact with user while using the product.

Sure, that would definitely be ideal. I just don't think it is worth investing resources into building a communication infrastructure even if it is dead simple when off-the-shelf solutions like email exist and will get us 80% there.

Perhaps there are JS email clients that we can integrate? I am not sure if it is possible to speak SMTP over HTTP somehow but then the user could use their own email provider. Maybe once-off email providers have client libs for this?

Matrix would be another option.