A guide for the organisation being asked to sign

One thing, narrowly: that the specific sentence on the signing page — the dates, the counterparty, the stated basis — is accurate. Nothing more. It is a fact-check, not an endorsement, a partnership agreement, or a statement that you approve of anything the other organisation does beyond the fact being described.

The signature is produced by an Ed25519 key generated in the browser tab you are reading this from, over the exact bytes shown on the signing page — the same bytes, not a summary of them. There is no wording you agree to that differs from the wording you can read before you click.

No contract, no ongoing obligation, no exclusivity, no agreement to anything that is not the one dated sentence on the page. It does not enrol your organisation in anything, create an account, or grant FlashyOS — or the organisation that invited you — any standing authority over your name, your brand, or future claims made about you. A future claim needs a future signature; today’s signature covers today’s sentence and nothing written after it.

Yes, and the mechanism is not a policy promise — it is how the flow is built. Clicking “No — do not sign this” generates nothing, sends nothing, and contacts nobody. No key is created, no request reaches any server, and the organisation that sent the link is told nothing except, if you choose to reply to them directly, whatever you decide to say. The claim they published stays exactly as it was — one organisation’s account of the relationship, labelled “asserted” rather than “countersigned” wherever it is shown, which is the honest state of most claims on this network.

If the claim is inaccurate rather than merely unwelcome, declining does not fix that on its own — the useful next step is telling the asserting organisation directly, so they can correct or withdraw it at the source they publish it from.

A signature is never deleted or edited retroactively — the record is append-only, the same discipline this estate applies to every other kind of correction it publishes. But it is not permanent in the sense that matters to you: either party can revoke it.

A revocation is a new, separate record citing the original claim by its fingerprint, naming who at your organisation decided the relationship is over and why, in real substance — not a checkbox. It requires a named person, never an automated process, on either side; a claim your organisation signed cannot be silently un-signed by anyone. Once filed, the relationship is shown as ended everywhere the original claim was shown, and the historical fact that it was true from one date to another stays on the record — the same way a company’s own public filings do not pretend a past contract never existed once it lapses.

The mechanism is revokeCountersignature in the Directory service — either the asserting organisation or the counterparty may call it, and it refuses anything shorter than a real, substantive reason.

No. The private half of the key generated to sign is created in your browser tab, used there, and never transmitted anywhere — not to FlashyOS, not to the organisation that invited you. It is offered to you as a download at the end of the flow and nowhere else; if you close the tab without saving it, it is gone, and nobody — including us — can recover it or sign with it. Only the public half, and the signature it produced, are meant to leave your browser, and both are things anyone could already see once you publish them.