The ☰thereum Foundation DAO (upon formation) could open-up a vote, for
The Community to suggest and discuss which TLD's (Top Level Domains) we might initially have included in the ☰thereum
Domain Name System (☰ÐNϟ)
Candidates could include:
This is just a preliminary list off the top of my head. Architecting and implementing a resilient, sensible, long-lasting, name-reg system, will be a challenging initiative. One that will require input from the broader nodal community.
Since 'eth' is also already associated with 'ETH' and 'Ether' (☰thereum's internally based cryptocurrency; token; coin; product) it may introduce unnecessary confusion if
.eth were also to serve as a TLD.
The existing combined values of the term "ETH" as a cryptocurrency and
eth:// as a DPI (Decentralized Protocol Identifier) - or to use a more headache inducing technical description:
eth:// as an abstraction application layer, for process-to-process distributive transmissions, across a decentralized communications value protocol - are both already substantially significant use cases.
Responsibility for the structure and management of any
eth:// Top-Level Domain Names that are introduced and eventually implemented into ☰thereum, could be effectively managed by specific DAO's. These organizations would form freely and organically, at the outer edges ov ☰thereum. They could then seek consensual TLD authorization via submitting TLD proposals for
The ☰thereum Foundation to review and approve.
These types of organizations (DAGR's; Decentralized Autonomous Governing Registries) are effectively equivalent to what
Domain Name Registries are over in
http:// land; where new TLD's are added into the DNS by
ICANN and
IANA.
((extra credit for the trvly 1337))Opening up the conversation around The ☰DNS will enable ☰thereans to have an input in the crafting of best practices for TLD addition to the ☰thereum DNS.
The ☰thereum Foundation could structure a simple contract facilitating the frictionless and effective review of these and other processes, proposals and administrative tasks pertaining to decision making that would best be served if direct input from
The ☰therean Community were taken into consensual consideration.
So here we are
deep in the transitory phase..
☰nduring the cross-over..
This period ov limbo
inwhich we now
find ourcellvescollectively submerged,
makes it hard to sleep..
Ideas ov all sorts,
pouring forth,
Δwakening Ðreams.
What is IT?
This New ☰arth 0perating ϟystem
we are imagining.....
Like Andreas Antonopoulos has mentioned so many times in the past:
"Something like bitcoin, in theory, doesn't work.
Just as, wikipedia in theory, wasn't going to work.
But it works. It works really well."By introducing such 'grandiose undertakings' like ☰thereum, we are effectively formulating the collective manifestation of a distributive, voluntarily integral, societal system.
I may be headbanging with the choir, but 'this thing' we're building is going to greatly assist us in Ðefining new social parameters and constructs, which
may aid us in our life living interactivities and ultimately in our specie's solunar cosmik evolution; beyond beyond.....
:: Carl Sagan's ghost exits the stage ::
☰thereum, like Planet Earth's mycellium network, may come to be the etheric infrastructure, or digi-astral body ov the human psyche. It can spread, propagate, and convey nodal-nutrients over great distances, eventually sprouting fruiting bodies — like our
ϟacred mushrooms do. This means that no matter how many nodes fall off the network, more shall pop into place and the cycle ov the galactick continuum sails forth
Ad infinitum think
re:generative death/birth cycle.☰thereum re:presents
an orthogonal opportunity to plug directly into
the $ocioϟpiritual ecology
ov th33 species.
There are XXXtra-dimensional KINsideRaySuns and real3Y3ϟΔZ☰Ns that shall be grasped at upon ☰thereum's emmergence within
The VVorld Soul. Realizations that lye beyond simple cognitive accessibility at this layer/realm/array ov dualistic paradigmatic receptivity (binary frequencies flying from pixels beamed by glowing screens).
☰thereum will be one ov many bridges, ϟerving and Δssisting Th33 PlanIT in its ☰xpedient Δctivation ov th33 inÐiviÐual and ☾ollecktive neurosomatic infrastructure.
Of course this is all just an angle on things.. but the DNS system of the ☰thereum protocol is a critical component for the long-term success of the ☰thereum undertaking. As is the proper establishment of
The ☰thereum Foundation - being a truly Decentralized Autonomous Organization.
Still, it's very early days.. I suppose.
Comments
You could do a simple mapping between Ethereum addresses and IP addresses but then why is an IP address superior to an Ethereum address? If I can virtually link an Ethereum address to any other data point, why do I want to have people crawling the network for a specific machine to respond when I can stop operating on purely client/server terms altogether?
People don't want to use a URL either. We've dropped the protocol from the location inputs, we've dropped all the subdomains we could ("www"), and we've adopted patterns to more effectively communicate the intent of a URL. Despite this I can't type links from memory and if you think you can then try giving me the link to where Amazon lists books. If you do look it up you'll notice that it's barely intended for humans; it's engineered for machines to calculate search rankings.
Rather than uncovering the Ethereum parallel to DNS or the URL, what would be a better solution that Ethereum makes possible? What is the actual problem? Can we integrate with DNS as-is through protocols that just fill the gaps? Can we add an entry for DNS that binds the record to a more reliable record in Ethereum? Is it possible for everyone to have their own local vocabularies and link to reputable fallbacks? How does that fit into the larger identity metasystem?
DNS works for the internet because the only first-class entity is a device. In Ethereum, it's possible we can make everything a first-class entity as identity is independently generated, privately held, and can be assigned to more than just devices. Mapping a URL to an ethereum address may be as simple as signing a HTTP header property or using host-meta or webfinger. So before we rush into repeating the past let's stop and think if we're living in a different kind of present.
I'm experimenting in this area. I hope that others do too.
Concerning the "eth://"-notation, which I first really liked - I meanwhile think it's a bit misleading and probably obsolet. Since we use this notation normally to address a service in a protocol:
<protocol>://<address>[:<service>|/<service>]
So talking about ethereum, a valid application of that schema would at best be adding peers in this notation:
Add Ethereum peer: eth://<address>:303030
A big question for me in this area is still what will we address in the ehterbrowser (when speaking of full qualified addressing instead of lookup based)?
As far as I can see in the current state of the client, we open .html files from our hard drives and this will be replaced with html-content distributed by swarm if I understand correctly.
So we are talking about addressing html-content in a torrent-like environment?
Or will we address a smart contract itself who provides us with references to swarm-content for the html UI?
For the holde naming/registry stuff it would be important to know I guess.
https://my-ethereum-dapp.com/
work in both etherbrowsers and normal browsers. It would definitely help the adoption of Ethereum if we don't break DNS or the web.
For normal browsers, the client code would load as it does today and embedded in the application would be an API endpoint for interacting with the ethereum side. This could be achieved through hard-coding a developer-trusted endpoint or by using protocol handlers which are supported by every modern browser. The protocol handler route gives more control to the user but would be more difficult as you would have to abstract the interaction with ethereum in such a way that any application can use the same syntax.
(ie:
eth://address/storageKey
??)Sidenote: I'm not a fan of
eth:
being used as a protocol. I feel like it should just be a URI like ISBN's(ie:
eth:addresshash
)For etherbrowsers, an optimized path could be made available through HTTP headers or by inspecting the HTML metadata. Each approach would offer different capabilities but ultimately resolve to an ethereum address. An HTTP header could allow the etherbrowser to short circuit the request allowing for more performant retrieval of the dapp client and faster validation of the signatures used to secure the bootstrapping process. An HTML metadata approach would be ideal for situations where a person can't manipulate the HTTP headers as they have restricted access to the server. Most of the work for both of these approaches might already be done except for the bits necessary to prove authorship by the owner of the ethereum address.
DNS, or "protocol handlers" - is definitely an issue we need clarity on. I'm eager to explore what @vitalik @Stephan_Tual @gavofyork @tgerring have to say on the matter.
I ran across this little clip a few days ago. The whole piece of propaganda is worth perusing. It's all very relevant to what we are endeavoring towards. /\ big part ov me not-so-secretly craves http://RIPhttp.com
Anyway check this silliness out..
I'd like to challenge this point, as I see no good way to achieve this.
I see two ways to have to have etherbrowser and regular browser using the same URL:
1. You maintain two separate registry with
https://my-ethereum-dapp.com/
,.. on one hand some ethereum-registry and on the other hand good old public DNS. For obvious reasons this would be a mess and error prone.2. The EtherBrowser just use a regular DNS-lookup and connects to the a old fashion centrally hosted webserver,.. but then you would bring in the vulnerability to DNS-manipulation (which we know can and has happened).
Therefore im my opinion the EtherBrowser definitively needs a independent nameing/addressin-schema,.. unless I missed some other way to solve this.
In my opinion the hold Ethereum platform shouldn't depend on any legacy infrastructure above OSI Layer 4.
But as I started to lay out in another thread, I'm all for making Dapps accessible from legacy platforms (in a limited way). But I think it's important to make a explicit distinction between the trust-less environment and the old corruptible platforms, when communicating with the end user.
Will we address Swarm-Content directly or are we resolving to a smart contracts address which the gives us the references to Swarm-Content?
(sorry for asking, if this is already clarified somewhere,.. but I can't find any infos on that.)
But *.edu is already used by ICANN I think... how will we distinguish ? by prepending with eth:// protocol ?
If so, we also should have .eth for the good-old http:// protocol, the same way there is .bit Bitcoin DNS for the legacy Internet.
some.shop
you buy thesome
and put a sub-name registry in that has a nameshop
in there.Different name registries can play different roles based on what the buyer/DAO behaves like. For instance you could have a
mirror
one that mirrors the internet with swarm.(insofar legal) Orblog
could be a publishing DAO for blogs, and all sub-names are blogs on its system.If you have your own 'website' with
yourname.project
,yourname.blog
is more convenient, thanproject.yourname
,blog.yourname
; in the former you registeryourname
, and only bother with the top name registry, in the latter you need to bother with bothproject
andblog
of course the blog publishing DAO has its purposes, i.e. it might pay you for the blog. (though presumablyyourname.blog
could redirect)To sum it up, if we try to figure out postfixes.. we're doing work and imposing it. Whereas we could just say "yeah you all get a shot at this, good luck". Although maybe we could do some competition/bounties for the best idea to use for instance the name
blog
for. Hmm, good point, that takes some pressure off from the system being name hoarded.(but hardly all...) Name hoarding is an potential problem to try avoid.