Bugfix: NIP-05 strikethrough in bad networks #1210
Conversation
| } | ||
| self.verifiedNip05Identifier = isVerified |
There was a problem hiding this comment.
I removed the animation because for the normal use case (a valid NIP-05), the animation causes an annoying blink. See relevant comment here https://planetary-app.slack.com/archives/CM4EPK324/p1717187450297749
I tried to add an if that executes that just when isVerified is different from verifiedNip05Identifier but it didn't work right away and decided not to continue with that line just because I think the animation is not important in this case and we can just remove it for all cases. If it were important, I think we should re-try the if line, eventually we will find out the solution.
martindsq
changed the title
| } | ||
| self.verifiedNip05Identifier = isVerified |
Nos/Views/NIP05View.swift
Outdated
| // Cancelled requests are common in bad networks. We | ||
| // should keep things as they were to avoid reproducing | ||
| // https://github.com/planetary-social/nos/issues/1161 |
There was a problem hiding this comment.
I appreciate the comment here to explain what's happening. I think I'd go a little further -- in order to fully understand this comment, you need to open the link. What if we include a brief description of the issue right here so the reader doesn't have to follow the link? We can still keep the link so they can get more detail.
There was a problem hiding this comment.
Yeah, I agree with you. Let me correct it.
|
This PR is fine but also kind of misses the point. We should be caching the status of nip-05 verification and using that. The most common thing to happen is the user sets a nip-05 verification and then the server is flaky. In that case we should continue to show it as verified while somehow some slow background process might check to update. Failure to connect should not reset from verified to not, it’d need to be something more like that service IS online but no longer serving the valid data fro this user. |
I totally agree with you @rabble . As I explained in this slack comment yesterday, we should cache the NIP-05 validation, we are doing it all the time and that's too much. I'll open a ticket so @setch-l is aware of that and can prioritize that work accordingly. |
Issues covered
#1161
Description
While we don't show the NIP-05 with a strikethrough when we are fetching the server response, we do show it if the request fails. In order to fix this specific issue, I'm catching the "cancel" reason. This happens when we cancel the request programmatically, but also frequently happens when the user has a very bad network (I'm not sure why, we don't cancel the request programmatically, I want to find out).
Also, relevant discussion here https://planetary-app.slack.com/archives/CERN44F17/p1717190530026669?thread_ts=1717185627.726309&cid=CERN44F17
How to test
Screenshots/Video
It doesn't make sense to post a screenshot for the "after" state. But I can post a screenshot of how the bug looks when using the app with a bad network: