Highport orbital control

Sites that ask who you are

Some doors on this station are locked. The lock sits at the gate, not inside the room, which is why you are sent somewhere else to sign in and then sent back.

Some sites here ask you to sign in before they will show you a page. The owner listed which addresses need it, either one section or the whole site, and the check runs before the page is fetched instead of inside it. So you are not given half a page with a login box on top. You are sent to sign in, and then you are given the page.

The sign-in happens on the site's own domain. There is no Highport login screen in the middle of it: the form is served by the site you are reading, and the only other place you visit is the server that already holds your account. No site here ever sees your password. What the owner ends up with is the identifier your account already has, and a count of what you read.

A locked door on this station belongs to the site's owner, not to Orbital Control. We check that you have a name and hand you back; we do not keep a guest list, because there is no guest list to keep.

What you see

If you followed a link or typed an address, you get a 302 to /_bard/oauth/login on that same domain, with the page you asked for remembered. The heading reads Sign in to read followed by the site's own domain name.

If the thing being refused was an image, a stylesheet or a script inside a page you were already looking at, you get a bare 401 with no body at all. Nothing is drawn and nothing is explained. That is deliberate. Sending an image to a sign-in page produces a broken image whose contents are an HTML form, which explains nothing and takes a long time to work out. The page around it may simply look incomplete. Sign in from the page's own address and the missing parts arrive.

Which addresses ask is the owner's choice, and they choose by prefix. A prefix covers everything beneath it. /gallery covers /gallery itself and /gallery/2026/one.jpg, and does not cover /gallery-public, which is a different name that merely starts the same way. A prefix of / is the whole site.

If you would rather not sign in, nothing else on the site is affected. Only the addresses the owner listed ask. The rest is served to you the way it is served to anyone, and an anonymous request leaves a record of a request, not a record of a person.

A gate goes on and comes off when the owner publishes, and the change takes up to thirty seconds after that to be noticed, in either direction. A page that has just been made public can keep asking for that long, and a page that has just been gated can stay open for it.

The same sign-in page appears for a second, unrelated reason. An owner can set a budget for readers who have not signed in, and once that budget is zero or spent, anonymous readers are sent to sign in too. When a site is unavailable covers that one.

Signing in

Four steps, and only one of them is anywhere but the site's own domain. That one is the screen where you agree to it, and it belongs to the server that holds your account.

  1. The site's sign-in page. Served at the site's domain, no scripts, and one field, labelled Your handle or DID. There are no suggestions as you type, because a page served for a site is not allowed to talk to anything but that site, and making an exception would put some third party's server into the sign-in page of every site here.
  2. Finding your server. Highport looks your handle up, finds the server that holds your account, and sends you to it.
  3. The consent screen. That screen belongs to your server. It names the actual domain you are signing in to, and the one permission being asked for, which is your identity. Not your posts, not your files, not anything you have published. The mark it shows and the terms and privacy links are Highport's, because Highport is what runs the sign-in on the site's behalf.
  4. Back to the page. You land on the address you originally asked for, and a cookie is set for that domain.

Between the third step and the fourth, your server issues Highport the same sort of credentials it would issue any application. They are read for one thing, which account you are, and dropped on the spot. They are not stored, and they never go to the publisher.

The sign-in page says as much itself. Word for word, with the site's own name where example.com is here:

Sign in to read example.com

      This site asks readers to cover their own bandwidth. Signing in with your
      AT Protocol identity is what lets it charge your allowance rather than
      refuse you.

      Your handle or DID
      [ your.handle.domain ]   [ Continue ]

      Highport asks your server for your identity and nothing else — no access to
      your posts, your files, or anything you have published.
      

The first of those two paragraphs is the honest cost. A page the owner has gated is always billed to the reader who reads it, whatever the owner's own arrangement is. When a site is unavailable explains what an allowance is and what happens when one runs out.

The gate asks exactly one question, which is whether you are signed in. Any account passes it. There is no guest list, and the owner does not approve readers one at a time.

The sign-in page a gated site shows, served on the site's own domain

What the owner learns

