so uh I'm Ryan and I understand this is
being live-streamed so if any of you
watching at home have any questions or
comments feel free to tweet at right pdx
and i will get to those as soon as i can
so we've decided to be the ethereal
namespace maybe someday we'll be the
etherium namespace that would be great
i'm a dev with nexus and in the process
of working on the maker stable coin and
crypto currency leverage platform we
decided that we needed to make a smart
contract package manager we made that we
called a dapple one of the design goals
of dapple was to provide a node package
manager like experience so people could
install and publish packages by their
names under username namespaces so to
accomplish that goal we came up with the
system of smart contracts that we call
the ethereal namespace essentially it's
a hierarchical permission abal name reg
so this is the name reg interface as it
stands and it allows you to map
addresses to names and names addresses
and it's great for a lot of purposes I
use it myself and usually I end up with
something like this where I'm just
mapping strings to addresses but if you
have data that looks kind of like this
that's somewhat hierarchical it's not
such a great fit now you can naively
store data like this in the name reg
contract you can do this and just have
path strings mapped addresses
but there there's a drawback to that
which is first of all there's a
conceptual gap between users mental
model of how things should be working
and how it's actually implement it and
usually with good design you want to
minimize the gap between what the user
hal user thinks the thing works and how
it actually works because the greater
the gap the greater the abstraction
tends to leak so that's one problem with
it another problem with this approach is
that it kind of becomes messy and
difficult to try to set permissions on
sub paths right because now you have
this this big name reg and you have to
parse each sub path and do all this
stuff to deal with permissions on sub
paths so something like this is a much
better fit for hierarchical data I don't
think I have to argue that one too hard
to this crowd so this is what we
basically tried to to make now my
initial approach to it was to just
chained together named reg contracts and
it technically works but again there are
a couple of drawbacks number one is
there's a nonlocality of information
here if I am just interacting this name
right contract here I'm getting
addresses but there's no information
within this name reg system to indicate
which addresses are pointers to name reg
contracts which addresses are basically
pointers to sub trees and which
addresses are dis addresses so that
information has to either live within
the application that is interacting with
the name reg or you have to do some
sneaky things to try and divine if this
address is pointing to a name wreck the
other problem of course is that there's
no standardized way of setting up
permissions on these these name break
contracts so you end up potentially with
a lot of one-offs maybe some things that
don't quite separate concerns well
enough so to resolve the first problem
all of our getters and setters on re NS
app interface return and accept a
boolean called is linked and that
explicitly defines whether the data
stored
at a particular path should be
considered a pointer to another node in
the tree and the second problem of not
having a standardized permission
interface we just solved by making a
standardized permission interface we
call a controller contract and you can
set those on any node in the tree so
this is roughly what our code looks like
right now this is just a UML diagram and
you can see there are two distinct
structures the one on the left is
governed by the NS app interface on top
and that is what you'll be interacting
with most of the time it lets you get
and set values in the NS tree using
paths and the second structure you only
use if you're setting permissions on a
node I'll dig into these in more detail
over the next few slides so this is the
interface for the ens app contract and
you see there's a getness set function
you also notice that on every function
we have a boolean okay return value we
found that was necessary because
sometimes functions return knolls if
there's a failure mode there are certain
failure modes that return null and you
need to be able to differentiate between
real valid null values and a failure
mode right so if the boolean ok returns
true or is true then everything went
through ok if it's false then any null
values gotten back are not valid and you
should figure out what's going on and
fail gracefully so get takes a forward
slash delimited path and returns a bytes
32 value it returns are is linked
boolean that we talked about earlier and
returns the evo k boolean set of course
takes a path the value in his link
returns the ok boolean and those are
what you'll be working with most of the
time of course claim no you only be
working with if you're writing a
controller contract controller contracts
call
this function DNS app sets the
controller contract making the call to
be the controller for the node that it
sets aside in the tree for that
controller and that it returns that
nodes ID the controller contract can
then build out the sub tree as however
it wants and it can set the position the
path for that sub tree in the ens tree
using the set function it passes in the
desired path it passes in the ID of the
node as a value and it sets these link
function or boolean to true and then we
have the node get node set functions
which are just ways of saving on look up
costs you can look up you can look up
values on nodes you can look at values
relative to nodes and set values
relative to nodes and then finally the
get controller function which simply
takes a node ID and returns the
controller contract and that was a bit
of a data dump so here's a kitten take a
take a breather all right we'll jump
back into it in three and two and all
right and this is the ens controller
interface and the only thing that
interacts with the NS controllers is the
NS app so when you're writing any nest
controller you need to make sure that's
permission that only the NSF can
interact with those two functions it
takes a node an address that's the
caller of making the request to set or
get the key and the value that should be
stored as well as the this link boolean
and it should return false if the caller
either doesn't have the right
permissions or if the requesters doesn't
make any sense for the given path so to
make your life easier we've implemented
a couple of controllers for you guys to
look at I'll go over these very quickly
because I'm running out of time I this
is the standard registry controller and
it's simply a first-come first-serve
zero fee controller if you look above
set and get the new registry function is
what you'll be using to set
to request some notes from the ens app
and get back an idea that you can then
set using the set path method that we
talked about earlier inset and get of
course set and get values and transfer
above the ens set and eunice kit allows
people to transfer ownership of nodes
between each other nens at indian escape
we of course talked about earlier so all
of this code is published at github com
/ nexus development / e and s i don't
know if you can see it on the bottom
there that's all right cool and we're
looking for feedback looking for pull
requests obviously with the system like
this the more people using it the more
valuable it is to everyone if we have a
common ens app implementation then it
helps with discoverability and we've
been trying to figure out how to make it
happen so we'd love some feedback get in
contact with us some of the things we've
been kicking around if maybe a token
system for registering tlds maybe an
auction system so if you want to be part
of that process please you know talk to
us tweet at me email us we have a github
we're fairly easel easy to stalk so you
know you can get in contact with somehow
if you have any questions or comments
again do we let me or if I'm eating one
of the brakes thank you very much
you