Issues of the handle and improvement ideas

[KingYoSun]

There was a bit of a ruckus in the JP community the other day. Detail
I found issues of the handle, and thought improvement ideas.
Some issues are already open, but I will try to implement some of the ideas myself.
I post here because I want to hear what others have to think about this issues.

---

Users identify each other by the handle now

About

• The DID is hidden in the UI, users are not aware of it.
• Fake (spoofing) accounts are effective against users who do not have a follow-follower relationship, as in the Eugen Rochko’s case.

Improvement Idea

• Display a (shot hash of) the DID in clients (e.g. tooltip)
• Display change history of the handle in clients.
• Other improvements in identification?

Implementation

• Reference implementation (e.g. in my repo) for unofficial clients
  • It would be easier to any developer of clients.
  • The record can be got from plc.directory.

---

A different user can reacquire the handle immediately after the handle changed.

About

• Bad UX that users have to worry about spoofing when changing handle
  • Currently, the only way to prevent this is to get a sub-account.
  • There is widespread concern among JP users about identity theft.

Improvement Idea

• [Same issue is open] Moratorium period. For example, Twitter or Google Developer Profile. Same handle cannot be reacquired constant period.
• Leave alias with DID after handle change (one DID has multiple handles)
  • It is better to set a limit on the number of aliases (2 or 3?), since unlimited aliases will allow an unlimited number of handles to be obtained.

Implementation

• Need to change did-method-plc
  • Increasing length limit of alsoKnownAs . Looking at [https://plc.directory/${DID}](https://plc.directory/${DID}) , alsoKnownAs is defined []string.
    • When operating from PDS, it is easier that to select the handle to change from among the alsoKnownAs .
    • Unconfirmed if it is restricted by did-method-plc, could be PDS.

---

Duplicate handle can be obtained for different PDS

About

• The handle must be changed when moving the PDS, because the uniqueness determination in plc.directory is probably "handle + serviceEndpoint”.
  • Hard to move to a PDS where same handle has been acquired by other user, because the handle serves as personal identification subjectively by each users.
  • Isn't this bad from the point of view of account portability, which is the concept of ATProtocol?
• It is confusing when users with different DIDs of the same handle are lined up in the search results from the crawling indexer.

Improvement Idea

• On the same plc server, it is better to make the handle be verified as unique so that users are not confused.

Implementation

• Uniqueness determination by handle when registering DID

[ghost]

Measures for verifying identities and countering impersonation are poor in general. It doesn't help that there isn't a roadmap or even a consensus on how to improve the situation from what I have seen. Things need to improve dramatically before Bluesky leaves closed beta and it would be nice to know what solutions the core team has in mind.