5465b65756
WordPress makes two assumptions this project cannot accept: that identity comes from an email address, and that a site lives at one server. Both are things somebody else can take away — a mailbox is rented from a provider who can close it or be compelled to open it, and a server is one seizure from being gone. Sirius Press replaces the first and hedges the second. Signing in means signing a challenge with the key that controls a CashAddress. The address is recovered from the signature, so nothing is typed but the signature itself, and the result is an ordinary WordPress session cookie — roles, capabilities, nonces and the REST API never learn the login was different. Three ways to produce one: a wallet the browser already exposes, a phrase used once in the page and wiped, or a signature pasted in from any BIP-137 wallet, which needs no JavaScript and lets the key stay on a machine that never touches the web. There is no password reset, and the recovery page says so plainly rather than offering a form that cannot work. A reset mechanism is by construction a way to take an account from its owner, and it is always easier to attack than the cryptography it bypasses. Publishing a post also exports it as static HTML to the name's storage on Sia, signed by the key that owns the name, so the site keeps answering when the server does not. Email as a feature is untouched. wp_mail() still works, SMTP still sends, and contact forms still deliver to addresses real people typed. Only mail to the site's own unroutable placeholder addresses is diverted to an in-app inbox. The objection was to email as identity, not to email. Core is pinned and patched rather than vendored. WordPress 7.1.1 is 149 MB and 5,008 files; the fork's entire core diff is 75 lines in wp-admin/install.php. Carrying the former to express the latter would bury the patch where nobody reviews it and make every clone of the monorepo pay for it. Upstream releases still merge through tools/update-wordpress.sh, which reapplies the series and says exactly which hunk needs a human. The cryptography is implemented twice — PHP on the server, JavaScript in the page — because the server must verify and the browser must sign. Both are pinned against libauth, the library the Sirius portal wallet and the BNS gateway already use, so a disagreement of one byte fails the test suite rather than presenting as a rejected login at three in the morning. 132 checks, no framework, about a second.
104 lines
3.6 KiB
Markdown
104 lines
3.6 KiB
Markdown
# 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.
|