@@ -1,56 +0,0 @@
1−:- :~ title/'Using a Star'
2− ==
3−;>
4−
5−# Using a Star
6−
7−A _ship_ is an instance of the Arvo operating system that is used as a personal server on the Arvo network. Stars are a type of ship that act as infrastructure for the Arvo network. In the Arvo ship-hierarchy, stars are below galaxies and above planets.
8−
9−Parallel to the Arvo network is Azimuth, the Urbit identity system that uses the Ethereum blockchain. All ships must have a corresponding _point_ -- an Azimuth identity -- to boot a ship and to use the Arvo network.
10−
11−Important star operations happen on both the Arvo side and the Azimuth side. On the Arvo side, these operations come in the form of Dojo commands. On the Azimuth side, operations are executed by interfacing with the star's point through the [Bridge](https://github.com/urbit/bridge/releases) client.
12−
13−## Power of a Star
14−
15−Stars are above planets in the network hierarchy in the sense that stars sponsor planets: A stars discover peers for planets, route packets for planets, provide DNS for planets, and push software updates to planets. A star that fulfills this is the *sponsor* of planets that receive such services; those planets, in turn, are *dependents* of that star.
16−
17−Stars are also the "parents" of all planets. A new planet comes into existence 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.
18−
19−Planets 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. Sponsorless planets will still be able to message discovered peers until such any such peers change their IP addresses.
20−
21−## Responsibility of a Stars
22−
23−Like with real-life infrastructure, the operation of Arvo infrastructure comes with unique responsibilities. For reasons stated above, stars should be always be online on a reliable cloud service, such as AWS or Google Cloud Platform. These platforms have layers of redundancies that make them much more resilient than local machines, so stars hosted on the cloud are unlikely to leave their dependents in the dark.
24−
25−## Star Operations
26−
27−Below are some handy operations for the use and maintenance of your star.
28−
29−### Setting Your IP Address
30−
31−You star is not aware of your own IP address by default.
32−
33−0. wait for the initial post-boot sync to succeed
34−1. :dns|ip
35−2. Prompt you for an IP address and you copy in an IP address
36−
37−### DNS Proxying
38−
39−### Escaping The
40−
41−
42−
43−### Maintaining Connectivity
44−
45−Occasionally, your star might lose network connectivity due to a known timer issue. When this happens, run the `|bonk` command in the Dojo to regain connectivity.
46−
47−### Finding Your Own IP Address
48−
49−After you boot
50−
51−We need a page in the document for Star Owners (we can add Galaxy Owners later) that basically outlines to them know their responsibilities as a star operator on the Arvo network. The most important points.
52−
53−- Explanation about the relationship between Azimuth point and Arvo ship
54−- Planets issues from them will route through them by default, this means they should be run on cloud somewhere
55−- DNS proxying instructions
56−- Any special instructions (like intermittent |bonk)ing