Human Friendly Identifiers

[aristidesstaffieri]

What problem does your feature solve?

Public keys are hard to remember and recognize visually, human users benefit from a more memorable and approachable naming scheme for addresses that they commonly interact with and potentially trust.

What would you like to see?

A design for human friendly identifiers. Two viable approaches today are -
Soroban Domains: a PR has been started by @salazarsebas #2949
Internal Contact Book: Off chain solution, inverts the naming responsibility and gives the account owner control of the names. Carries no cost or on chain activity(like keeping your data entry live).

What alternatives are there?

Accept public keys as the main identifier for an account.

[aristidesstaffieri]

@earrietadev one of my concerns about integrating Soroban Domains into Freighter is the level of adoption the protocol has seen. Are you able to provide any context on the future of the protocol? Is there a roadmap or plan to stay active in it's development and adoption?

[earrietadev]

@aristidesstaffieri adoption hasn't been great, most of the integrations were either in my own apps (xBull for example) or in really specific stuff like xlm.sh from overcat

At the beginning of the year, I made a second version of the contract so it was compatible with the NFTs contract design made by OpenZeppelin, because a team said it wanted to work on an NFT market in stellar with it, but as far as I know they are not working on it.

Because this new version required a full migration from the old one, Overcat said that he was not going to support it in the xlm.sh site so that's something I will probably need to do on my own.

The protocol was also limited because of the lack of indexer options on the network I would use, people could not do stuff like querying domains a user had for example and that limits integrations.

But because not having a multipurpose indexer api on the network was also limiting me with xBull (no proper way to have a soroban-focused xBull without it), I decided to make my own indexer, and I already have simple logic to query domains data: https://github.com/Creit-Tech/Stellar-Indexer-SDK/blob/main/src/protocols/stellardomains/sdk.ts

So now that I have an indexer and I can do more stuff, the next step will be having a free API that exposes these things so UIs can fetch them. I will include domains in xBull even if no one else integrates it anyway, so that's why I have been making all these "dependencies" that were needed for me to use it in my apps.

Right now the new protocol has 397 domains registered.

Now with that being said... In my opinion, Freighter should have an internal contact book. Even if it integrates domains at some point, the two things are completely different because domains are for public stuff while an internal contact book is something people will fill in their own style so whether domains are added to Freighter or not, the contact book is something important

[aristidesstaffieri]

thanks for the context @earrietadev , the lack of a canonical indexer has definitely made it hard for the application layer to integrate many protocols. I think this would have to be a pre-req for us as well in wallet-backend if we did decide to integrate Soroban Domains. I do agree that a contact list feature could be compatible with a Soroban Domains integration, we did at one point plan to explore a contact list but in the near term it didn't make the cut for prioritization over other features. I think the best order of operations would be to design the contact list feature and consider where/how an on chain naming solution would fit the feature instead of the other way around.

[salazarsebas]

Thanks for looping me in, and thanks @earrietadev for the honest context on adoption and the indexer situation, that's exactly the kind of signal that should drive a decision like this one.

I've been studying data indexing closely over the past few months, so I have a good sense of how hard it is to index this kind of data correctly, and more importantly, how to do it in an optimized way. That's not a minor detail, it's a real constraint that will shape whichever direction Freighter takes here, whether that's an off-chain contact book, an on-chain naming protocol, or eventually both working together.

I'm available to help with either direction the team decides on, the contact book or Soroban Domains, and can dig into the indexing side specifically if that ends up being useful.