wabarc/wayback: an IM-first archiving daemon for Internet Archive, archive.today and IPFS

The gap wayback fills: one URL, several archives, one chat window

Public archiving services each have their own submission form, rate behaviour and retention policy. A person who wants a page preserved in more than one place normally opens several tabs and repeats the same paste. Wayback collapses that into a single submission path. The README describes it as "a web archiving and playback tool that allows users to capture and preserve web content" with "an IM-style interface for receiving and presenting archived web content", and the flag list confirms the fan-out: separate booleans for Internet Archive (--ia), archive.today (--is), Ghostarchive (--ga), IPFS (--ip) and Telegraph (--ph). The intended user is a web archivist, researcher, or anyone who wants a page retrievable later, and the interface assumption is that this person is already sitting in a terminal or a chat client rather than a browser. That assumption is the whole design. If you are not in a terminal or a chat client, wayback has little to offer you.

What actually happens between your message and a stored snapshot

The architecture visible in the material is a dispatcher with pluggable back ends. The binary runs either as a one-shot CLI invocation or as a daemon (--daemon, with the documented services being telegram, web, mastodon, twitter, discord, slack, irc and xmpp). In daemon mode the process holds a connection to the chat network, receives a message containing a URL, and submits that URL to whichever archiving services are enabled. Results are then returned to the same channel, and the README adds that results can also be published to a Telegram channel, Mastodon, or GitHub Issues, and that archived files can be stored to disk for offline use. IPFS is the one back end with a configurable transport: --ipfs-host defaults to 127.0.0.1, --ipfs-port to 5001, and --ipfs-mode to pinner, which means the default path talks to a locally running IPFS daemon rather than a remote gateway. The pinning-service route replaces that with an external pinner configured through the WAYBACK_SLOT, WAYBACK_APIKEY and WAYBACK_SECRET environment variables, with pinata given as the example slot. There is also a --tor flag to snapshot through the Tor anonymity network and a documented Tor hidden service, so the submission path itself can be separated from your IP. Note the asymmetry: the daemon is the stateful part, and the material mentions a --migrate flag to "Run SQL migrations", which tells you the daemon keeps a database, but the README does not describe its schema or location.

Installing and running it: the commands the README gives

