@oetyng Philosophy is good - thinking around and from different angles has benefits IMO.
I was thinking about this from scratch again, including the point you make about owning things forever which I hadn’t thought of before.
I arrived at familiar places (ideas, pros, cons) but also a better grasp. So I think the revisiting and reworking that happens in topics like this is useful. I was never saying it wasn’t BTW - just that it is hard to work things out with only our imaginations to guide us and in that realm, without evidence and experience to guide us it’s easy to get things wrong.
I don’t really like the domain name model for the reasons most of us agree, but to date I’ve not seen anything that seems better than that to me in regards to simplicity, familiarity and workability, with all its faults.
I do not though think it is necessarily right for SAFE because our present implementation is different (names don’t expire for example) in ways that mean it too won’t necessarily work as we imagine. I’m not ready to abandon it yet though! It’s still my favourite, ideally with some features to mitigate squatting if we think that’s possible (I’m not even convinced of that yet even though I’m suggesting it). So I am open to alternatives.
One observation which I agree with is that it won’t be the only game in town, and I don’t think Maidsafe need to do anything to ensure this. Resolution happens in the client, so any client or browser fork can have its own naming scheme. And any client can adopt any number of such alternative name resolution schemes.
We might want to encourage it though if we think its a priority, at least by ensuring it can be done with a browser plugin.
Anyway, in some ways the scheme we are debating is only special because it will be supported in the initial official applications, and applications which follow the convention.
This means that I’m less worried about names lasting forever - a new scheme will always be available, and could be adopted widely, leaving old schemes to atrophy.
Where universal permanent links are needed, we will always have the xor addresses, and in time I expect client apps and users will adapt to multiple schemes, with xor as an underlying permanent layer. So I suggest that the most important feature of the initial name resolution scheme may just be to help the transition - by being familiar and easy to adopt. Later things can evolve regardless of it.
This is where it gets hard to predict how things might play out, but a useful analogy might be blockchain forks. So, for example the Doge Naming System , and all manner of schemes with creative quirks , perhaps rentable names, expiring names, etc if there are attractions for such features. I’m not saying there are, but I can imagine there might be for some.
If what I’m saying is true, maybe all we need to do at this stage is ensure that the current naming scheme is fit for purpose. Later, the fact that it is entirely in the hands of clients rather than a centralising body means that there will be alternatives, and battles for users between those backing them.
I can imagine people trying to gain users by offering goodies in the client, emoji names for example, themes for different groups etc.
In some cases we want universality, in others perhaps groups want their own resolver ‘lingo’ that only works for users of their particular protocol, and this could even be restricted to members of the group.
I’m not saying any of these are good ideas. What I’m saying is that we may not need to worry as much as at least I have been doing, about the initial name resolution system. If it performs badly in the long term - ie no decent names left - that creates a pressure for an alternative to be adopted and for clients to add support for alternatives.