Skip to content

Identity and capabilities

reply2social has no users. It does not create them, store them or authenticate them. It asks the host —the site that hosts it— who the person on the other side is.

The invariant

This service never signs a token. It only validates.

If it had something to sign with, it would have something to manufacture an identity with — and an identity manufactured by the service that consumes it proves nothing. The only source of a valid identity here is the validator against the host.

How it happens

host (Antisionista)reply2socialnginxbrowserhost (Antisionista)reply2socialnginxbrowsersigned with a shared secretGET /reply2fb/api/emisiones (with its cookie)1proxy, credential passed through as-is2POST /api/reply2fb/validar3re-reads the user FROM THE DATABASE:active? which role today?4id + capabilities5is that enough for this route?6200 · 401 · 403 · 5037

The host re-reads the user from the database on every validation, instead of believing what the token says. That is what makes suspending someone take effect immediately: the same token that worked a second ago starts returning 401, without waiting for it to expire. And if their role is lowered, the response carries the new role.

The three capabilities

View

look at the panel

Operate

approve, pause, seed

Administer

accounts, permissions, flows

They are cumulative: whoever can administer can operate, and whoever can operate can view. In the code they are axum extractors — a route declares what it requires and the rest cannot forget to check it.

CapabilityExample routes
Operateapprove an emission, pause emission, disseminate to the archive
Administersign accounts up, grant permissions, create flows, export the cauce

The distinction that was hard to find: 401 versus 503

Both mean “you do not get through”. They mean opposite things.

yes: you are nobody

yes: it is you, without permission

yes: it is you, with permission

I could not ask

a request arrives

did the host answer?

401

«you are not authenticated»

403

«not enough»

200

503

«I cannot know who you are»

A 401 when the host is down is a lie. It asserts “you are nobody” when the truth is “I could not ask”. The difference matters on screen: with a 401 the panel sends you to log in again —and logging in again will fix nothing, because the problem is elsewhere— whereas with a 503 it says the identity service is not responding, which is what is actually happening.

This did not come for free: the middleware swallowed the validator’s error and everything ended up degraded to 401. The failure had to be carried all the way to the extractor for the 503 to survive.

Fail-closed, always

secret not configured?

it does not start

host not answering?

503

response not understood?

capability not enough?

403

On no path is doubt resolved by letting things through. A service that opens up when in doubt is a service that, the day its dependency fails, is left open — and that is exactly the day nobody is watching.

And the network credentials

A different thing, and worth not mixing up: the Instagram, Mastodon or Telegram tokens are not people’s identities but keys to the accounts.

  • They are stored encrypted with AES-256-GCM in cuentas.credenciales_cifradas.
  • They are never returned, not even masked. There is no endpoint that shows them.
  • You load them and that is it: if you got it wrong, you load them again.

There is no HTTP endpoint that returns ciphertext. The only path that takes credentials out of an installation is the CLI backup, and that is not an endpoint. That is why the invariant has no exceptions to remember.