Implementation of .algo name services in ASA Stats

[ipaleka]

We have opened another discussion here about ANS proposition, and the intention with this one is to discuss the practical ways for implementation of both platforms in ASA Stats, as well as discuss and invite JohnMizzoni to this thread as defined in our Twitter DM:

---

by @JohnMizzoni on May 17, 2022, 10:08 PM:
Hi, would you be interested discussing a possible integration with us at
@NFDomains

May 17, 2022, 10:10 PM
We'd love to hop on a call and discuss how we could work together and what features you could use of ours!

Thanks so much!

---

Hi!

We discuss everything in ASA Stats, so in order to answer your question we'll first open a discussion on our official communication Channel (https://github.com/asastats/channel/discussions). We'd open such a discussion with your proposal.

Are you ok with that?

Btw, our DAO governor and fellow developer Jeremy V had some chats with Patrick about implementation on our website.

Best regards!

---

that sounds great!

---

Well, meanwhile our fellow developer DragMZ had talked with your devs and afterwards he developed a solution that uses Algorand Node instance instead of your API and that pretty much solves all of our requirements.
🔥

---

fantastic!

---

It really is. We'll soon open a public discussion about a preferred ways for solving duplicate ".algo" found for both providers, so we'll link it here afterwards. Regards!

---

Hi!

We're about to open the discussion on our Channel. If you have a proposition you think doesn't fit public space, please let us know here in Twitter DM and then we can arrange a meeting where you can present it to us.

---

So, I'm about to give a proposition for solving the unprecedented issue ASA Stats and Algorand community as a whole have got with this great idea started by our (unclaimed) governor @barnjamin. We have implemented the ANS, while the NFD is going to be deployed on Mainnet on 6/4.

My proposition for implementation in ASA Stats is defined by the following process:

• user enters ".algo" name in the index page's input box or directly in URL (https://www.asastats.com/name.algo)

  Entries are case insensitive, namE.AlGo or NAME.ALGO applies too.

• our engine tries to resolve the name using both providers' dApps

• if only one provider has got the name registered, we use the related address

• if both providers have got the name registered we use the provider where the name was registered first

  Based on a preliminary check of @dragmz work, we would be able to retrieve that information without additional calls to Algoran Node.

• if the address isn't the one our user wanted to show, the user has to enter the name with appended a suffix character to it

Examples:

• name.algo+
• name.algo-
• name.algo2
• name.algo1
• name.ALGORE
• name.algorand
• name.algotendolla

The suffix can be any character, while additional characters will just be ignored. One added character implies the alternative provider. If there would be additional providers in the future, then one added character would imply the second oldest name registered, two added characters would imply the third oldest name, etc.

[wxivd]

if only one provider has got the name registered, we use the related address

That's straightforward.

if both providers have got the name registered we use the provider where the name was registered first

1. Giving priority to the first registered domain does not sound right. This creates additional "subjective" value or weight to the first registered domain, especially the case where suffix implement a sort of ordering name.algo1 ..etc. This idea considers the expected role of ASA Stats as the primary source of price information on Algorand. Therefore ASA Stats should not take part in ranking domains. I would not like a to buy a domain that is ranked 2. another example is where a trader buys a domain featuring existing brand with the view of selling it to them.

if the address isn't the one our user wanted to show, the user has to enter the name with appended a suffix character to it

2. This idea presumes the user know the two domains which may not be true. The values of "human readable addresses" are plenty, including the brand, ease of use and the most important point is accurate identification. There should be no room for error here.

The following idea may solve this issue if it is viable from the technical point of view,

if both providers have got the name registered we display two options

• This brings awareness to the user that two domains exist
• Give them option to select the choice
• Upon clicking on the provider of choice, their handle would

A. Remain as is: e.g. Binance.algo is represented as https://www.asastats.com/ATXMIVSPIHEEIEZWG4OZC3LUS2HUYJ5HRNKGYMD3JWYHTHNFJ3TVQYNXPU
B. Include suffix that features domain provider
Name.algo/ANS

[ipaleka]

Yes, this goes in line with @dragmz opinion, to let users choose the provider from the UI.

The thing is that we have to deal with fixed entries. User has to have the option to apply provider directly in URL, input box, or as a part of a bundle.

A solution for that is "Name.algo/ANS" or "Name.algo/NFD", yes, so when user picks one from UI the way you have represented, the URL will actually become https://www.asastats.com/name.algo/nfd and our engine will redirect it to https://www.asastats.com/ABCDEFGIJ..... So if the user picks a provider through the UI, they have to have an option to not pick again for the same name.

This discussion is to explain the need for having such a distinct URL and to find a solution that fits the best.

My intro suggestion had been to pick a default after a user uses basic name.algo and if they are not satisfied that they use an alternative form (name.algo+).

I'm for whatever option we choose under the condition that the user doesn't need to pick every time.

[wxivd]

A solution for that is "Name.algo/ANS" or "Name.algo/NFD",

This looks perfect.

My intro suggestion had been to pick a default after a user uses basic name.algo and if they are not satisfied that they use an alternative form (name.algo+).

I place much value on standardisation, I do not encourage giving options to use alternative, even if it is an advanced feature (also we have priority features to implement first). I am keen to listen to other views.

[ipaleka]

During @jeremyv3 talks with Patrick from NFD, we decided to apply for a reservation of the asastats.algo name for the NFD service. We just received the following email:

---

Congratulations! Your NFD: asastats.algo is reserved for NFD Mainnet!
The name will be waiting for you to 'claim' when you connect with the Algorand account address you provided: VKENBO5W2DZAZFQR45SOQO6IMWS5UMVZCHLPEACNOII7BDJTGBZKSEL4Y4
Connect your wallet, then go to Manage -> Reserved and you will see your name(s) waiting.

Launch is this Saturday, June 4th at 5:00pm EDT. We hope to see you there!

https://app.nf.domains/

---

Btw, the core research and development for the implementation was conducted by @dragmz . We'd probably implement NFD together with ANS based on this suggestion.
#120

[ipaleka]

We have implemented both providers, with a workflow as suggested by initially DragMZ and SCN9A in this comment.

By entering name.algo in the index page's input box or in URL (https://www.asastats.com/name.algo), the engine will check both ANS and NFD. It will proceed to the registered address page if the name is registered only at one provider.

If the name is registered at both providers then such a name will be presented in the input box with two providers' icon buttons below. By clicking on an icon, the provider's code will be appended to the name:

Append a provider's code in order to directly access the provider's database:

https://www.asastats.com/name.algo/ans

or

https://www.asastats.com/name.algo/nfd