Manifest
Credentials absent. It comes out over HTTP and through the panel; it can be committed. It does not restore: tokens have to be reloaded.
Social media archiving and republishing · in production
reply2social
It pulls material from a social media account, keeps the bytes and publishes it again to other accounts — with recorded permission and, by default, after a person has looked at it.
It sounds like a bridge. The difference is in the middle: CDN URLs expire in hours or days, so a system that stored only the link would hold, a year later, a catalogue of dead links. Here the bytes are downloaded; that they also happen to be useful for republishing is a consequence, not the goal.
★ The distinctive part
Cauce: the whole installation, in one file
Cauce —Spanish for watercourse— is a TOML file describing where material may flow: which accounts exist and what goes from which to which. It publishes nothing —that is still the worker's job, with its tap and its guards— but it covers the four things that matter when something breaks: backup and disaster recovery, bulk sign-up, versioning the configuration in git, and replicating to another installation.
formato_version = 1
credenciales = "ausentes" # no tokens: safe to commit
[[cuentas]]
handle = "fuente-ig"
plataforma = "instagram"
rol = "lectura"
poll_horas = 6
[[cuentas]]
handle = "difusion-masto"
plataforma = "mastodon"
rol = "escritura"
max_por_hora = 4 # the tap
[[flujos]]
clave = "fuente-a-difusion" # immutable
origen = "fuente-ig"
destino = "difusion-masto"
condicion = { tipo = ["VIDEO"] }$ cauce importar instalacion.toml
+ cuenta fuente-ig se crearía
= cuenta difusion-masto sin cambios
~ flujo fuente-a-difu… cambia: condicion
⚠ activa = true se crea PAUSADO
nada se escribió.
--aplicar para hacerlo.
Like terraform plan and apply, and the
cut is not cosmetic: looking does not ask for identity, applying
does — «mutating the database = signing». It is idempotent:
running it twice says «no changes» across the board. The keys and
the output are in Spanish, which is what the parser and the CLI
speak.
Backup
Credentials encrypted, and it only comes out through the CLI. No endpoint of this service returns or accepts ciphertext — with no exceptions to remember.
The guards, and why they exist
Each one was born of a concrete failure mode, not of a general best practice. That is why they are written down with their reason beside them.
The header cannot lie
If the file declares itself «ausentes» and carries a credential, or says «cifradas» and does not carry the block naming the key, validation rejects it. Not a warning: whether somebody archives a manifest believing they have a backup depends on it.
A single conflict stops everything
Applying «whatever can be applied» would leave the installation halfway between two descriptions, and nobody would know which one it is in.
Importing is additive, and three things it declares are not applied
Consent is granted again by hand —a permission is a personal, dated assertion, not bulk paperwork—, flows are created paused, and automatic publishing stays off. All three warn; none stays quiet.
A filter nobody understands is an ERROR
Writing «tags» instead of «tag» used to give a valid file whose flow published everything: the engine ignored what it did not understand. The most dangerous filter is the one that looks like it is there and is not.
Restoring with a different key refuses before touching anything
The backup carries the fingerprint of the key it was encrypted with. Writing anyway would leave accounts that look like they have a credential, and the failure would only show up at publish time.
What is restored stays «degraded», never «ok»
The credential is loaded and nobody exercised it against the network. Calling it healthy would be the false green exactly where it costs most: whoever restores walks away reassured.
The full format, with its diagrams and seven example files: cauce · cauce by example.
★ No false green
What runs, what does not, and what is still plan
The system is in production and publishes for real. At the same time, there are parts verified only against fake servers running inside the tests, and parts that are still plan. Distinguishing them is part of the product: a system that says «ok» without having checked fails exactly when somebody walked away reassured.
● Running in production
- 12 accounts and 5 flows in a real installation
- Comes in from Instagram, Telegram and RSS feeds
- Goes out to Mastodon, Telegram and a site of its own
- Published for real: video with attribution to the source account
- Stores the bytes, not the link: the archive outlives the CDN
- Splits long video into parts without re-encoding
◐ Verified only against fake servers
- Facebook and LinkedIn: the code is there, the real network has not contradicted it yet
- The worker's failure modes —429, timeout, partial failure— are provoked inside the tests, which is where they can be provoked at will
○ In genesis
- The installable packaging: an Ansible role as the primary artefact
- Interface wrappers beyond Svelte (React, Vue, Angular): the framework-free TypeScript core is written and tested, the ports are not
- The archive purger: every state that grows needs its drain
Both publications can be looked at: a 23-second video on Mastodon (3 August 2026) and another one on a public Telegram channel (4 August). Both went out with their attribution to the original material, travelling the whole path: polling → archiving the bytes → emission → publication.
★ At a glance
In numbers
12
accounts in production
5
active flows
3 + 3
networks in and out
1
TOML file describes it all
AES-256
GCM for every credential
AGPL-3.0
licence of the core
★ Inside
How it is built
One Rust binary starts three things: the API (axum), the poller and the emission worker. In the middle, the archive: bytes and metadata on disk and in Postgres. The interface lives apart, split into a TypeScript core with no framework at all and thin wrappers on top — Svelte, today.
poller Every N hours it asks each source what is new, and downloads whatever it finds.
archive Stores the bytes and the metadata. It is the centre: everything else reads from it or writes to it.
emission Takes what was approved and publishes it, respecting each destination's tap.
panel Where a person looks, approves, grants permissions and pulls the brake.
cauce Exports and imports the whole installation as a declarative file.
The service validates identity; it never issues it
It has no users: it asks the site hosting it who is on the other side, and the host re-reads the person from its own database on every validation. Suspending somebody takes effect immediately, without waiting for anything to expire. If the service could sign a credential, it could manufacture an identity — and an identity manufactured by whoever consumes it proves nothing.
★ Free and public
The code
Everything on this page —the Rust service, the panel, the CLI and the documentation— lives in a public repository, under AGPL-3.0: it can be used, studied, modified and deployed, on the condition that whoever offers it as a service publishes their modifications.
v0.1.0-rc.1
2026-08-15 · first tagged version
git clone https://gitlab.com/pineiden/reply2fb.git reply2socialIt is a release candidate, and the suffix is not modesty: Instagram —the source this project grew out of— has never run against Meta's API. That path is verified against a fake server running inside the tests, and a fake server cannot contradict what a real one would say. The changelog lists the seven limits of that class, one by one.
The repository is called reply2fb and the module
reply2social: it was born mirroring Instagram to a
Facebook Page and grew into a multi-network system. It was not renamed
so as not to break the clones that already exist.
★ Learn more
Documentation
Eleven pages with their diagrams —rendered at build time, so a broken diagram breaks the build instead of showing up blank.
What this is →
The whole map in one diagram, and what the design prevents on purpose.
★ Download the code →
The repo, the tagged versions, what is in each directory and what the AGPL requires.
A post's journey →
From the source account to the destination, step by step.
★ Cauce: the declarative file →
Manifest and backup, plan and apply, and why each guard exists.
★ Cauce by example →
Seven files, from the smallest to a complete installation, each with its graph.
The data (ERD) →
The tables, their partial unique indexes and their CHECKs.
The modules →
How the Rust binary is split and why the boundaries are there.
The interface →
A framework-free TypeScript core, with thin wrappers on top.
Permission and regime →
Who authorised what, over whose material, and until when.
Identity and capabilities →
The service validates identity; it never issues it. Why that is an invariant.
Integrate it in your site →
Step by step, verifiable, to host it from another application.