# Changelog ## v4.0.2 — 2026-09-16 **Two comments named a retired internal service by its path, and now describe it instead.** The v4.0.0 entry below and the matching comment above `install` in the `Makefile` said which consumer had been retired on 2026-06-02. Both now say "another consumer in this repository". The measurement they report is the same, and no source file, header or build rule changed, so every artifact this library builds is byte-identical to v4.0.1. The v4.0.0 entry is edited in place, which a changelog entry normally never is. This file is published with the library, so a name in an old entry is published exactly as a name in a new one would be. ## v4.0.1 — 2026-08-25 **The shared library recorded a dependency on a copy eleven weeks older than the sources beside it, and said nothing.** `build/libantpeer.so` linked `-lantheos -lmembus -lsockbus -lblebus` with no `-L`, so it resolved `/usr/local/lib`, where `libantheos` was dated 2026-06-05. The artifact was wrong and the build was green. Found by deleting the installed copy, not by reading the Makefile: the link then failed with `cannot find -lantheos`. `make test` was green before and after, because the test path links the sibling ARCHIVES (v3.2.1, `ANTPEER-TESTS-LINK-THE-INSTALLED-ANTHEOS`) and never builds this target. The `.so` now takes `-L` on the sibling build directories under the same `FAMILY_SRC` selector the tests use, and the sibling `.so` files are prerequisites. `-L` does not reach `DT_NEEDED`, so the recorded sonames are unchanged and no RPATH/RUNPATH enters the artifact — both verified on the built library, not assumed. A standalone checkout is unaffected: with no siblings present it resolves installed copies exactly as before. ## v4.0.0 — 2026-08-25 **BREAKING — the public headers install into `$(PREFIX)/include/antpeer/`.** `#include ` becomes `#include `, and `#include ` becomes `#include `. Matches `antheos/` and `membus/`, which already installed into subdirectories — so the family contained both patterns and this member was on the wrong side of its own convention (`ANTPEER-HEADERS-INSTALL-FLAT`). A flat install puts a header into a namespace this library does not own. That is not a hypothetical here: `pki-reg/Ed25519Utils.hpp`, in this same repository, declares `pkireg::KeyPair` under the identical filename that ours uses for `antpeer::crypto::KeyPair`. The two have never collided because pki-reg includes its own with quotes, and the quoted form searches the including file's directory first — which is a property of how the CONSUMER writes its include, not of anything this library does. A collision would present as a wrong header silently included, which is among the worst failures to read. **No compatibility shim at the flat path, and the decision is measured.** The flat headers have zero consumers: `chrysalis/CMakeLists.txt` states it links no antpeer, another consumer in this repository was retired 2026-06-02 with its binary and units removed, this project builds against `include/` directly, and a scan of 769 executables under `/usr/local/bin`, `/opt` and `/srv` on the build host found nothing linking `libantpeer` at all. A shim for no consumer is a second path to keep in step forever. `make uninstall` removes the directory (via `rmdir`, so a file someone else put there stops it rather than being deleted) AND the flat copies a pre-4.0.0 install left behind — otherwise upgrading leaves the stale flat header on disk, which is exactly the state `ANTHEOS-STALE-INSTALLED-LIBRARY-AT-USR-LOCAL` describes for a sibling. ## v3.3.0 — 2026-08-25 **This library opened a named bus and could not destroy one.** `membus_open`, `sockbus_open` and `blebus_open` each create a named kernel object; nothing in the public header removed one. All three transports underneath already export the counterpart — `membus::destroy`, `sockbus::destroy`, `blebus::destroy` — so the abstraction was one-way across every transport it wraps, three times over, and a consumer who opened a bus through antpeer had to include the transport's own header and reach past this library to close the loop. Added: `membus_destroy`, `sockbus_destroy`, `blebus_destroy`, each a thin forward. Thin on purpose — opening is where the three transports differ (stale reclaim, create-if-missing, EEXIST tolerance) and removing is where they agree. All three tolerate a name that is not there, so they are safe to call twice. **`Client::close()` is not the pair, and the name invites the mistake.** It ends the session and drops this process's handle; the named object is untouched and outlives it, which is the point of naming one. `~Bus()` must not be the fix either — unlinking on handle close would destroy a rendezvous other peers are still seeking. So the remove half genuinely had to be separate and explicit. **The suite is the evidence, not an afterthought.** `tests/unit_test.cpp` swept its own shm segments by including `` and calling `membus::destroy` — a suite reaching past the library under test to undo what that library had done, which is how the gap was found. It now sweeps through `antpeer::membus_destroy` and no longer includes a transport header at all. 87/87 and 48/48 green; shm residue clean. **Also fixed: bare `make` built nothing and reported success.** v3.2.3 moved the include-staging rule above the rules that name it as a prerequisite — necessary, since a variable in a prerequisite expands when the rule is READ — and that made it the FIRST target in the file, which is make's default goal. `make` therefore created one symlink directory and stopped. Nothing caught it because every gate here names its target (`make test`, `make install`); the caller who types bare `make` is a person, or someone building this from the published tarball. Pinned with an explicit `.DEFAULT_GOAL := all`. ## v3.2.3 — 2026-08-24 **v3.2.1 pinned the LINK to the tree and left the COMPILE reading June.** `INCLUDE = -Iinclude` covers this library's own headers and nothing else, so all four family includes fell through to the default system path. Measured with `g++ -H` rather than read: ``, ``, `` and `` every one resolved to `/usr/local/include`, while the archives on the link line were the ones in the tree. That is a declaration/definition split, and it was not hypothetical. Three of the four installed headers had already drifted from the trees beside them: the tree's `antheos.hpp` declares a public `flags_conform(WordType, Radix, Unit)` the installed copy does not have at all, `sockbus.hpp` still published a `MAX_NAME` its tree removed as a breaking change, and `blebus.hpp` still said v1.0.0. Both suites reported 87/87 and 48/48 throughout, and still do against the correct headers — the numbers never moved, which is why nothing noticed. The fix is not a spelling change. `` is a subdirectory spelling over a FLAT in-tree `include/`, and you cannot `-I` your way from one to the other, so a build-time staging directory of symlinks supplies the missing level. No source line moves and the include a consumer writes is unchanged. It applies to every compile here rather than only the two files that need it today: a family include added later to a file not on that list would resolve to `/usr/local` silently, which is this defect returning. **Both checkouts still work, and they want opposite answers.** A standalone checkout has no sibling trees, so `/usr/local` is not merely acceptable there — it is the only place the headers can come from. The selector is the presence of a sibling source tree, the same one v3.2.1 used for the link, and the guard inverts with it rather than asserting one answer. That guard reads the compiler, not the Makefile. A text check on the include flags passes the moment they LOOK right, which is exactly how the link half stayed half-open in the first place — its `-l` flags were correct in isolation and carried no `-L`. **Also:** the README no longer states a test count. The number it carried was correct, and two independent checks already derived 87 and 48 from the suites themselves, so a wrong number could not have survived a commit. What it cost was four places to edit per added test, with the `87 + 48` sum asserted nowhere. **Not in this archive:** the guard lives at `scripts/header-origin-check.sh`, and `scripts/` is excluded from the published source set — as is `shm-residue-check.sh`, which v3.2.2 above calls "the guarantee". Both are described here and neither ships; a consumer building from this archive gets the corrected include path but not the check that holds it. ## v3.2.2 — 2026-08-19 **The test suite left one kernel shared-memory object per bus behind, forever.** A full run took `/dev/shm` from empty to 55 named objects, 736 KB, and the previous day's set was still sitting there beside them. This is caller error, not a library defect. A POSIX shared-memory object outlives the process that created it — that is what naming one is for — and `membus`'s destructor deliberately does not unlink, because closing a handle must not destroy a rendezvous other peers may still be looking for. The suite opened buses and never removed them. The names are fixed, which makes it more than untidiness: the next run does not ignore a stale object, it reuses it, so a test can pass against state its own earlier invocation left behind. No test turned out to depend on that, but nothing had been checking. `unit_test.cpp` now registers every bus it opens and unlinks the set at exit, registering before the open so a failed open is swept too. That covers the one entry point the suite uses today and cannot cover a future test that opens a bus another way, so the guarantee is `scripts/shm-residue-check.sh`: it runs the suite and diffs the directory, which does not depend on knowing the callers. It is deliberately not wired into `make test` — it runs the suite itself, so wiring it would run everything twice. Run it by hand when touching a test that opens a bus. The check refuses to answer rather than measuring when `/dev/shm` already holds a shared-memory object. A before/after diff cannot see a leak that re-creates a name already present, and with fixed names that is the normal case, not a corner — an early version of the check reported success over 55 leaked objects for exactly this reason. **Noted for consumers, not fixed here:** the test had to include `` to clean up, because antpeer wraps `membus_open`, `sockbus_open` and `blebus_open` and exposes none of the three `destroy` functions those libraries already provide. `Client::close()` ends a session; it does not remove a bus. So a consumer that creates a bus through antpeer cannot remove it through antpeer, and has to reach to the transport library underneath. ## v3.2.1 — 2026-08-18 **`make test` graded the installed Antheos family, not the one in the tree.** `-lantheos -lmembus -lsockbus -lblebus` carried no `-L` and nothing pinned them at run time, so every test binary resolved `/usr/local/lib` copies dated 2026-06-05 — from before libantheos v1.0.11's §6.1 flag-rule enforcement, its BLOB-radix fix, and the `logic` and `iso` namespaces entirely. libantpeer itself was pinned only by an `LD_LIBRARY_PATH=build` on the run line, which does not travel with the binary. Two situations are genuinely different and both have to keep working. A standalone checkout of this repository has no sibling trees: the INSTALLED libraries are the dependency there, and naming them with `-l` is correct for a third-party consumer. Inside the LangSyn monorepo the siblings are present and `make test` must grade them. The selector is the presence of a sibling SOURCE tree — a property of the checkout, which does not change with what has been built. A build-order selector would have reproduced the sibling defect fixed in membus v2.1.1. In the monorepo the sibling archives are prerequisites and are named on the link line; in a standalone checkout the `-l` names are used unchanged. Both branches were run: 87/87 + 48/48 either way, with no family shared object resolved from anywhere in the monorepo build. `libantpeer.so` is unchanged — a shared library should record `DT_NEEDED` on shared siblings, which is what an installed consumer resolves against. **The README was one transport behind at three sites.** The intro, the requirements list and the Features transport line all named membus and sockbus and stopped there, while the Makefile links `-lblebus` and `antpeer.hpp` declares `blebus_open` alongside the other two. A reader of the front page did not know the third transport existed. blebus is named without a link, and the README says why. Its three siblings each have a published repository to point at; blebus does not, and a published page should not carry a link to nothing. It is still a build requirement, and is listed as one. ## v3.2.0 — 2026-04-11 Server BLOB tail access for K-verb requests. - `Server::last_blob_tail()` returns BLOB tail from current request - Inline dispatch: delegates to `Context::last_tail()` (zero-copy) - Threaded dispatch: tail captured in WorkItem, set via thread-local g_worker_tail - 135 tests (87 unit + 48 crypto), zero regressions ## v3.1.0 — 2026-04-03 Open-source release under MIT license. - MIT license (was proprietary) - SPDX-License-Identifier headers in all source files - README, CONTRIBUTING.md, CHANGELOG - 135 tests (87 unit + 48 crypto) ## v3.0.0 — 2026-03-30 Multi-bus-hop Z-verb relay authentication. - Route struct and add_route()/set_route() for multi-hop relay paths - Relay Z-challenge/response handling in Server and Client - MESSAGE (~) word encoder in libantheos - 87 + 48 tests ## Pre-release History | Date | Change | |------|--------| | 2026-03-30 | AP-11: Ed25519 auth (Z-verb). Ed25519Utils crypto primitives, require_auth(), set_auth_key(). 85+48 tests. | | 2026-03-30 | AP-10: Threaded dispatch. set_dispatch_threads(n) worker pool. 82 tests. | | 2026-03-28 | AP-09: Antheos exceptions. SESSION_NOT_FOUND, SERVICE_UNKNOWN, Server X handler. | | 2026-03-28 | AP-08: Establish/Conflict protocol (BID collision handling). | | 2026-03-27 | AP-07: Remove OFFER broadcast — demand-driven discovery only. | | 2026-03-27 | AP-06: FrameExtractor with BLOB tail support. | | 2026-03-27 | AP-05: Port to C++ APIs (membus::Bus, sockbus::Bus, antheos::Context). | | 2026-03-27 | AP-04: C++17 rewrite from C11. | | 2026-03-16 | AP-03: Purity audit + depth test suite 21→55. | | 2026-03-16 | AP-02: Migrate all services from antserver. | | 2026-03-15 | AP-01: Initial C11 port from antserver. |