Installation is conventional. From source, go install github.com/wabarc/wayback/cmd/wayback@latest. The project also ships a release installer (curl -fsSL https://get.wabarc.eu.org | sh), Bina, Snapcraft (sudo snap install wayback), an APT repository with a signed-by keyring, an RPM repository, and a Homebrew tap (brew tap wabarc/wayback then brew install wayback). Configuration resolves in this order: ./wayback.conf, then ~/wayback.conf, then /etc/wayback.conf, overridable with -c or --config. Running is a single positional argument list: wayback https://www.wikipedia.org, or several URLs at once, which the README frames as batch archiving for speed. To target one service instead of the defaults, pass the matching flag, for example wayback --ia https://www.fsf.org for Internet Archive or wayback --ip https://www.fsf.org for IPFS. For IPFS against a pinning service the README shows WAYBACK_SLOT=pinata WAYBACK_APIKEY=YOUR-PINATA-APIKEY WAYBACK_SECRET=YOUR-PINATA-SECRET wayback --ip https://www.fsf.org. A daemon invocation looks like wayback --ia --is -d telegram -t your-telegram-bot-token, with --chatid for a channel. Two operational flags are easy to miss and worth knowing before a first run: --info prints application information and --print shows the resolved configuration, which is the quickest way to confirm which back ends are actually enabled. Streaming media download requires FFmpeg to be present on the host.

The default-on problem, and why the flags deserve a second read

The help output is explicit that --ia, --is, --ga, --ip and --ph each default to true. A bare wayback https://example.com therefore attempts five destinations at once, including an IPFS submission that expects a daemon at 127.0.0.1:5001 unless you reconfigure it. For a user who wanted only an Internet Archive copy, that is four unintended network operations, one of which will likely fail noisily on a machine with no IPFS node. The README's own examples quietly work around this by passing single flags, but the default behaviour stands. This is the clearest design trade-off in the project: convenience for the common case (archive everywhere) at the cost of surprise for the narrow case. There is no documented "dry run" flag to inspect what would be submitted, so if you care about which third parties see a URL, you must read the flags and pass them explicitly on every invocation, or pin the behaviour in wayback.conf. Treat the defaults as something to override, not something to inherit.

Where wayback is the wrong tool

Wayback does not archive anything itself. It submits URLs to Internet Archive, archive.today, Ghostarchive, IPFS and Telegraph, and the resulting snapshot lives on that service under that service's terms. If archive.today removes a capture, or a pinning service stops pinning, wayback cannot restore it. The disk-storage feature gives you a local copy of files it has fetched, which is the closest thing to independent custody here, but the README does not describe a verification step, a manifest, or a checksum, so a local copy is not by itself evidence that the remote copy still exists or matches. A second limitation is interface scope: the tool assumes chat or shell. There is a web entry point in the daemon list, but the material presents it as a privacy and accessibility entry rather than a browser-based capture UI, so a team wanting a click-to-archive button for non-technical staff will not find that here. Third, the chat integrations are daemons: they need a long-running process, credentials per platform, and the SQL state that --migrate sets up. Anyone who wants a fire-and-forget script should stay on the CLI path and skip the daemon entirely.

Compared with running the archiving CLIs and APIs directly

The obvious alternative is to call each service yourself: the Internet Archive's Save Page Now endpoint, archive.today's submit URL, and the IPFS pinning API, wired together in a shell script or a small internal service. That approach gives you exact control over which services are contacted, what headers and user agents are sent, how failures are retried, and where the results are recorded. Wayback's value is that this fan-out, the chat front ends, the Tor option and the pinning-service configuration already exist and are maintained in one Go binary with documented flags and a config file. The difference in approach is custody and control. A hand-rolled script is more work and more code you own, but it can log every submission and store the returned snapshot identifiers in your own database, which is what you need if the archive is meant to be auditable. Wayback's own SQL migrations suggest it keeps some state, but the README does not document what is stored or whether it is exportable. If auditability matters more than convenience, the script wins; if you mainly want a URL preserved in several places from a chat window, wayback wins.

Maintenance, releases and the GPL-3.0 question

The release history in the material shows v0.20.0 and v0.20.1 in July 2024, then a gap to v0.21.1 in July 2026, with the repository's last push in September 2026. That is a long quiet stretch followed by a resumption, and it is worth checking the changelog between v0.20.1 and v0.21.1 before upgrading a running daemon, particularly if you rely on a chat integration, since those are the parts most exposed to third-party API changes. The project is licensed GPL-3.0. If you run the binary as a service for yourself, that is the ordinary case. If you modify it and distribute it, or offer a modified version as a network service, the copyleft terms apply to what you distribute, and the precise scope of that obligation for network services is a question for your own counsel rather than something to settle from a README. One practical consequence: the chat bot tokens, pinning API keys and any SQL database the daemon creates are operational secrets and state you now own. Before upgrading, run wayback --print to capture the resolved configuration, because a config file that silently drifts from what the daemon is actually using is the failure mode that wastes the most time.

Editorial conclusion

Adopt wayback if your archiving workflow already lives in chat or a shell and you want one command to fan a URL out to several public archives. Do not adopt it if you need a self-contained, verifiable archive of record, because every copy it produces is held by a third party and can disappear or be altered by that party. Before deploying, verify two things: which services are on by default in your build, since the flags list shows --ia, --is, --ga, --ip and --ph each defaulting to true, and what the SQL migrations under --migrate create, because the daemon services persist state and you need to know where.

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. wabarc/wayback on GitHub