Surfacing reliability metrics in design guidance

[weex]

One of the main issues I face across many apps is knowing whether my notes got posted. When I do get feedback it's not generally actionable because there's no detail that's easy to access. For example, it's hard to know which relay didn't get the post, or if I connected or still connected to a particular relay. The result of not knowing these was subscribing to failed relays or not paying for paid ones. The overall uncertainty left me asking if my notes are getting to anyone at all and questioning if Nostr works.

The solution I propose is to make reliability a first-class design consideration. I understand the desire to hide the backend as much as possible but if it's affecting UX then we should err on the side of surfacing errors while the community is small and enthusiastic so they can be fixed across the system and get it ready for the next stage of growth.

[weex]

Continuing this thought, I still haven't found any site that shows any kind of reliability metrics. Maybe this is an opportunity in the shorter term for a kind of note ping tool.

[karnagebitcoin]

Snort has a note status tool that shows which relays the note went to, or which rejected it. We thought this was a great idea, but after using it for a while people have complained (and I am also annoyed by it). I think we could design a less intrusive version and I have taken a stab at it, but there is not much development desire to implement these things.

Instead of showing all the relay statuses, I think we could show just the ones that failed, and have this feature be a tap / hover instead of showing all information at once. On desktop you'd hover over "2 relays failed" for example, and it would show you which relays failed to accept the note (with options to do something about it, delete relay, try again, etc...)

On mobile you'd have to tap that number (probably in red) to see those stats.

What do you think?

[weex]

As a user, I'd love it if there were more stats for nerds in a sense that the developer has helped me make good decisions. Ping times, posting success rate, and relative lag come to mind as metrics I'd like to see more of as a user. I suppose for a design guide that it's enough that there be a section somewhere with a couple examples, not that it needs to address every use case.

It still feels early enough for Nostr and reliability a recurring enough issue that the guide deserves such a section. If you agree that reliability is important then I might try composing a PR or would be happy to collaborate as far as editing.

[karnagebitcoin]

I think the relay settings could probably use more information. Some clients are doing better than others. If you have some ideas for that that'd be great!

[dtonon]

Coracle has a HUD (head up display) in the right bottom, that tries to give some insight in a gentle way.

Some time ago, before the HUD, I designed this interface to improve the communication about issues when posting:
coracle-social/coracle#411

Since Nostr communication is highly asynchronous and has a fairly high failure rate, given the distributed nature, I think this type of solution should be included in a design guide.