I don't know, I think it's a serious problem if someone mention me and I do not receive notifications when I should. Maybe could have some logic that when this happens, the client ask to the user retry to republish? I mean in the case where the user was using Jumble client too. For example: The user click post and close Jumble without waiting to publish to all relays. So the user open Jumble again, and maybe should ask to republish to all relays that the post should have be published?
Discussion
It’s hard to track reliably, and in some cases certain relays are simply unreachable.
If be unreachable, would fail again and the user will know, no?
Maybe it’s just that the other person set unsuitable relays, or maybe only one or two relays failed — should the user really have to see error messages all the time for that? In most cases, a few relay failures aren’t a big deal. If you need absolute reliability, that’s what centralized platforms are for.
Understood. Thanks for taking time to always explain me things.
That said, it’s true that Jumble marking a post as successful after just one relay accepts it isn’t ideal. I’ll adjust it so it only shows success once maybe a third or half of the relays have confirmed.
I just would like something like:
1- The person has for example four write relays, he reply someone, goes to only one relay. The UI show a message like: Reply tent to only one relay of four that you have. Do you want to try to send to the others relays or skip and send to just one?
*reply sent
Usually a reply gets sent to around ten or more relays. To achieve what you’re imagining, you’d have to wait for all of them to respond or time out, which would make the user experience really poor.
what would be better is a queue that just tries, when it succeeds, remove the item from the queue, and retry the others with an increasing delay until it's like 5 minutes then give up
What I don't understand or what I don't want to understand, haha, is:
Why we don't have a way to know if our reply was or not published on a read relay of the person we are replying? Because if we know that it was not, the Jumble UI could show a warning that the user we replied didn't get a notification and maybe show a way to try to notify the user.
We can know whether an event was delivered, but doing so would make the publishing process feel very slow.
I don’t think it’s worth sacrificing the experience for these rare cases. In most cases, sending succeeds, and if it fails, retrying will likely fail too—it could be a network issue or the relay simply refusing your event.
>I don't know, I think it's a serious problem if someone mention me and I do not receive notifications when I should.
This is just life on Nostr I think. We can either accept it or move to another decentralised network that takes different trade-offs and where this doesn't happen.
I think the UI could have more explains to the user when these things happens.
I think it's a physics problem, the UI cannot know what hasn't been confirmed to it. And confirmation on Nostr is often impossible, too many potential points of failure to confirm what point failed and for who and when and what to do about it. So the UI will have no idea what to explain or not to explain.
Nostr is just not good for air-tight communication, there will always be leaks.
I think it's a case of changing how we use Nostr, that is the biggest problem right now and why Nostr cannot grow.
Most normies, once they have an experience like you (they realise that they missed an important reply) will never trust Nostr again and fade away. And telling them not to worry about missed replies because "it's just how Nostr is" won't bring them back.
What we need is a whole new way to use Nostr.