keybase / keybase/keybase-issues

Suggestion: Implement a new proof status: Unreachable

Open
#2,616 0 comments 3 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
899
Forks
40
PR merge metrics
No merged PRs in 30d

Description

I would suggest implementing a new proof status, which could be signified with a yellowish/orange color and icon, called "Unreachable".

Unreachable should be used when the resource where the proof is, is unreachable, eg when the server where the proof is stored, is non-contactable from keybase's end. Yellow proof should still be shown publicity, so a user can still try the proof for himself, but the yellow status signifies that its most likely to fail.

So for example, for twitter, a available tweet should be signified with a blue status, a deleted tweet is red, and when twitter servers are down, it should be yellow.

Notifications for yellow proofs should not be sent unless the proof has been yellow for some time, lets say 5 days. 5 days is a resonable time as its the retry timer that a MTA can expect a receiving MX to be down before failing permanently, and thus is resonable that the server can be down for such a time.
Here, a red status could be switched to when it has been yellow for more than 5 days.

For DNS proof, a NXDOMAIN should result in a red status, while a SERVFAIL or non-contactable should be yellow. Same with web proof, a contactable server who reports 4xx should report red, but a noncontactable server or 5xx, should report yellow.

The reason? Because sometimes things happen out there, a server might crash or need recovery. Or it happens something on the internet causing the server to be unreachable from some parts of the world, or just overloaded. That does not neccessary mean the proof is deleted or unavailable. It might even be available from other ends than keybase's end.

Contributor guide

No contributing guide indexed for this repository

Research direction

No files, tests, or entry points are named. Start by locating the proof verification and notification flows, then trace how DNS, web, and Twitter outcomes are classified. Done means unreachable failures have a distinct yellow status, the stated retry and notification behavior, and the specified red-versus-yellow distinctions.

Written by the indexing model from the issue text.

Assessment

Domain
security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.