Messages not going through for iOS

[ecurrencyhodler]

I messaged dread who is a lite user (android). I am also a lite user (iOS). Some messages didn't go through.

What might be a reason to cause this issue?

[ecurrencyhodler]

Here's another example where messages didn't go through from me to raph.

[ecurrencyhodler]

I wonder if we should prevent sending these message if they aren't going through. I know they're not going through because there isn't a lightning bolt. But that's a very subtle indicator and I even miss it sometimes. I wonder if we should just fail this sending message instead.

[ecurrencyhodler]

Okay apologies the second comment was desktop. I'm going to repost that one in mac desktop.

[tomsmith8]

After chatting @tomastiminskas this is not related to apps. This is an issue with relay/lightning (I'll create a ticket to investigate).

Having no confirmation sign means the message didn’t go through OR the confirmation message back from the receiver didn't come back. @tomastiminskas Could we make this more obvious that the message didn't go through?

[ecurrencyhodler]

Thanks @tomsmith8. I know I saw a "failed message" somewhere in sphinx chat b4. Not sure what triggers that but we could reuse that.

[tomastiminskas]

@tomsmith8 the bolt sign shows up when the confirmation arrives. If it's not there it could be because the message failed on lightning or the confirmation failed on lightning. Apps have no way to know which one of those happened as it's built right now.

To differentiate between message not delivered and confirmation not received we should do changes on relay

[tomastiminskas]

@tomsmith8 this is why we have the additional bolt sign on the chat view header. That represents if there's a path to destination. Every time you enter a chat a queryRoute lightning command is run. If it success then it becomes green, if it fails it becomes yellow. So in the case of a sent message with no confirmation sign, if the bolt sign in the chat header is green it's more likely that the message was delivered, but the receiver has not path/route to you, so confirmation couldn't come back. If the bolt sign in the header is yellow instead, then it's more likely that the message was not even delivered. Let me know if that's clear for you

[Evanfeenstra]

We have the error_msg field on Messages too now... we can use that to show if a message send failed right? What other changes on relay are needed @tomastiminskas ?

[ecurrencyhodler]

Is this specifically for DM's? In DM's should every message have a green bolt?

I ask because there are times in tribes where I don't see a green bolt but I know that people in the tribe have received it.

In this example, the first message has a green bolt but the second one doesn't. But it's clear paul saw it because he replied to it.

[tomastiminskas]

@ecurrencyhodler messages are grouped with previous one just if the message is confirmed (bolt sign). So in that case you can assumed the second message was delivered and confirmed

[tomastiminskas]

@Evanfeenstra I can use that to show the failed messages, but to do it in real time we will need a new socket message with a different new type that should be triggered when the message failed and should include the message object (now with the error_message column set). Let me know if it makes sense, and if you can do that and deploy to my nodes, then I can test and implemente the app side changes

[ecurrencyhodler]

Okay this is true for dm's and tribe chats?

messages are grouped with previous one just if the message is confirmed (bolt sign).

So on both the screenshots above with island bitcoin and raph, I should expect a green bolt on my messages because we alternated. But if I send multiple messages consecutively and no one else responds, then I should just assume they went through?

That might be a bit confusing.

edit: I don't think this is a blocker. But maybe should be something we create an issue for to review from a UX experience.

[tomastiminskas]

@ecurrencyhodler yes, this is true for all chats. The app will grouped just confirmed messages. Actually you can see that just after being sent the message is not grouped, and then it groups after a second or two once the confirmation gets back

[tomastiminskas]

@ecurrencyhodler I think Milan was already working on some UI changes to show the status of the message inside the bubble instead of showing that above it. That way grouped messages will have their status visible. Is that correct @Antanasijevic ?

[Antanasijevic]

@tomastiminskas @ecurrencyhodler Yes we explored few options of layout changes. It is still in the concept phase, and you can check it out in these two tickets #252 #253

[tomastiminskas]

@ecurrencyhodler @tomsmith8 I will release new versions for iOS and Mac today with some changes to start showing failed message status header on message bubbles with the error message coming from relay. We can improve designs later if needed with Milan's help. So relay now waits for lightning payment response before returning endpoint response to the app, so at the momento the message is sent the app will know if it succeeded or failed.

Here is a example of how a failed message will look:

From now on:

• Failed status header: means the msg failed and was not delivered
• No failed status header and no confirmation sign: the message was delivered but the confirmation didn't come back. It could be because the receiver of the msg can't send payments to you or because the confirmation failed
• Confirmation sign present or grouped bubble: message was delivered and confirmation was received.

This depends on relay changes so if you run the new version and this is not working as expected please check with Evan or Kevin so they can deploy latest relay version to your nodes