The Ethereum Domain Naming System

vaXvaX Austin, TXMember Posts: 78 ✭✭✭
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:

image

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 ourcellves
collectively 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

  • rabbitrabbit Member Posts: 15 ✭✭
    edited September 2014
    First, you're awesome. Second, I wish DNS was not the point of reference for these discussions. It was conceived under entirely different constraints and predates adventures in hypertext. A fully modern solution should look very different.

    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.
  • MichaelSmithMichaelSmith Member Posts: 79 ✭✭
    Honestly, I find all these special characters (☰ϟΔ etc) as well as the poetry and the grand alludings that have been commonplace in the forum lately a bit annoying.
  • MichaelSmithMichaelSmith Member Posts: 79 ✭✭
    Probably better to focus on building the platform first and then letting people use it for whatever creative purposes they aspire to - poetry and technical documentation are not necessarily a good match.
  • rabbitrabbit Member Posts: 15 ✭✭
    I think a little playfulness never hurt but I can understand what you mean. Still, this meta conversation is the first off topic bit. What are your thoughts on the subject at hand? How do we better define the problem?
  • vaXvaX Austin, TXMember Posts: 78 ✭✭✭
    rabbit said:

    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.

    Say that we don't use a DNS, would we simply direct people to perform search queries within the EtherBrowser to locate specific DApps?
  • m0sem0se Member Posts: 10
    edited September 2014
    I could imagine a solution, where you can subscribe to a bunch of different registries for a bunch of different things and when you start typing in your etherbrowser the auto-complete kicks in with results from those registries. (Of course this registries could be DAOs or any kind of smart contract based structure, but would need to implement a common interface for querying.)

    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:
    ://[:|/]
    So talking about ethereum, a valid application of that schema would at best be adding peers in this notation:
    Add Ethereum peer: eth://: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.
  • rabbitrabbit Member Posts: 15 ✭✭
    edited September 2014
    vaX said:

    Say that we don't use a DNS, would we simply direct people to perform search queries within the EtherBrowser to locate specific DApps?

    That's one way to do it. Maybe a little too subjective tho. I'm suggesting that DNS as-is may be sufficient depending on the problem we're trying to solve. If it's the ability to link to an app then it seems to me the best possible world would be to have
    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.
  • vaXvaX Austin, TXMember Posts: 78 ✭✭✭
    @rabbit Loving your ideas.

    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..
  • rabbitrabbit Member Posts: 15 ✭✭
    I'll check it out. Also, the ideas I'm throwing out here are just to stir the pot. It's impossible to know what the right solution is until we understand the problem. I would be very interested in how we might be able to identify the problem.
  • m0sem0se Member Posts: 10
    edited September 2014
    rabbit said:


    That's one way to do it. Maybe a little too subjective tho. I'm suggesting that DNS as-is may be sufficient depending on the problem we're trying to solve. If it's the ability to link to an app then it seems to me the best possible world would be to have
    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.


    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.
  • m0sem0se Member Posts: 10
    rabbit said:

    I'll check it out. Also, the ideas I'm throwing out here are just to stir the pot. It's impossible to know what the right solution is until we understand the problem. I would be very interested in how we might be able to identify the problem.

    Good point. One problem I can identify is, that we not even know, WHAT (technically) we are going to address in the EtherBrowser yet.

    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.)
  • TechnologovTechnologov Member Posts: 102 ✭✭
    edited September 2014
    Hmm. Very interesting proposal ! +1 :)
    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.
  • rabbitrabbit Member Posts: 15 ✭✭
    Thanks @m0se these are very good points.
    m0se said:

    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.

    Hmm... it depends on how you define the registry role. You could have a registry in Ethereum that merely extends the DNS record so there is no fragmentation. It's a single document with an addendum provided to Ethereum-capable clients. This would have the added effect of retroactively building confidence in the DNS record. If we have an entry we can add to DNS that relays the lookup metadata for Ethereum then we can have a bidirectional binding between the two. The performance would probably not be that bad given that the Ethereum data is effectively local or at least mirrored nearby; it may end up taking longer to do the DNS lookup.
    m0se said:


    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).

    Keep in mind the EtherBrowser is just browser fork. It will interact with DNS as-is and the full web will still be available unless steps are taken to remove it (why?). So having an option like (1) above looks even better given that the EtherBrowser can take advantage of a feature normal browsers can't to build confidence in the DNS records integrity and protect users from poisoned DNS.
    m0se said:


    In my opinion the hold Ethereum platform shouldn't depend on any legacy infrastructure above OSI Layer 4.

    Most people around here likely feel the same. I feel the same long term but I'm interested in building migration paths. If option 1 is viable (your thoughts?) then I could see it being a hybrid approach until a critical mass is achieved then migrate to an Ethereum-exclusive route at that point.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Imo, bugger the postfixes, have people free to make sub-name registries. So if you want to be some.shop you buy the some and put a sub-name registry in that has a name shop 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) Or blog 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, than project.yourname, blog.yourname; in the former you register yourname, and only bother with the top name registry, in the latter you need to bother with both project and blog of course the blog publishing DAO has its purposes, i.e. it might pay you for the blog. (though presumably yourname.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.
    Keep in mind the EtherBrowser is just browser fork. It will interact with DNS as-is and the full web will still be available unless steps are taken to remove it (why?).
    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.
Sign In or Register to comment.