Let me give it my best shot 
Before starting, I would have been interested in understanding the why and what for, form this project (if you can say it of course), what/who are you targeting. I felt I was missing the purpose to be able to get the reasoning behind most choices.
The user base we are thinking of at the moment are all Tezos users - people who have their Tezos wallets and probably own some Tezos currency. There are definitely good prospects of supporting other blockchains or completely generic meta-data. They are not the primary motivations right now though.
You can check out the first article for some broader context.
Edit: TLDR the project is meant to associate primarily names to Tezos addresses.
Name: I am a strong Tezos supporter but doesnât understand why blockhains projects always need to put the infrastructure in the name.
To be honest, I donât have a strong opinion on the name. Two points that come to my mind are:
- Names should easily associate with a concept, if possible. As we are not seeing this project as a generic dictionary of things yet, we wanted to include Tezos as part of the name.
- Projects can be renamed, reformed and restructured. When the service becomes more, it can always be reflected in the name.
Auction vs FIFS: No strong opinion here. And maybe depends on implementation I suppose. If someone wants do buy a domain name and he is alone, I hope no Auction should be triggered. So I suppose, Auction is here at first where FIFS happen more in the future?
The FIFS model is meant to trigger when demand for a domain is zero. When the service (or a new TLD) launches, we canât make this prediction, so an auction would be triggered for all new domains. However a domain that had no bids goes into FIFS and can be purchased immediately.
As for the rental model - yes we currently plan on requiring renewals. There are two opposite approaches:
- You require renewals and try to maximize the utilization of the namespace. The theory goes, if people are required to renew their domains, the domains are likely to be utilized much more efficiently. People who donât use their domains will not keep renewing.
- You treat the domains as tokens - register and forget. This can be a popular approach because people donât have to make take additional actions or think about renewals at all. One problem is that there is virtually infinite supply of names and people are likely to exhaust usable names much sooner. Another one is that names can be lost over time - people can lose their private keys or forget about the name they register. Thinking about names as ânon-perishableâ NFTs can be problematic in the long run.
- Proxy Contract: To me this one is a crucial point (from my understanding) - Could you ensure the incapacity from an âAdminâ to censure any domain? Letâs say, someone publish an article a government doesnât like via a Tezos Domain.
In theory, yes. In practice, if the contract is controlled by a DAO, itâs very unlikely that the DAO will agree on a censorship action without extremely good reasons.
Unicode and look-alike: You conclude Security over Usability, which may indicate here, you are not interested in adoption but building something reliable for latter, I might not follow and again not understand the purpose of this TD. Plus, here the security of the system is not challenged, itâs mainly the end user who might be impacted by not being attentive. Couldnât those be solved with a âflagâ or kinda good old âgoogle ratingâ and a mention not to trust any newly created/unflagged/un-rated address.
While itâs a good idea in general, there are technical limits to what can be achieved on-chain. We are trying hard to make blockchain the âsingle source of truthâ, especially when it comes to a flag that relates to security. For this reason, our approach is to come up with an âall-or-nothingâ validation that we know can be implemented on-chain, at the risk of it being more restrictive. Our goal right now is to keep the door to Unicode open and deploy extensions when any new Unicode namespace is properly analyzed and implemented on-chain.
