I am not sure how you would get the 60 digits from the other person in your clipboard.
My point is that users should have the chance to know what they are doing. There seems to be a tendency to deliberately keep them in the dark. A 4 digit code is objectively more usable than a 60 digit code.
If verifying these digits make any sense, that means you already have a trusted channel you rely on to communicate these digits. You would use that trusted channel to transfer these digits. How do you want to communicate them?
> A 4 digit code is objectively more usable than a 60 digit code.
It's more usable, but that would assume synchronicity (like a TOTP) or something else to be secure, while the 60 digits do not AFAICT. So there's a usability tradeoff. You can't truncate a hash function and assume it's just as safe. They could add more options on top of the current one though.
Overall I think the intersection of pairs of users who:
* want to verify their safety numbers
* have very infrequent physical contacts
* would struggle to use another trusted channel to communicate their safety numbers
is small enough for this not to be a priority for Signal.
Typically people would compare identity numbers over a voice channel. A sort of biometrics. It's been suggested that Signal add a voice channel feature for that purpose[1].
If a system is using a 4 digit number for identity verification, chances are it is something like a PAKE[2]. See OTR's (Off The Record) simplified Socialist Millionaire's Protocol for a practical example that allows the use of any string based on shared knowledge.
In any case, the user won't have the faintest idea of why they have to do that, so they won't, which in a sense makes this moot.