About you Do they get it Detail
Your account's identifier Yes Once you have signed in there, and only for that domain
How many requests you made, and how many bytes they came to Yes Counted per domain
When you were last there Yes The most recent time you read something on that domain
Your address No It is deleted before anything is written down
Your browser No Also deleted, before anything is written down
Anything at all about you before you signed in No An anonymous request produces a record of a request, not a record of a person
What you read on their other domains No Every list is scoped to one domain, and there is no way to ask about one reader across several
Your password No It does not reach Highport either
Your posts, your files, anything you have published No The permission asked for is identity, and nothing beside it

Signing in sets one cookie, named __Host-bard-site, on that domain and nowhere else.

What it holds Your account's identifier and the domain it was issued for. No token, no key, no password
Where it goes Only to the domain that set it
Encryption It is encrypted before your browser ever receives it
How long it lasts Fourteen days by default; the operator of the deployment sets this
Scope One site. Signing in at one domain does not sign you in at another, and each one asks separately

Fourteen days outlasts a visit, which matters on a shared browser. The next person at that keyboard is signed in as you until somebody signs out or the cookie expires.

It is not the same thing as the session you get by signing in to the Hub at hub.highport.space. Different cookie, different domain, different lifetime, and neither one implies the other. Site owner authentication covers that side.

A cookie presented at a domain it was not issued for is ignored instead of refused. You are simply anonymous again.

Signing out

Visit /_bard/oauth/login on the site while you are signed in and the page reads You are signed in, with a Sign out button.

Signing out clears that site's cookie and the data that site stored in your browser. Nothing on any other site is touched, including any other site on Highport and including the Hub.

Some sites carry a sign-in control of their own on the page, a Sign in link that becomes a Sign out button once you are signed in. It is the same cookie and the same sign-out. The owner has chosen to put it where you can see it.

Nothing lists the sites you are currently signed in to, and there is no one place to sign out of all of them. The Hub has a section called Visited sites in the Observatory, under Your activity, but it is a record of reading, not a set of switches: each domain you read while signed in, how many requests you made there, and how many bytes of your own allowance went on it. On a site whose owner is paying, that last figure is zero. Signing in at a site records no approval there, so the Approved column reads — on every row and no Revoke button appears. Nothing on that page signs you out of anything. Each site is signed out at the site itself, at /_bard/oauth/login.

Every outcome

What happened What you get What it says
Gated page, not signed in, you navigated to it 302 to /_bard/oauth/login on the same domain Sign in to read the site's domain
Gated image or script inside a page 401 Nothing. Empty body
Gated page, signed in 200 The page
Your sign-in lapsed, or you cleared it The same as never having signed in The sign-in page again
You hold a sign-in for a different site The same as never having signed in The sign-in page again
Signed in and still refused 402 Out of allowance, naming whose allowance ran out and when it resets. That is bandwidth, not permission: see When a site is unavailable
The sign-in did not finish 400 That sign-in did not finish. "The sign-in did not complete, so the site does not know who you are. Nothing was recorded and nothing was charged." With a Try again link
Your handle would not resolve 200 The sign-in page again, with "That did not work. Check the handle and try again." above it
The site's access check is unreachable The page Served as though there were no gate
Reader sign-in is not set up on this deployment 404 at the sign-in address Nothing

When something goes wrong

"That did not work. Check the handle and try again." is the only thing you are told when a handle does not resolve, and it is the only thing anyone is told. The page will not say whether the handle exists, because an error that distinguished "no such account" from "that server is down" would answer questions about strangers for anybody who asked. Check the spelling. If the handle is right, the server that holds your account is probably not answering. Wait a while, then start again from the page you wanted.

If the site's access check is unreachable, the page is served. The check runs beside the site, and when it cannot be reached the request goes through unexamined instead of being refused. A reader is never locked out of a site because a part of Highport is briefly unreachable. The trade is that a gated page may occasionally be served to somebody who has not signed in.

If the sign-in address answers 404, reader sign-in has not been set up on the deployment serving that site. Nothing you do will get you in. Whoever runs that deployment has to finish setting it up.

Sites published from a space

A site can be published from a space, which is a private store on the owner's own server, readable only by the people they admit. That is a fact about where the owner keeps the records behind the site, not about who may read the finished pages: a site published from a space serves them at its domain exactly as any other site does. So being a member of somebody's space does not get you through a gate, and not being one does not keep you out. The gate asks whether you are signed in and nothing else. Spaces is the full account.

If you own a site and want to turn this on, Asking visitors to sign in is the page for that.

Visitors · 2 of 4