During the summer, there was some work done in the area of introducing subdomains to AE Naming System.
While the implementation is complete, it’s better to look at this endeavor from the research/prototype point of view - validating that we can have reasonably usable subdomains with minimal impact to the rest of Naming System. It shouldn’t be understood as a final, production ready implementation with polished user experience…
Still, it was worthwhile to find the limits of the approach chosen for this prototype.
If you are interested, you can read more in the paper here: Prototype of subdomains implementation for Aeternity node.pdf
Good write up on the prototype, thanks!
Can you consider adding examples?
What are the constrains on subnames? Can we transfer them, etc.
If not, what are benefits of that?
Also, can you describe potential future work that is not under minimal-impact requirement.
What are consequences from diff updates to the tree from crypto-economisc (and danger of DoS attack on miners)
Hi @michalzee, thank you for valuable feedback!
I’ve updated the paper, showing an example how to construct the subname transaction and potential future approach to the implementation.
Several things like transfer/revoke - they way how they should function depends on the end user utility and expected behavior - this is, as such, not yet clear at the moment and should be area for discussion.
Regarding the last issue - diff updates from crypto-economic point of view - once we don’t have such a strong limitations, we would be able to represent subdomain tree naturally by storing parent child links.
Such subdomain tree cache, kept outside of consensus, would also be able to lookup subdomains directly by their ID.
This would prevent us from walking the hierarchy from the root (top-name) and would provide (amortized) constant-time lookup to any hierarchy tree node.
In practice, we would also implement limit on the depth of the most nested subdomain, as it’s questionable what utility does for example 20 levels deep subdomain bring to the end user.
@karol.chain @michalzee is there still work ongoing here? subdomains would be a really great feature and are probably needed at some point if we expect the naming system to be successful.
Probably @bruteforce.chain can also share some information here.
Hi @marco.chain,
this prototype was more or less exercise if we can fit in some form of subdomains functionality to AE node before Lima hardfork.
While we showed that we could have something, the usability wasn’t great. The most limiting factor was a need to provide a full subdomains tree to when changing any subdomain (or pointers).
So, currently there are no plans to continue with this prototype, although if there’s more push from the top we could come up with more user friendly system.
thanks for that information. but what’s the alternative? building another naming system on top of aeternity like ENS on ethereum? 
I guess many people using the naming system would like to see subdomains being implemented.
another question regarding the pointers. I was a bit confused in this discussion:
I always thought the pointers behave like a key-value map. but in fact it is true they for a key (e.g. account_pubkey) multiple values can exist but only the last one is relevant right?
We certainly can build solid subdomains on top of our AENS, but at the moment it’s not a technical question but product one - if it’s valuable to invest time in it.
The behavior of pointers is that the name record can have multiple pointers with the same key, but only the most recently added value for that key can be resolved. So it’s a map-like behavior, where we internally still keep previous values. Ideally we could improve on that.
2 Likes
This is an excellent question to discuss on the governance aepp.
1 Like