Highport orbital control

Site owner authentication

There is no crew list to join. You sign in with an account you already have, approve a short list of things Highport may do, and everything else in your account stays shut.

There is no Highport account. No password to choose, no email to confirm, no registration step, nothing to cancel. You sign in to the Hub at hub.highport.space with an account you already have: the one you use for Bluesky, or one held on any other server that speaks AT Protocol, the network underneath both.

Here is the part that matters. You approve the grant on your own account's server, not here. Highport hands that server a name, a logo and a description of what it is asking for. The server shows you the screen and issues the credentials. We never see your password, and we never learn whether the screen was shown at all. We are only told, afterwards, what you agreed to.

Orbital Control has no arrivals desk, no forms, and nothing to add you to. There is no account here, so there is nothing to close if you never come back. We regard this as the ideal arrangement and take no credit for it.

What you type

One box and one button. The box wants your handle: the domain-shaped name your account goes by, like alice.example.com. It also accepts the identifier underneath that handle, the one beginning did:, and the address of the server that holds your account, which is useful when a handle is not resolving.

The label says what is about to happen, and it is worth reading once:

Enter your handle. We'll send you to your own server to approve access.
      

The button reads Sign in, and Contacting your server… while it works. An empty box answers Enter your handle to continue. and goes nowhere.

Suggestions, and where they come from

After two characters, matching accounts appear under the box. Arrow keys move through them, Enter picks the highlighted one instead of submitting what you typed, and Escape closes the list.

Those suggestions are the one thing in the Hub that comes from somebody other than Highport. They are fetched from typeahead.waow.tech, a community account-search service. Here is exactly what it sees and does not see:

So a server that is not ours learns that somebody is signing in here. That cost is why a deployment can turn it off. The suggestions are a convenience, not a step in signing in. Block them, lose your connection to them, or use a Highport that has turned them off, and the box still takes a handle typed out in full.

Approving it at your own server

Clicking Sign in sends your browser to your own account's server as a full page navigation, so you can see in the address bar whose screen you are looking at. Check it. Everything from that point until you come back happens there, including any password or passkey.

That screen is assembled by your server from what Highport publishes about itself: the name highport.space, its logo, links to its terms and privacy policy, and the two strings describing the grant. Those two are the ones to read, and they are these, exactly as shipped:

Manage highport.space sites, tiles, spaces, and bandwidth

      Create, update, and delete your site and tile records — in your own repo and in your own highport.space spaces — record your acceptance of the highport.space policies, let highport.space read the spaces you belong to so it can keep their sites published, manage your registered domains, create and manage your own highport.space spaces, and read and set how your sites' bandwidth is metered and who pays for it.
      

You have ten minutes to approve. Past that the sign-in expires and you start again. If you have granted this before, your server may skip the screen entirely and send you straight back. That is its decision, not ours, and Highport has no way to force the screen to appear.

Approving sends you back to hub.highport.space, signed in. You land on your dashboard, or on the page you were trying to reach when you were asked to sign in. If you have never published anything, the dashboard is empty and says so.

What the grant covers

In plain terms:

Those twenty-nine are named one by one instead of as a general permission to call Highport, so the consent screen can say what is being granted rather than saying "everything":

The permission set names all twenty-nine, and reads out the rest of the grant in full.

If your account's server does not support spaces yet, it grants everything else and signs you in normally. The Spaces area then explains itself instead of listing anything, and nothing else about your account is affected. Spaces has the detail.

What it does not reach

Where your tokens live

They never reach your browser. Highport's servers hold the access token, the refresh token, and the key those tokens are bound to. Your browser holds one cookie, bard_session, and inside it is an encrypted identifier that means nothing anywhere else. There is no token in it and no key, a script on the page cannot read it, and no host but hub.highport.space is ever sent it.

A session lasts ninety days from the moment you sign in. Nothing needs to be renewed by hand. The tokens behind it are refreshed for you, and you never see them.

The permission set has the rest of it: where each piece is kept and for how long, the five things the page in your browser is allowed to learn about your session, and what something holding a live session can and cannot do while it is open.

Signing out

Sign out is in the header, and reads Signing out… while it works. Three things happen. The session is deleted on our side, which takes the tokens with it. Your server is then asked to retire the credential that would let us come back. And the response clears the cookie whatever happened to that middle step.

Asking your server is best-effort, and nothing waits on it. A person who clicked sign out is signed out whether or not their server answers. A sign-out that failed because a remote server was down would be a sign-out that left a live session behind.

Two things it does not do. It signs out this browser only. There is no session list anywhere, so there is no sign out everywhere. And it does not withdraw the grant at your own server, so signing in again may or may not show you the approval screen. That is your server's decision.

If you do nothing at all, the session ends ninety days after you signed in.

When sign-in does not work

Everything that can go wrong before you leave Highport produces the same message:

InvalidRequest: InvalidRequest: that identity could not be used to start a sign-in; check the handle and try again
      

The vagueness is deliberate. No such handle and that server is not answering are two different answers, and the difference between them tells anybody who cares to ask whether a given account exists on a given server. So there is one message, and the specifics stay in our logs where an operator can read them.

It covers all of these:

• The handle does not resolve to an account.
• The handle is published in two places, a DNS record and a file served at the domain, and the two name different accounts.
• The account resolves, but names no server we can use.
• The server's sign-in metadata is missing something Highport requires.
• The server cannot grant the kind of permission Highport asks for. Not every server can yet.
• The server refused both of our attempts to begin.

Three things to check, in order:

1. The spelling, including the part after the last dot.
2. Whether the handle is new. A handle whose DNS has not propagated yet cannot be signed in with, and there is nothing to do but wait.
3. If you typed a server address instead of a handle, whether it ends in a /. It must not, and that one failure looks identical to every other.

The rest of what you might see:

One last thing that catches people out. A site published on Highport can ask its own visitors to sign in, and it is a different system with a much smaller grant. It never asks for anything but your identity, and it happens on the publisher's domain instead of here. Sites that ask who you are is that page.

Site owners · 1 of 12