# Pointing your name at your site

A BCNR name carries a small set of records on-chain. Two of them say "the site
for this name is served from here":

| Record | Holds | Use it when |
|---|---|---|
| `ip` | An IPv4 or IPv6 address | You have a server with a fixed address — the normal case for a VPS |
| `p`  | A hostname | Something else already resolves to your server: a DNS name, a tunnel endpoint, a load balancer |

Either one makes a BCNR resolver — Theseus, Ariadne, or the public gateway —
send visitors to your Sirius Press instance.

---

## Setting the record

From the Sirius portal at [sirius.x](https://sirius.x): open your name, go to
the DNS tab, add the record, and sign. The change costs nothing and takes
effect as soon as the manifest is published, because records live in a
wallet-signed manifest rather than in a chain transaction.

You can also set them from the registrar CLI if you run one.

---

## Which one to use

**`ip`, if you can.** It is one fewer system between a reader and your site,
and it does not depend on anyone's DNS continuing to answer — which is most of
the point of having a BCNR name in the first place.

**`p`, if your address moves**, or if you are behind a tunnel, or if you want
a CDN in front. The tradeoff is real: a `p` record points at a name in somebody
else's namespace, and whoever controls that namespace can redirect your
visitors. If you are using BCNR to get out from under ICANN, pointing your name
back into it is worth doing deliberately rather than by default.

---

## Telling WordPress its own address

WordPress builds absolute URLs from a value it stores, and it has to match what
visitors actually type or you get redirect loops.

In Docker, set `SITE_URL` in `docker/.env` and restart:

```
SITE_URL=https://example.bch
```

Elsewhere, set it in `wp-config.php`:

```php
define( 'WP_HOME',    'https://example.bch' );
define( 'WP_SITEURL', 'https://example.bch' );
```

Do this once your name resolves, not before — WordPress will happily guess from
the request until then, which is what you want during setup.

---

## The static mirror is separate

Setting `ip` or `p` points readers at your **live WordPress**. It has nothing
to do with the static export.

The export goes to your name's storage on Sia, at `bns/<name>/`, and resolvers
reach it through the name's `s3` record. That means a name can have both:

- an `ip` record, so visitors get the live site with its comments and search
- a populated bucket, so that when the server is down, or slow, or gone, the
  last published copy still answers

Which one a given resolver prefers is its business, and different resolvers
choose differently. The useful way to think about it: the live site is where
your site is, and the static mirror is what survives if it stops being there.

If you want *only* the static copy served — no PHP exposed to the public at all
— leave `ip` and `p` unset and let the `s3` record do the work. Your WordPress
then runs somewhere private, as an authoring tool, and publishes outward. For
a site that is mostly reading rather than interaction, this is the strongest
arrangement available, and it is what `silentmode.st` itself does.

---

## Checking it

```bash
curl -s https://navigate.st/api/dns/example.bch | python3 -m json.tool
```

shows the verified records a resolver sees, and

```bash
curl -s https://navigate.st/api/site/example.bch | python3 -m json.tool
```

lists what is actually in the name's bucket — which is the quickest way to
confirm an export arrived.

The **Sirius Press → Publishing** screen shows the same thing from inside
wp-admin, along with whatever the queue is still working through.