474 lines
27 KiB
Markdown
474 lines
27 KiB
Markdown
---
|
||
title: Name System
|
||
...
|
||
We intend to establish a system of globally unique wallet names, to resolve
|
||
the security hole that is the domain name systm, though not all wallets will
|
||
have globally unique names, and many wallets will have many names.
|
||
|
||
Associated with each globally unique name is set of name servers. When one’s
|
||
wallet starts up, then if your wallet has globally unique name, it logs in
|
||
to its name server, which will henceforth direct people to that wallet. If
|
||
the wallet has a network accessible tcp and/or UDP address it directs people
|
||
to that address (one port only, protocol negotiation will occur once the
|
||
connection is established, rather than protocols being defined by the port
|
||
number). If not, will direct them to a UDT4 rendezvous server, probably itself.
|
||
|
||
We probably need to support [uTP for the background download of bulk data].
|
||
This also supports rendezvous routing, though perhaps in a different and
|
||
incompatible way, excessively married to the bittorrent protocol.We might
|
||
find it easier to construct our own throttling mechanism in QUIC,
|
||
accumulating the round trip time and square of the round trip time excluding
|
||
outliers, to form a short term and long term average and variance of the
|
||
round trip time, and throttling lower priority bulk downloads and big
|
||
downloads when the short term average rises above the long term average by
|
||
more than the long term variance. The long term data is zeroed when the IP
|
||
address of the default gateway(router) is acquired, and is timed out over a
|
||
few days. It is also ceilinged at a couple of seconds.
|
||
|
||
[uTP for the background download of bulk data]: https://github.com/bittorrent/libutp
|
||
|
||
In this day and age, a program that lives only on one machine really is not
|
||
much of a program, and the typical user interaction is a user driving a gui
|
||
on one machine which is a gui to program that lives on a machine a thousand
|
||
miles away.
|
||
|
||
We have a problem with the name system, the system for obtaining network
|
||
addresses, in that the name system is subject to centralized state control,
|
||
and the TCP-SSL system is screwed by the state, which is currently seizing
|
||
crimethink domain names, and will eventually seize untraceable crypto
|
||
currency domain names.
|
||
|
||
In today’s environment, it is impossible to speak the truth under one’s true
|
||
name, and dangerous to speak the truth even under any durable and widely used
|
||
identity. Therefore, people who post under names tend to be unreliable.
|
||
Hence the term “namefag”. If someone posts under his true name, he is a
|
||
“namefag” – probably unreliable and lying. Even someone who posts under a
|
||
durable pseudonym is apt show excessive restraint on many topics.
|
||
|
||
The aids virus does not itself kill you. The aids virus “wants” to stick
|
||
around to give itself lots of opportunities to infect other people, so wants
|
||
to disable the immune system for obvious reasons. Then, without a immune
|
||
system, something else is likely to kill you.
|
||
|
||
When I say “wants”, of course the aids virus is not conscious, does not
|
||
literally want anything at all. Rather, natural selection means that a virus
|
||
that disables the immune system will have opportunities to spread, while a
|
||
virus that fails to disable the immune system only has a short window of
|
||
opportunity to spread before the immune system kills it, unless it is so
|
||
virulent that it likely kills its host before it has the opportunity to
|
||
spread.
|
||
|
||
Similarly, a successful memetic disease that spreads through state power,
|
||
through the state system for propagation of official truth “wants” to disable
|
||
truth speaking and truth telling – hence the replication crisis, peer
|
||
review, and the death of science. We are now in the peculiar situation that
|
||
truth is best obtained from anonymous sources, which is seriously suboptimal.
|
||
Namefags always lie. The drug companies are abandoning drug development,
|
||
because science just does not work any more. No one believes their research,
|
||
and they do not believe anyone else’s research.
|
||
|
||
It used to be that there were a small number of sensitive topics, and if you
|
||
stayed away from those, you could speak the truth on everything else, but now
|
||
it is near enough to all of them that it might as well be all of them, hence
|
||
the replication crisis. Similarly, the aids virus tends to wind up totally
|
||
suppressing the immune system, even though more selective shutdown would
|
||
serve its interests more effectively, and indeed the aids virus starts by
|
||
shutting down the immune system in a more selective fashion, but in the end
|
||
cannot help itself from shutting down the immune system totally.
|
||
|
||
The memetic disease, the demon, does not “want” to shut down truth telling
|
||
wholesale. It “wants” to shut down truth telling selectively, but inevitably,
|
||
there is collateral damage, so it winds up shutting down truth telling
|
||
wholesale.
|
||
|
||
To exorcise the demon, we need a prophet, and since the demon occupies the
|
||
role of the official state church, we need a true king. Since there is a
|
||
persistent shortage of true Kings, I here speaking as engineer rather than a
|
||
prophet, so here I am discussing the anarcho agorist solution to anarcho
|
||
tyranny, the technological solution, not the true king solution.
|
||
|
||
Because of the namefag problem and the state snatching domain names, we need,
|
||
in order to operate an untraceable blockchain based currency not only a
|
||
decentralized system capable of generating consensus on who owns what cash,
|
||
we need a system capable of generating consensus on who who owns which human
|
||
readable globally unique names, and the mapping between human readable names,
|
||
Zooko triangle names (which correspond to encryption public keys), and
|
||
network addresses, a name system resistant to the state’s attempts to link
|
||
names to jobs, careers, and warm bodies that can be beaten up or imprisoned,
|
||
to link names to property, to property that can be confiscated or destroyed.
|
||
|
||
A transaction output can hold an amount of currency, or a minimum amount of
|
||
currency and a name. Part of the current state, which every block contains,
|
||
is unused transaction outputs sorted by name.
|
||
|
||
If we make unused transaction outputs sorted by name available, might as well
|
||
make them available sorted by key.
|
||
|
||
In the hello world system, we will have a local database mapping names to
|
||
keys and to network addresses. In the minimum viable product, a global
|
||
consensus database. We will, however, urgently need a rendezvous system that
|
||
allows people to set up wallets and peers without opening ports on stable
|
||
network address to the internet. Arguably, the minimum viable product will
|
||
have a global database mapping between keys and names, but also a nameserver
|
||
system, wherein a host without a stable network address can login to a host
|
||
with a stable network address, enabling rendezvous. When one identity has its
|
||
name servers registered in the global consensus database, it always tries to
|
||
login to those and keep the connection alive with a ping that starts out
|
||
frequent, and then slows down on the Fibonacci sequence, to one ping every
|
||
1024 secondsplus a random number modulo 1024 seconds. At each ping, tells the
|
||
server when the next ping coming, and if the server does not get the
|
||
expected ping, server sends a nack. If the server gets no ack, logs the
|
||
client out. If the client gets no ack, retries, if still no ack, tries to
|
||
login to the next server.
|
||
|
||
In the minimum viable product, we will require everyone operating a peer
|
||
wallet to have a static IP address and port forwarding for most functionality
|
||
to work, which will be unacceptable or impossible for the vast majority of
|
||
users, though necessarily we will need them to be able to receive money
|
||
without port forwarding, a static IP, or a globally identified human readable
|
||
name, by hosting their client wallet on a particular peer. Otherwise no one
|
||
could get crypto currency they would need to set up a peer.
|
||
|
||
Because static IP is a pain, we should also support nameserver on the state
|
||
run domain name system, as well as nameserver on our peer network, but that
|
||
can wait a while. And in the end, when we grow so big that every peer is
|
||
itself a huge server farm, when we have millions of users and a thousand or
|
||
so peers, the natural state of affairs is for each peer to have a static IP.
|
||
|
||
Eventually we want people to be able to do without static IPs and
|
||
portforwarding, which is going to require a UDP layer. One the other hand, we
|
||
only intend to have a thousand or so full peers, even if we take over and
|
||
replace the US dollar as the world monetary system. Our client wallets are
|
||
going to be the primary beneficiaries of rendevous UDT4.8 routing over UDP.
|
||
|
||
We also need names that you can send money to, and name under which you can
|
||
receives. The current cryptocash system involves sending money to
|
||
cryptographic identifiers, which is a pain. We would like to be able to send
|
||
and receive money without relying on identifiers that look like line noise.
|
||
|
||
So we need a system similar to namecoin, but namecoin relies on proof of
|
||
work, rather than proof of share, and the state’s computers can easily mount
|
||
a fifty one percent attack on proof of work. We need a namecoin like system
|
||
but based on proof of share, rather than proof of work, so that for the state
|
||
to take it over, it would need to pay off fifty one percent of the
|
||
shareholders – and thus pay off the people who are hiding behind the name
|
||
system to perform untraceable crypto currency transactions and to speak the
|
||
unspeakable.
|
||
|
||
For anyone to get started, we are going to have to enable them to operate a
|
||
client wallet without IP and port forwarding, by logging on to a peer wallet.
|
||
The minimum viable product will not be viable without a client wallet that
|
||
you can use like any networked program. A client wallet logged onto a peer
|
||
wallet automatically gets the name `username.peername`. The peer could give
|
||
the name to someone else though error, malice or equipment failure, but the
|
||
money will remain in the client’s wallet, and will be spendable when he
|
||
creates another username with another peer. Money is connected to wallet
|
||
master secret, which should never be revealed to anyone, not with the
|
||
username. So you can receive money with a name associated an evil nazi
|
||
identity as one username on one peer, and spend it with a username associated
|
||
with a social justice warrior on another peer. No one can tell that both
|
||
names are controlled by the same master secret. You send money to a username,
|
||
but it is held by the wallet, in effect by the master secret, not by the
|
||
user name. That people have usernames, that money goes from one username to
|
||
another, makes transferring money easy, but by default the money goes through
|
||
the username to the master secret behind the quite discardable username,
|
||
thus becomes anonymous, not merely pseudonymous after being received. Once
|
||
you have received the money, you can lose the username, throw it away, or
|
||
suffer it being confiscated by the peer, and you, not the username, still
|
||
have the money. You only lose the money if someone else gets the master
|
||
secret.
|
||
|
||
You can leave the money in the username, in which case the peer hosting your
|
||
username can steal it, but for a hacker to steal it he needs to get your
|
||
master secret and logon password, or you transfer it to the master secret on
|
||
your computer, in which case a hacker can steal it, but the peer cannot, and
|
||
also you can spend it from a completely different username. Since most people
|
||
using this system are likely to be keen on privacy, and have no good reason
|
||
to trust the peer, the default will be for the money to go from the username
|
||
to the master secret.
|
||
|
||
Transfers of money go from one username to another username, and this is
|
||
visible to the person who sent it and the person who received it, but if the
|
||
transfer is to the wallet and the master secret behind the username, rather
|
||
than to the username, this is not visible to the hosts. Money is associated
|
||
with a host and this association is visible, but it does not need to be the
|
||
same host as your username. By default, money is associated with the host
|
||
hosting the username that receives it, which is apt to give a hint to which
|
||
username received it, but you can change this default. If you are receiving
|
||
crypto currency under one username, and spending it under another username on
|
||
another host, it is apt to be a good idea to change this default to the host
|
||
that is hosting the username that you use for spending, because then spends
|
||
will clear more quickly. Or if both the usernames and both the hosts might
|
||
get investigated by hostile people, change the default to a host that is
|
||
hosting your respectable username that you do not use much.
|
||
|
||
We also need a state religion that makes pretty lies low status, but that is
|
||
another post.
|
||
|
||
#True Names and TCP
|
||
|
||
Vernor Vinge [made the point](http://www.amazon.com/True-Names-Opening-Cyberspace-Frontier/dp/0312862075) that true names are an instrument of
|
||
government oppression. If the government can associate your true name
|
||
with your actions, it can punish you for those actions. If it can find the true
|
||
names associated with a transaction, it is a lot easier to tax that transaction.
|
||
|
||
Recently there have been moves to make your cell phone into a wallet. A
|
||
big problem with this is that cell phone cryptography is broken. Another
|
||
problem is that cell phones are not necessarily associated with true names,
|
||
and as soon as the government hears that they might control money, it
|
||
starts insisting that cell phones *are* associated with true names. The phone
|
||
companies don’t like this, for if money is transferred from true name to
|
||
true name, rather than cell phone to cell phone, it will make them a servant
|
||
of the banking cartel, and the bankers will suck up all the gravy, but once
|
||
people start stealing money through flaws in the encryption, they will be
|
||
depressingly grateful that the government can track account holders down
|
||
and punish them – except, of course, the government probably will not be
|
||
much good at doing so.
|
||
|
||
TCP is all about creating connections. It creates connections between
|
||
network addresses, but network addresses correspond to the way networks
|
||
are organized, not the way people are organized, so on top of networks we
|
||
have domain names.
|
||
|
||
TCP therefore establishes a connection *to* a domain name rather than a
|
||
mere network address – but there is no concept of the connection coming
|
||
*from* anywhere humanly meaningful.
|
||
|
||
Urns are “uniform resource names”, and uris are “uniform resource identifiers” and urls are “uniform resource locators”, and that is what the
|
||
web is built out of.
|
||
|
||
There are several big problems with urls:
|
||
|
||
1. They are uniform: Everyone is supposed to agree on one domain
|
||
name for one entity, but of course they don’t. There is honest and
|
||
reasonable disagreement as to which jim is the “real” jim, because
|
||
in truth there is no one real jim, and there is fraud, as in lots of
|
||
people pretending to be Paypal or the Bank of America, in order to
|
||
steal your money.
|
||
|
||
2. They are resources: Each refers to only a single interaction, but of
|
||
course relationships are built out of many interactions. There is no
|
||
concept of a connection continuing throughout many pages, no
|
||
concept of logon. In building urls on top of TCP, we lost the
|
||
concept of a connection. And because urls are built out of TCP
|
||
there is no concept of the content depending on both ends of the
|
||
connection – that a page at the Bank might be different for Bob than
|
||
it is for Carol – that it does in reality depend on who is connected is
|
||
a kluge that breaks the architecture.
|
||
|
||
Because security (ssl, https) is constructed below the level of a
|
||
connection, because it lacks a concept of connection extending
|
||
beyond a single page or a single url, a multitude of insecurities
|
||
result. We want https and ssl to secure a connection, but https and
|
||
ssl do not know there are such things as logons and connections.
|
||
|
||
That domain names and hence urls presuppose agreement, agreement
|
||
which can never exist, we get cybersquatting and phishing and
|
||
suchlike.
|
||
|
||
That connections and logons exist, but are not explicitly addressed by the
|
||
protocol leads to such attacks as cross site scripting and session fixation.
|
||
|
||
A proposed fix for this problem is yurls, which apply Zooko’s triangle to
|
||
the web: One adds to the domain name a hash of a rule for validating the
|
||
public key, making it into Zooko’s globally unique identifier. The
|
||
nickname (non unique global identifier) is the web page title, and the
|
||
petname (locally unique identifier) is the title under which it appears in
|
||
your bookmark list, or the link text under which it appears in a web page.
|
||
|
||
This, however, breaks normal form. The public key is an attribute of the
|
||
domain, while the nickname and petnames are attributes of particular web
|
||
pages – a breach of normal form related to the loss of the concept of
|
||
connection – a breach of normal form reflecting the fact that that urls
|
||
provide no concept of a logon, a connection, or a user.
|
||
|
||
OK, so much for “uniform”. Instead of uniform identifiers, we should
|
||
have zooko identifiers, and zooko identifiers organized in normal form.
|
||
But what about “resource”, for “resource” also breaks normal form.
|
||
|
||
Instead of “resources”, we should have “capabilities”. A resource
|
||
corresponds to a special case of a capability, a resource is a capability
|
||
that that resembles a read only file handle. But what exactly are "capabilities”?
|
||
|
||
People with different concepts about what is best for computer security
|
||
tend to disagree passionately and at considerable length about what the
|
||
word “capability” means, and will undoubtedly tell me I am a complete
|
||
moron for using it in the manner that I intend to use it, but barging ahead anyway:
|
||
|
||
A “capability” is an object that represents one end of a communication
|
||
channel, or information that enables an entity to obtain such a channel, or
|
||
the user interface representation of such a channel, or such a potential
|
||
channel. The channel enables the possessor of the capability to do stuff to
|
||
something, or get something. Capabilities are usually obtained by being
|
||
passed along the communication channel. Capabilities are usually
|
||
obtained from capabilities, or inherited by a running instance of a program
|
||
when the program is created, or read from storage after originally being
|
||
obtained by means of another capability.
|
||
|
||
This definition leaves out the issue of security – to provide security,
|
||
capabilities need to be unforgeable or difficult to guess. Capabilities are
|
||
usually defined with the security characteristics central to them, but I am
|
||
defining capabilities so that what is central is connections and managing
|
||
lots of potential connection. Sometimes security and limiting access is a
|
||
very important part of management, and sometimes it is not.
|
||
|
||
A file handle could be an example of a capability – it is a communication
|
||
channel between a process and the file management system. Suppose we
|
||
are focussing on security and access management to files: A file handle
|
||
could be used to control and manage permissions if a program that has the
|
||
privilege to access certain files could pass an unforgeable file handle to
|
||
one of those files to a program that lacks such access, and this is the only
|
||
way the less privileged program could get at those files.
|
||
|
||
Often the server wants to make sure that the client at one end of a
|
||
connection is the user it thinks it is, which fits exactly into the usual
|
||
definitions of capabilities. But more often, the server does not care who
|
||
the client is, but the client wants to make sure that the server at the other
|
||
end of the connection is the server he thinks it is, which, since it is the
|
||
client that initiates the connection, does not fit well into many existing
|
||
definitions of security by capabilities.
|
||
|
||
# Mapping between globally unique human readable names and public keys
|
||
|
||
The blockchain provides a Merkle-patricia dac of human readable names. Each
|
||
human readable name links to a list of signatures transferring ownership form
|
||
one public key to the next, terminating in an initial assignment of the name
|
||
by a previous block chain consensus. A client typically keeps a few leaves
|
||
of this tree. A host keeps the entire tree, and provides portions of the tree
|
||
to each client.
|
||
|
||
When two clients link up by human readable name, they make sure that they are
|
||
working off the same early consensus, the same initial grant of user name by
|
||
an old blockchain consensus, and also off the same more recent consensus,
|
||
for possible changes in the public key that has rightful ownership of that
|
||
name. If they see different Merkle hashes at the root of their trees, the
|
||
connection fails. Thus the blockchain they are working from has to be the
|
||
same originally, and also the same more recently.
|
||
|
||
This system ensures we know and agree what the public key associated with a
|
||
name is, but how do we find the network address?
|
||
|
||
# Mapping between public keys and nework addresses
|
||
|
||
## The Nameserver System
|
||
|
||
Typically someone is logged in to a host with an identity that looks like an
|
||
email address, `paf.foo.bar`, where`bar` is the name of a host that is
|
||
reliably up, and reliably on the network, and relatively easy to find
|
||
|
||
You can ask the host `bar` for the public key and *the network address* of
|
||
`foo.bar`, or conversely the login name and network address associated with
|
||
this public key. Of course these values are completely subject to the caprice
|
||
of the owner of `bar`. And, having obtained the network address of `foo.bar`,
|
||
you can then get the network address of `paf.foo.bar`
|
||
|
||
Suppose someone owns the name `paf`, and you can find the global consensus as
|
||
to what public key controls `paf`, but he does not have a stable network
|
||
address. He can instead provide a nameserver – another entity that will
|
||
provide a rendevous. If `paf` is generally logged in to `foo`, you can
|
||
contact `foo`, to get rendevous data for `bar.foo`, which is, supposing `foo`
|
||
to be well behaved, rendevous data for `bar`
|
||
|
||
Starting from a local list of commonly used name server names, keys, and
|
||
network addresses, you eventually get a live connection to the owner of that
|
||
public key, who tells you that at the time he received your message, the
|
||
information is up to date, and, for any globally unique human readable names
|
||
involved in setting up the connection, he is using the same blockchain as you
|
||
are using.
|
||
|
||
Your local list of network addresses may well rapidly become out of date.
|
||
Information about network addresses flood fills through the system in the
|
||
form of signed assertions about network addresses by owners of public keys,
|
||
with timeouts on those assertions, and where to find more up to date
|
||
information if the assertion has timed out, but we do not attempt to create a
|
||
global consensus on network addresses. Rather, the authoritative source of
|
||
information about a network address of a public key comes from successfully
|
||
performing a live connection to the owner of that public key. You can, and
|
||
probably should, choose some host as the decider on the current tree of
|
||
network addresses, but we don’t need to agree on the host. People can work
|
||
off slightly different mappings about network addresses with no global and
|
||
complete consensus. Mappings are always incomplete, out of date, and usually
|
||
incomplete and out of date in a multitude of slightly different ways.
|
||
|
||
We need a global consensus, a single hash of the entire blockchain, on what
|
||
public keys own what crypto currency and what human readable names. We do not
|
||
need a global consensus on the mapping between public keys and network
|
||
addresses.
|
||
|
||
What you would like to get is an assertion that `paf.foo.bar` has public key
|
||
such and such, and whatever you need to make network connection to
|
||
`paf.foo.bar`, but likely `paf.foo.bar` has transient public key, because his
|
||
identity is merely a username and login at `foo.bar`, and transient network
|
||
address, because he is behind nat translation. So you ask `bar` about
|
||
`foo.bar`, and `foo.bar` about `paf.foo.bar`, and when you actually contact
|
||
`paf.foo.bar`, then, and only then, you know you have reliable information.
|
||
But you don’t know how long it is likely to remain reliable, though
|
||
`paf.foo.bar` will tell you (and no other source of information is
|
||
authoritative, or as likely to be accurate).
|
||
|
||
Information about the mapping between public keys and network addresses that
|
||
is likely to be durable flood fills through the network of nameservers.
|
||
|
||
# logon identity
|
||
|
||
Often, indeed typically, `ann.foo` contacts `bob.bar`, and `bob.bar` needs
|
||
continuity information, needs to know that this is truly the same `ann.foo`
|
||
as contacted him last time – which is what we currently do with usernames and
|
||
passwords.
|
||
|
||
The name `foo` is rooted in a chain of signatures of public keys and requires
|
||
a global consensus on that chain. But the name `ann.foo` is rooted in logon
|
||
on `foo`. So `bob.bar` needs to know that `ann.foo` can log on with `foo`,
|
||
which `ann.foo` does by providing `bob.bar` with a public key signed by `foo`,
|
||
which might be a transient public key generated the last time she logged
|
||
on, which will disappear the moment her session on her computer shuts down,
|
||
or might be a durable public key. But if it is a durable public key, this
|
||
does not give her any added security, since `foo` can always make up a new
|
||
public key for anyone he decides to call `ann.foo` and sign it, so he might
|
||
as well put a timeout on the key, and `ann.foo` might as well discard it when
|
||
her computer turns off or goes into sleep mode. So, it is in everyone’s
|
||
interests (except that of attackers) that only root keys are durable.
|
||
|
||
`foo`’s key is durable, and information about it is published.`ann.foo`’s
|
||
key is transient, and information about it always obtained directly from
|
||
`ann.foo` as a result of `ann.foo` logging in with someone, or as a result of
|
||
someone contacting `foo` with the intent of logging in to `ann.foo`.
|
||
|
||
But suppose, as is likely, the network address of `foo` is not actually all
|
||
that durable, is perhaps behind a NAT. In that case, it may well be that to
|
||
contact `foo`, you need to contact `bar`.
|
||
|
||
So, `foo!bar` is `foo` logged in on `bar`, but not by a username and
|
||
password, but rather logged on by his durable public key, attested by the
|
||
blockchain consensus. So, you get an assertion, flood filled through the
|
||
nameservers, that the network address of the public key that the blockchain
|
||
asserts is the rightful controller of `foo`, is likely to be found at `foo!`
|
||
(public key of `bar`), or likely to be found at `foo!bar`.
|
||
|
||
Logons by durable public key will work exactly like logons by username and
|
||
password, or logons by derived name. It is just that the name of the entity
|
||
logged on has a different form..
|
||
|
||
Just as openssh has logons by durable public key, logons by public key
|
||
continuity, and logons by username and password, but once you are logged on,
|
||
it is all the same, you will be able to logon to `bob.bar` as `ann.bob.bar`,
|
||
meaning a username and password at `bob.bar`, as `ann.foo`, meaning `ann` has
|
||
a single signon at `foo`, a username and password at `foo`, or as `ann`,
|
||
meaning `ann` logs on to `bob.bar` with a public key attested by the
|
||
blockchain consensus as belonging to `ann`.
|
||
|
||
And if `ann` is currently logged on to `bob.bar` with a public key attested
|
||
by the blockchain consensus as belonging to `ann`, you can find the current
|
||
network address of `ann` by asking `bob.bar` for the network address of
|
||
`ann!bob.bar`
|
||
|
||
`ann.bob.bar` is whosoever `bob.bar` decides to call `ann.bob.bar`, but
|
||
`ann!bob.bar` is an entity that controls the secret key of `ann`, who is at
|
||
this moment logged onto `bob.bar`.
|
||
|
||
If `ann` asserts her current network address is likely to last a long time,
|
||
and is accessible without going through
|
||
|
||
`bob.bar` then that network address information will flood fill through the
|
||
network. Less useful network address information, however will not get far.
|