git.iko.soy/urbit.org
on master help sign in
adds link to moon-spawning instructions
5485941Robert
concepts/galaxies-stars-and-planets.md+1−1
compare with master
unifiedsplit
@@ -29,6 +29,6 @@ Planets are intended for everyday use by an adult human, and there is a maximum
29
29
30In addition to these three classes of Azimuth points, there two other kinds of Urbit identities, but they do _not_ use Azimuth.
30In addition to these three classes of Azimuth points, there two other kinds of Urbit identities, but they do _not_ use Azimuth.
31
31
32−**Moons** are 64 bits, are issued by planets, and have names like `~doznec-salfun-naptul-habrys`. Moons are meant for connected devices: phones, smart TVs, digital thermostats. Moons are not independent, but are subordinated to their parent planet.
32+**Moons** are 64 bits, are issued by planets, and have names like `~doznec-salfun-naptul-habrys`. Moons are meant for connected devices: phones, smart TVs, digital thermostats. Moons are not independent, but are subordinated to their parent planet. To create new moon under your planet, follow [this guide](/docs/using/admin#moons).
33
33
34**Comets** are 128-bit points with no parents that can be launched by anyone. They are meant for bots. Being disposable and essentially unlimited, they will likely not be trusted by the others on the Arvo network. They have enormous names, like `~racmus-mollen-fallyt-linpex--watres-sibbur-modlux-rinmex`.
34**Comets** are 128-bit points with no parents that can be launched by anyone. They are meant for bots. Being disposable and essentially unlimited, they will likely not be trusted by the others on the Arvo network. They have enormous names, like `~racmus-mollen-fallyt-linpex--watres-sibbur-modlux-rinmex`.
using/admin.md+5−6
@@ -120,13 +120,12 @@ our HTTPS isn't audited / battle tested, we just call it "secure" HTTPS.
120You can find that on `8443`. Or `8444` (and so on) if you're already
120You can find that on `8443`. Or `8444` (and so on) if you're already
121running something on `8443`.
121running something on `8443`.
122
122
123−## Moons
123+## Moons {#moons}
124
124
125−Urbit namespace is distributed by having parent nodes sign the keys for child
125+Planets can spawn moons, which are meant for connected devices: phones, smart
126−nodes. If you have a planet, your parent star issued your ticket. As a planet
127−you, in turn, can sign the keys for moons. The basic idea is: your planet runs
126+TVs, digital thermostats. The basic idea is: your planet runs permanently in a
128−permanently in a data center somewhere and moons run on all your devices. Each
127+data center somewhere and moons run on all your devices. Each planet can issue
129−planet can issue ~4 billion (`2^32`) moons.
128+~4 billion (`2^32`) moons.
130
129
131To generate a random moon from your planet, run:
130To generate a random moon from your planet, run:
132
131
using/operating-a-star.md+2−2
@@ -13,7 +13,7 @@ Important star operations happen on both the Arvo side and the Azimuth side. On
13
13
14Stars are above planets in the network hierarchy in the sense that each star sponsors some number of planets: stars discover peers for planets, route packets for planets, provide DNS routing for planets, and push software updates to planets. A star that fulfills this is called the **sponsor** of planets that receive such services from the star; those planets, in turn, are called **dependents** of that star.
14Stars are above planets in the network hierarchy in the sense that each star sponsors some number of planets: stars discover peers for planets, route packets for planets, provide DNS routing for planets, and push software updates to planets. A star that fulfills this is called the **sponsor** of planets that receive such services from the star; those planets, in turn, are called **dependents** of that star.
15
15
16−Stars are also the "parents" planets. A new planet comes into existence only when spawned by a parent star. A parent planet is the sponsor of its children planets by default. This can change if a planet chooses to find a new sponsor (see the "Escaping a Sponsor" section below).
16+Stars are also the "parents" of planets. A new planet comes into existence only when spawned by a parent star. A parent planet is the sponsor of its children planets by default. This can change if a planet chooses to find a new sponsor (see the "Escaping a Sponsor" section below).
17
17
18Planets must have a sponsor star to use most features of the Arvo network. A planet cannot boot without a sponsor, and cannot make new connections to peers as long as it is not connected to a sponsor. Planets without a sponsor will still be able to message discovered peers until any such peers change their IP addresses.
18Planets must have a sponsor star to use most features of the Arvo network. A planet cannot boot without a sponsor, and cannot make new connections to peers as long as it is not connected to a sponsor. Planets without a sponsor will still be able to message discovered peers until any such peers change their IP addresses.
19
19
@@ -25,7 +25,7 @@ Like with real-life infrastructure, the operation of Arvo infrastructure comes w
25
25
26Below are some handy operations for the use and maintenance of your star.
26Below are some handy operations for the use and maintenance of your star.
27
27
28−### DNS Proxying
28+### arvo.network DNS Records
29
29
30We have a system that lets users request a domain name for their star under `arvo.network`, in the form of `shipname.arvo.network`, where `shipname` is their ship's name, so that it can be accessed remotely via our Landscape web interface. To find out how to do this, take a look at the [DNS Proxying](../dns-proxying) documentation.
30We have a system that lets users request a domain name for their star under `arvo.network`, in the form of `shipname.arvo.network`, where `shipname` is their ship's name, so that it can be accessed remotely via our Landscape web interface. To find out how to do this, take a look at the [DNS Proxying](../dns-proxying) documentation.
31
31