Skip to content

Permission and regime

This system republishes other people’s work. Everything on this page exists because of that.

Two different questions

They are easy to confuse and they are independent:

only if both

if either is missing

Is there a flow

from A to B?

a ROUTE

configuration

Did A authorise their

material to appear on B?

a CONSENT

a person's assertion

does it emit?

it goes out

it does not

A drawn edge is not a permission. The panel draws flows without consent as broken, not connected. If they looked the same, this panel would be a false promise with better typography: somebody would look at a graph full of arrows and believe everything was authorised.

It is not a flag. It is a record with who, when, for which destinations and, optionally, with what evidence.

CONSENTIMIENTOS

uuid

cuenta_id

FK

whose material it is

text

otorgado_por

a person, by name

timestamptz

otorgado_en

timestamptz

revocado_en

null = valid

uuid_array

cuentas_destino

towards WHICH ACCOUNTS

text

alcance

the per-network label, derived

text

evidencia

the message, the email, whatever it was

cuentas_destino names accounts, not networks. Two earlier versions failed for the same reason: they stored 'mastodon'. With two Mastodon accounts, that permission enabled both, and there was no way to consent to one and not the other — a permission wider than what the person asserted. The per-network alcance still exists, but derived from the accounts, not the other way round.

An old, per-network permission is not translated into a selection of accounts. When the permissions panel opens, a consent that does not name accounts does not appear checked: showing it as if it named accounts would display something more precise than what the person said, and saving on top of that would turn their broad permission into a narrow one without anyone deciding so.

Granting and revoking

emissionservicepanelpersonemissionservicepanelpersonstores WHO asserts it and WHENfrom here on, those destinations emitwhat was ALREADY published is NOT withdrawnpicks destination accounts + evidence1POST /api/cuentas/{id}/consentimientos2recorded3revoke4POST /api/consentimientos/{id}/revocar5stops emitting immediately6sends a notice7

Revoking does not unpublish. What already went out stays online, and taking it down is a person’s work. The revocation dialog says so before it is pressed — staying quiet would let someone believe that revoking undoes what was done.

There is a case that does not fit the subscribe-with-permission model: somebody sends a loose link to an Instagram post over Telegram, to have it replicated. There is no subscription, there is no recorded consent.

The decision taken was to allow it with attribution and marking, not silently.

subscription with permission

loose link

no

yes

material comes in

where did it come from?

regimen: consentido

regimen: atribucion_sin_permiso

does it carry the link

to the original?

the DATABASE rejects the INSERT

enters the archive, marked

enters the archive

on publishing:

goes out with attribution

+ a notice is emitted

on publishing: goes out

Attribution is a CHECK, not a convention. The constraint items_atribucion_obligatoria says: if the regime is atribucion_sin_permiso, permalink cannot be null. Such an item, without a link to the original, cannot be written to the database. Not through a bug, not through a script, not by hand.

Where it shows up

Three places, and each one answers a different question:

WhereWhat it answers
A notice on publishing“Something just went out under this regime”
The history filter“What did we publish this way?” — the question of the day a complaint arrives
The per-row marker“This one here, how did it get in?”

Why the filter is a question and not just another column. A value per row is seen when somebody is already looking at that row. The day a complaint arrives, “what did we publish without recorded consent?” has to have an answer on a screen, not in an SQL query written in a hurry.

What the attribution regime does NOT enable

It only applies to the loose link, which is a deliberate act by a person pasting a URL. Subscribing to an account —including public accounts read through a browser— does require recorded consent. It is not a shortcut for skipping permission: it is the recognition that sharing an already identified link is a different thing from subscribing to somebody’s material.