Logos Forum — review
Follow-up review of edenbd1's LP-0026 submission: build from source, test, verify technical claims, use it live, sample its demo video · repo edenbd1/lp-0026-forum, default branch HEAD 5fd43e0 · checked against an earlier review of the same repository, also at 5fd43e0
The repository has not moved — zero commits since the earlier review, at the identical commit. That makes most of this review a direct re-verification rather than a check for change: the known defect (a false "no QRegularExpression anywhere" claim) is still there, unchanged, at the same two lines. The test-count claim (47) is still wrong by the same margin (52 real tests). CI is still green. The crypto, the token bucket, the backoff formula and identity rotation all check out exactly as documented.
One thing is genuinely new, though, and it changes how the known defect should be read: the actual catalog-published package a real evaluator installs does not contain the code the false claim is about. Source at HEAD is version 0.4.0 and includes a full RLN-sponsor UI (a status banner, a retry button, a copy-able payer address) built around the exact detail-string parser the earlier review flagged. The published package is version 0.3.5 — older — and its compiled backend has none of that integration's methods at all. The QRegularExpression call is a real, verified defect in the source CI tests and in what a contributor sees reading the code; it is not currently reachable by someone who only ever installs what the README tells them to install.
Jump to: Has the repo moved? · The known defect, re-checked · Technical claims verified against source · The e2e logs · Using it live · The demo video · How I reviewed · Not tested
Has the repository moved since the earlier review?
No. The default branch HEAD is 5fd43e03ea1e6989b7571cf321a88b5bd3b7c637 — the exact commit the earlier review examined, confirmed by git merge-base --is-ancestor and by the commit message itself ("e2e on 0.3.5: on a network that blocks public DNS, history with everyone offline passes with the package the catalog serves"). Nothing has been pushed since. Every finding below that says "unchanged" or "still" is a direct re-read of the identical source, not an inference from a diff.
The known defect, re-checked
"No QRegularExpression is used anywhere" — still false
Unchanged at the exact lines the earlier review cited: src/logos_forum_backend.cpp:1052 constructs a static const QRegularExpression to parse the RLN provisioning status string "<payer> needs <n> native (<price> price + <reserve> fee reserve); it holds <m>" — a few hundred lines from the comment at line 1418 explaining, correctly, why the app normally avoids this ("a QRegularExpression here would JIT-compile inside Basecamp's hardened runtime, which has no allow-jit and traps"). The claim appears verbatim in two places, both still present: docs/e2e.md:193 ("Also avoided by design: no QRegularExpression anywhere…") and submission/LP-0026.md:96-98 ("No QRegularExpression is used anywhere…").
Tested the regex itself against a real logged detail string (docs/e2e/e2e-history-offline-0.4.0-logos.test-unfunded.out:15, a genuine funding-wait message from a real run) — it matches correctly and extracts all five fields. So functionally the parser works when it runs; the claim is still specifically about whether it exists at all, and it does.
What's new this time: see the next finding — the practical reachability of this defect has changed, even though the source hasn't.
The published package is a different, older build than HEAD — and doesn't contain the code the known defect is about
metadata.json at the current source HEAD declares "version": "0.4.0". The package the catalog actually serves — downloaded fresh, sha256-verified against the catalog's own index (031a17df…, exact match) — declares "version": "0.3.5" in its own manifest. Diffing the package's qml/Main.qml against the source tree's copy shows this is not a cosmetic gap: the published QML has none of the RLN-membership status banner, the "Try again now" retry button, the copyable payer-account field, or the rlnJson/rln/rlnBlocks properties that drive them. Checking the compiled backend plugin (logos_forum_plugin.so inside the package) for the corresponding method names confirms it: it links the older, basic RLN state-query API (from the project's own earlier "0.3.1: ready for RLN networks" work) but has none of retryMembership, rlnJson, giftError, or membershipAnswered — the methods the sponsor/gifter integration (and the QRegularExpression call inside it) depends on.
In plain terms: the known defect is real in the source a CI run builds and a contributor reads, and it is not reachable in the binary a real evaluator installs from the catalog today, because that binary was built before this code existed. That could change the moment the catalog is updated to match current HEAD — at which point the unfixed defect becomes live for real users. This is independent of whether the defect itself should be fixed; it should, and the fix is still simple (swap the hand-rolled QRegularExpression for the same by-hand parsing approach line 1418 already uses elsewhere in this file, and correct the two doc claims).
Evidence: metadata.json (HEAD) vs. the package's own manifest.json; src/qml/Main.qml (source) vs. qml/Main.qml (package, extracted); strings logos_forum_plugin.so | grep -i retryMembership etc. (empty) vs. the symbols that are present. Full diff output and string-search results in probes/results.txt.
Test count: README still says 47, the real binary still has 52
Built core/ from scratch with the system toolchain (g++ 12.2, cmake 3.25, libsodium 1.0.18, sqlite3 3.40.1, nlohmann-json 3.11.2) — a clean build, no warnings. ./forum_core_tests: 52 tests, 0 failures. Rebuilt the same sources with -fsanitize=address,undefined: 52/52, clean, no sanitizer reports. README line 30 still reads "the core has 47 tests of its own." Not adversarial — the under-count favors the submitter least, if anything — but it's the same unverified number the earlier review flagged, unchanged.
Technical claims, verified against source
| Claim | Where | Verdict |
|---|---|---|
| Posts are content-addressed by SHA-256 | core/src/post.cpp:78-83 — Post::id() hashes a canonical, domain-separated ("logos-forum:post:v1") byte serialization with crypto_hash_sha256 | Confirmed |
| Posts are Ed25519-signed and verified | core/src/post.cpp:86-88, 98-100 — crypto_sign_detached/crypto_sign_verify_detached (libsodium's Ed25519) over the same canonical bytes the id is hashed from | Confirmed |
| Identity rotation | core/src/identity.cpp — rotate() zeroizes the old secret key (sodium_memzero), generates a fresh keypair, resets the post counter; author_anonymously() generates a one-time keypair, signs, then zeroizes it immediately | Confirmed, and correctly implemented (the old key is actually wiped, not just discarded) |
| Token-bucket rate limiter | core/include/forum/engine.h:49-56 — RateLimiter(capacity, per_minute), refills by elapsed time, consumes one token per take(); instantiated as limiter_{5, 20} and explicitly shared between the user's own posts and history answers ("History answers share the rate limit with what the user writes," engine.cpp:224) | Confirmed, genuine token bucket |
| Exponential backoff, "2s…5min" | core/src/store.cpp:82-86 — backoff_ms(n) = min(1000 << clamp(n,1,20), 5*60*1000); gives exactly 2000 ms at n=1, caps at 5 minutes | Confirmed, exact |
The e2e logs
docs/e2e/ carries versioned, real run output across many releases, not just the one the earlier review read. Re-read e2e-full.run7-0.3.2-logos.dev.out in full: 24 named checks (four nodes join, topic/alias/anonymous propagation, two anonymous replies on genuinely unrelated keys, a second account's posts linked to neither the first account nor each other pre/post rotation, an offline post that "reached no one" until reconnect, a newcomer recovering all 7 posts and holding exactly the same set as the original node), all ok, PASS (24 checks), exit=0 — texture consistent with a genuine multi-process harness, not a templated fabrication (specific node names, specific key fragments, specific counts that change run to run).
Also read two more recent logs the earlier review didn't cite: e2e-history-offline-0.4.0-logos.test-unfunded.out and e2e-sponsor-0.4.0-logos.test-unfunded.out, both from the RLN-sponsor integration specifically. These show a real, honest failure case — a sponsor with an unfunded wallet, the sequencer rejecting the registration transaction with a real error code ("Incorrect fee", wallet_ffi error 18), and the app's own retry-with-backoff behavior (1 min, then 3 min) — exactly the kind of log that would be awkward to fabricate since it documents the submission's own infrastructure not working at capture time. I read these; I did not re-run any of them. Re-running a multi-node, multi-day e2e scenario myself would need real additional devices and elapsed time this review didn't spend.
Using it live
Installed the real, sha256-verified logos_forum-0.3.5.lgx into a real Basecamp 0.3.2 via the documented lgpm --allow-unsigned install --file path (delivery_module 0.3.0, storage_module 3.0.2, both from the official catalog). Launched: an account auto-created, and the app connected to the live default network without any setup — matching the README's claim that logos.dev "needs no RLN, so anyone can post with nothing to set up." Within seconds the status line read "Connected · Caught up · 3 new · Storage ready" and a real topic from the live network ("testnet reboot: LEZ redeploy checklist") appeared — first-hand confirmation that history-from-peers actually works, not just a claim read in code. No RLN banner appeared anywhere in the UI, consistent with the package-staleness finding above (the package that was installed doesn't contain that UI at all) as well as with simply not needing one on this network.
I did not author any post this session. The app connects to the live public network by default, and the past two reviews of this same submission family already established a public, verifiable test-post on it; adding another wasn't necessary to confirm functionality already demonstrated live below and in the cited e2e logs.
The demo video
Downloaded the real file (youtu.be/xNY5EzhCtuI), not just the title or thumbnail: 223.26 seconds, matching the claimed "3:43" exactly. The description's own chapter list is detailed (11 named chapters). I did not watch it as continuous video with audio — I have no video player. I extracted still frames at each chapter boundary with ffmpeg and checked what's actually on screen. YouTube reports no subtitle track of any kind for this video (auto-generated or otherwise), so unlike a video with burned-in captions, there is no text-based proxy for the narration available either — this review has visual confirmation of what's on screen at eleven specific timestamps, and nothing about what's said.
What the sampled frames show, directly: a real two-node live session with topic and reply propagation (0:55), an alias post ("Ghost") and an anonymous reply both visibly signed and verified (√) by two different real devices (1:34), and — in the same frame — a post made after key rotation, correctly showing a new, unrelated key, alongside a newcomer's full recovered history including the pre-rotation and post-rotation posts together (2:28). A later frame (2:58) shows a terminal window title bar reading proof.sh visible behind the app window, indicating the demo session itself was driven by a script rather than hand-clicked — consistent with the project's broader pattern of scripted, repeatable evidence capture, and worth noting as context rather than a finding either way.
How I reviewed
Code. Cloned the repository fresh; confirmed the default branch HEAD against the commit the earlier review cites. Read core/src/{post,identity,store,engine,dns}.cpp and their headers in full, and the sections of src/logos_forum_backend.cpp around the known defect and the full RLN provisioning state machine (not just the one flagged line), to understand which other states exist and whether any of them have a similar parsing risk (none do — every other state passes a plain string through for display, with no regex or hand-rolled parser of its own).
Tests. cmake -S core -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j4, then ./build/forum_core_tests directly (not just via ctest, to see individual test names). Rebuilt with -fsanitize=address,undefined and re-ran.
CI. Checked the actual GitHub check-runs for the real current HEAD via the API (not a cached or historical run): all 8 jobs (core tests ×2 platforms, Basecamp module ×3 platforms, rln_gifter_module ×2, multi-platform package) completed/success.
Packages. Downloaded logos_forum-0.3.5.lgx from the catalog's own release asset; sha256 matches the catalog index exactly. Extracted it and diffed its qml/ tree and inspected its compiled plugin's exported strings against the source tree, which is what surfaced the package-staleness finding above.
GUI. Reused the same Basecamp 0.3.2 install/launch infrastructure proven in the companion Forumer review (an AppImage extracted and run through a newer glibc as an explicit dynamic-linker interpreter, since the host's system glibc is older than the binary needs), on a fresh Xvfb display and a clean HOME. Installed via the documented lgpm fallback.
Video. yt-dlp (with Node.js as the JS runtime, required for current YouTube extraction) to fetch the actual file; ffmpeg -ss TIMESTAMP -frames:v 1 to sample stills at each chapter boundary from the video's own description.
Not tested
- Real multi-day or multi-node e2e scenarios — read the project's own versioned logs (including two the earlier review didn't cite) rather than re-running them from scratch, which would need real additional devices and elapsed time.
- The RLN-sponsor flow live, end to end — this review did not attempt to fund a wallet and drive a real sponsored-membership registration; relied on the project's own real logs for this (which themselves show an unfunded failure case, not a successful funded run).
- Whether the catalog will be updated to match current HEAD before or after this review is read, which would change the practical reachability finding above. This is a snapshot as of today.
- macOS and Windows builds — CI builds both; neither was run here.
- The demo video's narration — no captions or subtitles exist for this video (checked directly, not assumed), so only what's visible in the sampled frames is confirmed, nothing about what's said.
- Whether the one-time anonymous key generation (
author_anonymously) is wired correctly end-to-end from the Qt/QML composer through to the engine in every disclosure-mode code path — read the core library's own implementation and confirmed it's correct there; did not trace every QML call site.
Environment: Linux 6.17, x86_64, Basecamp 0.3.2 (reused extracted AppImage + glibc workaround), Xvfb, g++ 12.2 with system libsodium/sqlite3/nlohmann-json 3, yt-dlp with Node.js as the JS runtime. Repo cloned fresh to a scratch directory and never modified. Re-run the checks with probes/README.md.