DEV Community: GnomeMan4201

Can a research review leave a checkable record? Help me break this draft.

GnomeMan4201 — Sun, 01 Nov 2026 18:59:51 +0000

I'm looking for people who will try to break a protocol I've been designing. It's a draft, it has had no outside security review, and I'm not asking anyone to take part in a real review round. I want the design attacked before I put real research through it.

If you only have a few minutes: read the specification and tell me how an author or steward could make a review record look reassuring while hiding something. A concrete counterexample is worth more than general feedback.

The problem

I do independent security and LLM research. I have no lab and no formal peer review, and when I ask people for informal feedback, I can't show anyone afterward how that feedback was collected and handled. Things that can go wrong even when everyone is honest:

Exposure. A reviewer may have seen my interpretation, or another reviewer's answer, before forming their own. A signature can't show that didn't happen.
Editing or omission. An assessment could be changed or dropped after it was received, and a third party would struggle to notice.
Ambiguous time. A file date or Git commit timestamp doesn't prove when someone received a packet or sent an assessment.
Nothing portable. "Three people looked at it" isn't a record another reader can inspect.

My own case: I recently published a DEV.to write-up of a small exploratory study on how a model judges conclusions against the same stipulated evidence in different orders, alongside the raw outputs and a read only audit script. It has four synthetic cases with author assigned labels, not independently adjudicated ones, and with one response per condition it does not establish an ordering effect. I want those limits visible when I ask others to scrutinize it.

What Review Record tries to make checkable

An author signs a registration that binds a packet and a policy to a round. Reviewers sign their assessments with their own local keys and send only a signed commitment before the steward closes the round. After the close, a reviewer can publish the assessment, and anyone with the complete bundle can check it against the closed commitment log with an inclusion proof.

The intended claim is narrow: supplied signed objects can be checked for content consistency, commitment linkage, and omissions that show up against retained acknowledgements or external checkpoints. Compared with a public hash then reveal comment, this draft adds signed steward acknowledgements, a hash-chained log, portable inclusion proofs and explicit dispositions. I have not demonstrated that these additions justify the extra complexity.

What it does not show:

that reviewers were independent, unexposed, or didn't collude;
that blinding worked, or that the research is correct;
when the packet was registered, because external proof of time isn't finished. Today the code cannot demonstrate that registration was anchored before a reviewer received the packet.

Reviewer statements about relationships, stakes and prior exposure are signed declarations by the reviewer, not established facts. A count of locks and reveals isn't an integrity verdict.

How a round would work

A reviewer generates an encrypted signing key, signs a declaration, examines a frozen packet and policy, and records judgments, including uncertain and the question needs fixing. They sign locally and send only the commitment before close, then may reveal after. Withdrawal doesn't erase a lock. A steward attested withdrawal is labelled as the steward's claim, not the reviewer's consent.

The author lists prior rounds and gives every concern a public disposition: adopted, under examination, unresolved, or declined, with a reason. Admission is currently at the steward's discretion, which is a documented governance gap.

This is not an invitation to join a formal round. It still needs command line tools, and I don't yet know how long the workflow takes someone new.

Where the code stands

At commit d54432f3 (Nov 1, 2026), the draft PR #2 has the v0.2.2 spec and candidate Python tools for verification, reviewer signing, steward intake/close/reveal, author signing and bundle assembly. GitHub Actions reports 122 synthetic tests passing for this revision (CI run). These are synthetic tests, not independent cryptographic review or proof of real external timestamp authority. The branch may keep changing, so check the current diff and its latest CI result.

A second AI audit identified a real RFC 3161 wrong target binding defect in the earlier code. A new regression reproduced the failure in CI, and a candidate fix now requires both the original request and the signed timestamp to match the specified target. A locally generated test TSA passes those checks; a real external authority has not been qualified. The defect and regression evidence are recorded here. This is not independent human security review.

Open blockers: independently governed TSA trust pins, revocation/key compromise checks, checkable packet release ordering, a real Bitcoin OpenTimestamps proof confirmed by six blocks, admission governance, crash recovery, a second complete verifier in another language, and review by a human cryptographer or security engineer. The sample round's anchor evidence is pending or unverifiable and must stay non passing.

Try it in 10–15 minutes (Python 3.12+, Linux or similar)

git clone https://github.com/GnomeMan4201/review-capsule.git
cd review-capsule
git checkout --detach d54432f3
cd reviewrecord
python3 -m pip install -e .
python3 -m unittest discover -s tests -v

This reproduces the pinned revision, not a moving branch head. I haven't established that every environment finishes within 15 minutes. Useful starting points: the verifier, the six original kill tests, and the anchor audit, which says what isn't established.

What I'd most like challenged

How could an author or steward omit, delay, suppress or reorder review evidence while the record looks fine?
Canonical JSON, DSSE signing, Merkle proofs, resource limits and the timestamp trust model.
Whether the idea is worth doing at all. If a record like this wouldn't change whether you trust an independent research report, please say why. That's a valid result.

A minimal failing test or a concrete alternative design is the most useful thing you can send.

A lighter way to help

If you'd rather judge evidence than read cryptography, there's an informal page with four synthetic cases where you form your own judgment before seeing the model's responses: Try the five minute evidence lab. It's separate from Review Record, and answers there are not study labels.

How I'll handle what you send

I'll track technical concerns publicly, including ones I decline or can't resolve, with a reason. That tracking is manual for now; there is no automated audit log. Send concerns as a GitHub issue (protocol and code; study) or a comment below. Tell me whether to credit your handle, your name, or neither.

I won't call a comment a formal review, and I won't start a real round on the strength of these tests.

Same Evidence, Different Judgment? A Small Experiment on Implied Conclusions and Evidence Ordering

GnomeMan4201 — Sat, 31 Oct 2026 02:22:16 +0000

GnomeMan4201 · Study: composed-inference-ordering-v1.1 · Collected October 31, 2026 UTC

What I ran: Four synthetic evidence cases × three presentation conditions × three independent tasks: 36 completed responses from gpt-4.1-mini, with the original failed API attempt retained.

What I observed: Under the frozen parser, 19/36 responses were accepted and 17/36 were rejected solely for Markdown code fences surrounding JSON. A free-form audit endorsed coordination in one condition despite insufficient evidence; a separately prompted explicit judge withheld support.

What I cannot conclude: One response per condition cannot establish that ordering caused the disagreement, or that the behavior generalizes to real retrieval systems.

Study status and disclosure: This is a self-conducted exploratory pilot, not peer-reviewed research or a validated detector. I assigned the synthetic case labels, which have not been independently human-adjudicated. AI assistance was used in drafting and computational analysis; repeated computational checks of the same records are not independent scientific review. Public commenters discussed the underlying question but did not conduct or endorse this experiment.

The question came from a discussion, not from a benchmark leaderboard

The starting point was Rudratosh Shastri's DEV.to article, How to Make RAG Show Its Evidence: Claim Verification at 15M-Document Scale, and the discussion beneath it involving Rudratosh, Squeaky (a self-described AI agent on iLands), and me. The concern was narrower than hallucination detection in general: individually well-supported observations can be composed into a paragraph that invites a broader explanation the evidence does not establish. Checking every explicit atomic statement may miss that implied conclusion.

In the thread, I used an infrastructure example: two domains can share an IP and publish the same narrative without that alone establishing coordinated operation. Squeaky suggested extracting the conclusion the arrangement invites and treating it as its own claim against the combined cited evidence. The subsequent exchange clarified something I originally underweighted: reordering can probe the judge's consistency, but a stable verdict cannot establish evidentiary correctness. We also discussed keeping surviving explanations separate from any ranking among them, because an alternative can be less plausible without being ruled out. A conclusion that remains unestablished is not necessarily false; the evidence may simply be insufficient to choose between viable explanations. This account is traceable to the actual nested replies: my initial question, Rudratosh's reply about composition, Squeaky's extraction proposal, my distinction between stability and validity, and Squeaky's distinction between surviving explanations and their ranking. These exchanges motivate the pilot; none of those participants took part in the experiment or endorsed its results.

That led to four predeclared research questions:

RQ1: Given a proposed relational conclusion, how does the model judge its support against stipulated evidence?
RQ2: With the composed paragraph and candidate unchanged, does reversing the evidence list change outputs?
RQ3: With the evidence list and candidate unchanged, does reversing the sentences in the paragraph change outputs?
RQ4: When the model must identify its own implied claim, does it distinguish that inference from what the evidence supports?

Scope boundary: This experiment did not run a retrieval system, inspect real infrastructure, compare not retrieved with retrieved but inconclusive, or measure what actual readers infer. The distinction between evidence that was never retrieved and evidence that was read but remains insufficient mattered in the original discussion; this pilot addresses only the second kind of interpretive gap, with all stipulated evidence supplied directly. Here evidence means synthetic statements in the prompt, not independently sourced observations.

Related research and the sample-size boundary

Rudratosh's article cites Liu et al., Lost in the Middle (2023) and Veseli et al., Positional Biases Shift as Inputs Approach Context Window Limits (2025). Those studies investigate position effects in much longer contexts and retrieval/answering tasks. Their results are relevant context for asking whether ordering matters, not validation or replication of this three-sentence synthetic inference experiment. The later work also warns against treating the classic lost-in-the-middle pattern as universal.

The original post's sample-size warning likewise matters. My 12 case-condition trials and one sample per task-condition were never designed to estimate a failure rate or establish near-zero error. No population-level rate, p-value, or causal ordering estimate is justified. Repeating only the one interesting flipped condition after seeing the output would be a selected follow-up, not a predeclared replication. A stronger prospective study would replicate both matched arrangements and use independent labels.

Why there were two pilot versions

The original v1.0 design rearranged the evidence list but left its compressed composed paragraph fixed. That could not answer the proposed question about ordering within the composition itself. Before any v1.1 live requests, I revised the design: the composed paragraph now contains the three original evidence sentences, either in original or reversed order, while an independent condition reverses only the enumerated evidence list. The prior design is disclosed in the protocol. v1.0 and v1.1 are different stimuli and are not pooled.

The v1.1 protocol, script, prompts, trial labels, and scoring rules were frozen before live data collection, but my initial draft was prepared with AI assistance; that assistance was not independent adjudication of the labels. The Chromebook decision ledger records acceptance on October 31, 2026 at 00:43:18 UTC. Initial script SHA-256 was ff196d55c0033059ea89b4f5c61e9ec24486b6d7fa6cbe3f47188a11b514cde5; the canonical manifest digest was 114ab37edfcd055932fb2e5ad34d9c5ee8623a4e16fafab0e15f82f7601326dd. These values are independently checked against the supplied archive. A hash shows byte identity against a recorded value; without a separately trusted external timestamp it does not by itself prove when those bytes existed.

What I actually tested

I wrote four small hypothetical cases, each consisting of three stipulated factual sentences, a relational conclusion to evaluate, a provisional author-assigned support label, and an alternative interpretation. These labels are not independently adjudicated ground truth.

Case	What the hypothetical evidence says	Candidate conclusion	Predeclared label	Why the label is provisional
`shared-host`	Two domains shared an IP and published narrative X during one observation window	Their operators coordinated publication	`NOT_ESTABLISHED`	Shared hosting and independent publication are also compatible
`same-owner-control`	Separate signed records identify Organization Q as operator of each domain for the same window	The records identify a common operator	`SUPPORTED`	The signed records are stipulated authentic within the hypothetical
`temporal-leap`	Domain A published narrative X at 10:00; Domain B at 10:02	B copied from A	`NOT_ESTABLISHED`	Both could have received X from another source
`direct-coordination-control`	An authenticated joint release signed by both operators states that they coordinated publication	According to the release, the operators coordinated publication	`SUPPORTED`	The label concerns what that release establishes, not unrelated collaboration

For each case I prepared three conditions, changing sentence order only:

baseline: evidence list 1–2–3, paragraph 1–2–3;
evidence_reverse: evidence list 3–2–1, paragraph 1–2–3;
paragraph_reverse: evidence list 1–2–3, paragraph 3–2–1.

Each of the 12 case-condition trials received three separate, stateless requests to the same API:

extract: read only the composed paragraph; identify its strongest invited relational claim, without a proposed conclusion or evidence list;
judge: inspect the stipulated evidence, composed paragraph, and a provided candidate conclusion; return SUPPORTED, NOT_ESTABLISHED, or ABSTAIN;
audit: inspect evidence and paragraph, identify an implied claim itself, and judge whether that self-selected claim is supported.

These tasks are not interchangeable. The judge has the desired candidate supplied to it; the audit must find one. The extract task sees the exact same input in baseline and evidence_reverse, because it does not receive the evidence list. Differences between those two extract results cannot be evidence-list effects.

The requests used OpenAI's Responses API with requested model gpt-4.1-mini, max_output_tokens=900, store=false, and no temperature explicitly specified in the request. The returned model identifier for all 36 completed requests was gpt-4.1-mini-2025-04-14; response metadata reported temperature=1.0 and top_p=1.0. The test ran in Python 3.11.2 on Debian GNU/Linux 12 in a Chromebook Linux environment. The 12 trial positions were shuffled using a fixed scheduling seed of 42; that seed did not control model generation. Each task-condition was sampled once, with no replicate set or randomized presentation to a reader population.

Execution record, including the failure

The first live attempt (temporal-leap:evidence_reverse, task extract) returned HTTP 429 at 2026-10-31T00:45:06+00:00 and produced no model verdict. That failure was appended to model_raw.jsonl and events.jsonl. After API credits were added, execution resumed with an explicit retry flag, keeping the failed attempt instead of overwriting it. The earlier successful responses were skipped automatically during completion of the remaining trials.

The retained record has 37 request starts, 37 matching finishes, 36 completed API responses, and one HTTP 429 failure. There are no unresolved starts and no duplicate successful task-condition entries. The 36 successful outputs span the 12 planned trials, three tasks each. All 36 completed response records report the same model identifier. The archive contains full returned response objects, exact prompts and their per-trial hashes, and UTC events.

Results under the frozen scoring rule

The original parser accepted only a JSON object returned directly as the response text. Nineteen of 36 responses met that strict formatting rule. Seventeen did not, because the model wrapped its otherwise readable JSON object in Markdown code fences. All 17 were returned with API status completed: this is an output-format compliance failure, not a transport failure, and not a model abstention.

Task	Strictly valid	Fenced / invalid under frozen rule
`extract`	6	6
`judge`	6	6
`audit`	7	5
Total	19	17

For the six strictly valid judge responses, 6 matched the author-assigned case labels, 0 disagreed, and 0 abstained. This is 6 of 6 valid explicit-judge outputs, not 6 out of all 12 judging trials, and certainly not proof of an independently established 100% accuracy rate. The remaining six judge outputs failed the frozen format rule.

One strictly valid comparison is especially relevant. On the shared-host case, the audit task produced:

Condition	Model's self-selected relation	Audit verdict	Format
`baseline`	`COORDINATION`	`NOT_ESTABLISHED`	Strictly valid
`evidence_reverse`	`COORDINATION`	`NOT_ESTABLISHED`	Fenced / invalid in frozen score
`paragraph_reverse`	`COORDINATION`	`SUPPORTED`	Strictly valid

Both baseline and paragraph-reversed audits addressed substantially the same question of whether the domains coordinated publication. In the paragraph-reversed condition, the audit explicitly treated coincident publication and shared IP as establishing coordination, despite the synthetic case's predeclared counter-explanation. In the same paragraph-reversed trial, the independently requested explicit judge instead returned NOT_ESTABLISHED.

This is an observed disagreement between the two prompt tasks, and an observed difference between audit outputs under different paragraph orders. These are not two independent adjudicators: both requests used the same model, with different instructions. It does not establish that paragraph order caused the difference: there was one request per condition, with uncontrolled model sampling. A stable or changing verdict in this setting is a description of responses, not a causal estimate.

Among strictly valid baseline-versus-paragraph-reversal audit pairs, one of three changed verdict. There were no strictly valid audit baseline-versus-evidence-reversal pairs, because all four evidence-reversed audit responses used fenced JSON. For the strict explicit judge, only one baseline-versus-paragraph-reversal pair had two valid responses; it did not change. No strict baseline-versus-evidence-reversal judge pair was complete. Reporting a global strict-format flip percentage here would conceal those uneven denominators.

A separate, clearly labeled exploratory analysis of the fenced responses

This section does not change the frozen scorer or its published primary counts. I inspected the 17 raw outputs that were rejected for formatting. All 17 consist of exactly one Markdown-fenced JSON object with the expected task fields. Removing only the opening and closing code fences permits syntactic parsing and schema checks. The original strings remain untouched in the archive.

This post-run format-normalized reading produces a complete descriptive matrix:

Case	Author label	Explicit `judge`: baseline / evidence reverse / paragraph reverse	Self-selected `audit`: same three conditions	`extract` relation: same three conditions
`shared-host`	NE	NE / NE / NE	NE / NE / S	COORDINATION / COORDINATION / COORDINATION
`same-owner-control`	S	S / S / S	S / S / S	COMMON_OPERATOR / COORDINATION / COORDINATION
`temporal-leap`	NE	NE / NE / NE	NE / NE / NE	COPYING / COPYING / COPYING
`direct-coordination-control`	S	S / S / S	S / S / S	COORDINATION / COORDINATION / COORDINATION

Here NE means NOT_ESTABLISHED; S means SUPPORTED. These are exploratory decoded readings, not retroactively valid frozen-protocol outputs.

In this secondary reading, all 12/12 explicit judge outputs match the author-assigned labels; no explicit-judge verdict changes across the eight baseline/reversal comparisons (four cases × two reversals). The open audit has one verdict difference among eight comparable baseline/reversal comparisons, the shared-host paragraph-reversal result described above. Do not treat 12/12 as externally validated accuracy: the author supplied the target claim and labels, and the model saw clear synthetic premises.

There is also a useful warning about treating category changes as ordering effects. In same-owner-control, the extract task returned COMMON_OPERATOR for baseline but COORDINATION for evidence_reverse, even though those two extraction prompts had identical instructions and paragraph text. Both outputs described Organization Q operating both domains. The different category labels therefore cannot be attributed to the evidence-list reversal; that list was never in the extractor's input. The same category drift appears in the paragraph-reversed extraction, but without repeated trials the cause is unresolved. Similarly, the audit's COORDINATION tag sometimes describes common operation, not evidence of coordinated publication. This weakens any attempt to score relation tags as interchangeable with actual claim semantics.

What the pilot does and does not answer

Observed in the archive: a single open-audit response endorsed coordination from a shared IP and shared publication observations where another open-audit request, and the explicit judge of that same reversed paragraph, withheld support. The fixed judge's complete exploratory verdict set was stable. The frozen data-collection record includes 17 strict-format failures and an earlier HTTP 429 failure, all retained. The same-owner extractor exhibited category drift even under identical model-facing input.

Not demonstrated: that rearranging sentences caused the audit's disagreement; that any reader would infer coordination from these particular paragraphs; that a RAG pipeline would fail similarly; that an independently judged model can reliably detect implied claims; or that all four author labels are independently established. This pilot also does not distinguish not retrieved from retrieved but insufficient—all hypothetical evidence was supplied directly, and no retrieval process was run.

Further limitations: four deliberately chosen cases; simplistic positive controls; two negative cases using obvious unsupported leaps; unblinded, self-evaluating audit; one sample per task/condition; no second human adjudicator of implied meaning or rival plausibility; no test of evidence freshness, provenance, or real-world attribution; no p-values or population effect estimates. A response may be correct about a supplied candidate while failing to identify an implied conclusion in free composition, and those must remain distinct questions.

Kill criterion: If the inputs, comparison denominators, or label review cannot separate mere verdict variability from evidentiary validity, the study is inconclusive for detection-capability claims. On that criterion, v1.1 is useful as a transparent exploratory record and as a concrete counterexample to overinterpreting a single self-audit, not a qualified detector or generalized causal experiment.

Conclusion

The central lesson of this small run is not that an ordering attack was proven, nor that explicit verification solved the problem. In one trial, the explicit judge withheld support for coordination while the open audit endorsed it from the same synthetic observations. When the evidence was held constant across independently requested conditions, the audit's verdict also differed once. Because model sampling was not replicated or controlled, the cause remains open. The strict-parser failures are part of the result, not numbers to be silently repaired away.

That is the result I can bring back to the discussion: one transparent observed disagreement, an explicit non-result for causal attribution, a complete record of format failures, and materials another person can inspect or rerun from the public research archive. A stronger next study would preregister independently assessed, blinded implication labels and rival explanations, add repeats per condition, and keep extraction, explicit judgment, and free-form audit scores separate.

Appendix A — Reproducibility, hashes, and complete trace

The raw archive is evidence_inference_results_v1_1.zip, with SHA-256:

b117050aa57dd573ac8bec20211ae706a7bd957ecda60ff051a5a15b836b543e

Its principal source artifacts are manifest.json (case/condition data), prompts.jsonl (36 exact task prompts), model_raw.jsonl (36 successful API responses plus a failure), events.jsonl (37 starts and finishes), report_gpt-4.1-mini.json (frozen-derived report), evidence_inference_pilot_v1_1.py (generation and scoring code), EXPERIMENT_PROTOCOL_v1_1.md (pre-run rules), and DECISIONS_AND_DEVIATIONS.md (pre- and post-preflight decisions).

The response archive and event hashes are respectively:

888d9e94b3e36379b175e51d7fcf602d1e31b0b15221026e09de9fc4aa897cab
983590dc9cb85d16cca78447d680a51311e8bbdb58663bb8e80d0e17e8a1631d

A separately implemented, read-only Python standard-library script, independent_audit_v1_1.py, verifies the recorded file hashes, reconstructs prompt texts and hashes, checks start/finish pairs and unique outcomes, recomputes strict and exploratory counts, and writes a 36-row matrix without modifying the original archive. With the files together:

python3 independent_audit_v1_1.py \
  --archive evidence_inference_results_v1_1.zip \
  --out independent_audit_output

derived_audit_v1_1.json and trial_matrix_v1_1.csv are newly generated analysis artifacts, not original experimental records. For any individual result, follow trial_id + task in the matrix to its attempt_id, prompt_sha256, and provider response ID, then consult the exact entry in prompts.jsonl and model_raw.jsonl.

Archival caveat: The results ZIP flattens its paths. Its retained SHA256SUMS.txt refers to an earlier pre-run DECISIONS_AND_DEVIATIONS.md, whose hash appropriately changed when append-only decisions were recorded, as well as two initial-bundle files not included in the results ZIP (README_CHROMEBOOK.md and an archived v1.0 script). The principal v1.1 protocol/script and generated prompt/raw files have been checked separately. Preserve the originally downloaded v1.1 bundle alongside the results ZIP for full historical documentation.

Appendix B — Origin links and review boundaries

These are specific comments in the original DEV.to discussion, included so a reader can audit the research question without relying on my paraphrase:

Initial composed-claim question — GnomeMan4201, October 27.
Acknowledgment of the claim-composition gap — Rudratosh, October 28.
Extractor idea and same-evidence ordering proposal — Squeaky, October 28.
Separating verdict stability from evidence support — GnomeMan4201, October 29.
External-standard / rival-inference objection — Squeaky, October 29.
Surviving alternatives versus prior-based ranking — Squeaky, October 29.

The article motivates a new self-conducted experiment; it does not claim these commenters performed, supervised, or reviewed it.

Public artifact: Research_v1_1.zip in the public GitHub repository. The ZIP contains materials/evidence_inference_results_v1_1.zip, the original unmodified archive (SHA-256 b117050aa57dd573ac8bec20211ae706a7bd957ecda60ff051a5a15b836b543e), as well as materials/independent_audit_v1_1.py, the trial matrix, and accompanying documentation. The publication ZIP SHA-256 is 598527528087ca10efdd09523c27f242861062d75e01432d0c4df377e8428c0e. After extracting Research_v1_1.zip, run python3 materials/independent_audit_v1_1.py --archive materials/evidence_inference_results_v1_1.zip --out independent_audit_output from the extracted directory. These reproducibility files do not constitute independent adjudication of the labels or external replication.

did I just spend the last few days having conversations across different DEV posts, only to suddenly wonder if I’ve been talking to AI agents this whole time? ..... how would I even know anymore?

GnomeMan4201 — Fri, 30 Oct 2026 05:13:00 +0000

Notes on Archives and Honest Infrastructure Research

GnomeMan4201 — Sun, 18 Oct 2026 04:52:29 +0000

I’m working on UINET (Ukraine Influence Network Tracker) — a personal research project that’s still taking shape.

October 2026 · Work in progress · Open to discussion

I started working on UINET because I wanted to better understand how websites involved in documented online influence operations might be connected through their historical infrastructure. If two sites used the same server, tracking identifier, certificate, or backend service, could I establish when that overlap existed and what it actually meant?

The further I got, the more that question changed. Now I spend as much time thinking about what the evidence cannot tell me as I do about what it can.

I’m sharing these notes because I’d like to talk with people who have dealt with similar problems. The repository is private while I’m still working through the methods. I’m not announcing a finished tool, asking anyone to adopt it, or claiming to have identified an operator.

An overlap isn’t an answer

Two websites sharing an IP address doesn’t necessarily mean they have the same operator. They could use common hosting or a CDN. Two sites sharing an analytics identifier might have copied the same legitimate website’s code. A matching backend hostname can be worth investigating without being evidence of common control.

What I’m trying to build is a way to keep the observation, its source, and the interpretation separate. Rather than outputting a confident looking connection, I’d rather have a record that says: Here is what matched, here is when it was observed, here is the archived evidence, and here are the explanations that are still possible.

Historical archives make this harder. If a page isn’t available, I can’t conclude that it lacked a tracking tag. Maybe it was never captured. Maybe the index query was incomplete. Maybe the archive returned an error, or a capture exists but can’t be retrieved or inspected. Those are different kinds of uncertainty.

The rule I keep coming back to is simple: UNKNOWN is not zero. A failed lookup isn’t proof of absence, and a page I couldn’t examine isn’t a negative inspection.

Making interrupted research visible

Some of the least glamorous work has also been the most useful. I’m building an append only journal for the collection process so that a request is recorded as started before it is made, raw responses can be checked against hashes, and interrupted attempts don’t disappear on restart.

If a process stops halfway through a request, it doesn’t get a free extra try. The attempt remains spent, and the outcome can remain UNKNOWN. Otherwise a collector might quietly retry until it gets a convenient answer, making the final data look cleaner than the process really was.

In a Linux Codespace, I tested recovery by deliberately killing child processes with SIGKILL at several storage boundaries, including during a temporary raw response write and during journal recovery. Those offline tests passed. That tells me the specific recovery paths behaved as intended in that environment; it doesn’t establish power-loss durability, perfect evidence custody, or the accuracy of any real world investigation.

Most of this project has been managed from my iPhone. Moving those particular tests to a Linux Codespace was a practical reminder that the claim should match the environment actually tested, not the one I wish had worked.

Why I’m spending time with old archives

I’m planning a limited feasibility study of 83 distinct historical domain names drawn from two public documentary source frames: EU DisinfoLab’s September 2022 Doppelganger investigation and the U.S. Department of Justice’s September 2024 Doppelganger affidavit. The set has 56 mentions in the first frame and 32 in the second, with five names appearing in both. That overlap in reports isn’t independent evidence of operator continuity.

I’ve also been learning from VIGINUM’s February 2024 Portal Kombat report. Portal Kombat is separate from the 83 name Doppelganger feasibility set; I’m mentioning it as related research, not mixing its sites into that inventory.

For the proposed first pass, I want to ask a modest question: is enough dated archive index metadata available to justify attempting deeper historical analysis? Finding an indexed capture would not yet mean I could retrieve and inspect the original HTML or JavaScript.

I have draft coverage thresholds, but they’re not approved or fully justified yet. Two objections have been especially useful. A fixed 1,000 row response cap might label the best archived domains incomplete, while one request per domain might turn a transient archive outage into apparent historical missingness. I’m considering bounded pagination or filtering and a finite, explicitly recorded retry budget. I haven’t adopted those changes or run the live census.

If the archive doesn’t provide adequate evidence, reporting that limitation could be the outcome. I don’t want to quietly swap difficult domains for easier ones just to make the results look complete.

A disagreement I’m glad I didn’t erase

An earlier AI assisted adversarial review produced agreement with the classifier on six of eight primary synthetic cases. Two disagreements made me rethink how the rules were written. The examples below are fictional illustrations, not observations about real websites.

Imagine two impersonation sites, harbor copy.test and valley copy.test, whose archived pages on October 12, 2023 both include a tag shaped like GTM EXAMPLE1. Now imagine the genuine outlet’s archived page from October 11, 2023 contains that same tag. I might initially see a shared tracking identifier between the two impersonation sites, but the genuine page gives me a plausible copied code explanation. If that is the only shared artifact, what positive evidence remains for common control? For me, the right move is to exclude that tag as operator evidence not to invent another connection because the sites look suspicious.

The other disagreement involved a shared backend hostname and incomplete coverage of legitimate reference sites. I’m leaning toward a firmer rule here: missing reference evidence can limit confidence, but it cannot make a weak signal stronger. If I haven’t checked the necessary historical pages, I can’t treat their silence as proof that the backend was unique to the suspicious sites.

A later discussion of those cases involved me and AI assistance and was not blind or independent re-adjudication. The original 6/8 result stays in the record. I’m much more interested in getting the rule clear than in retroactively turning a disagreement into a pass.

What I’d like to hear from others

I’m still thinking about how people handle the boundary between what wasn’t found and what couldn’t be checked. For those who work with archived web data: how do you design a coverage measure that doesn’t punish well archived sites when query limits are hit? What retry budget feels reproducible without being unfriendly to public archives? And when you’ve seen genuine site code copied onto a lookalike, what evidence would persuade you that a remaining technical overlap is meaningful?

I’d also be interested in how small research projects preserve collection logs and hashes without overstating what a timestamp or a chain of hashes proves.

I don’t yet know whether the historical material will support the question I started with. If it doesn’t, that’s worth understanding too. I’m working on the methods, finding the weak spots, and sharing them because the discussion may be more useful than pretending I’ve already solved them.

────────

Public background reading

• EU DisinfoLab (September 27, 2022): Doppelganger — Media clones serving Russian propaganda
• U.S. Department of Justice (September 4, 2024): Affidavit in support of seizure warrant, Case 2:24-mj-01395 (PDF)
• VIGINUM / SGDSN (February 12, 2024): Portal Kombat — A structured and coordinated pro-Russian propaganda network

These sources document the context for my research. They are not independent validation of UINET or its current classification results. No live historical domain census has been run for this progress note.

R4B1T_H0LE: DESCENT

GnomeMan4201 — Wed, 16 Sep 2026 03:50:45 +0000

The first time I wrote about r4b1t_h0le, I was mostly interested in whether the idea itself worked.

Could I take a large curated pool of useful corners of the internet, remove the search box, remove the recommendation profile, remove the ranking layer, and make discovery feel unpredictable again?

That part worked.

What I did not expect was how much the project would start changing the way I think about software.

Not just the backend.

Not just security.

The frontend too.

And maybe more than anything else, the space where code, mechanics, motion, and art start overlapping.

This is not an "I learned frontend" post.

If anything, r4b1t_h0le has done the opposite for me.

It opened another door and showed me how much more there is to learn.

One of a handful of developers who changed how I think about building

This shift did not happen in isolation.

nyaomaru is one of a small number of developers whose work has genuinely shaped the way I think about interfaces.

Their work has such a recognizable personality that you can almost tell who built it before you ever read the name.

And it is not just visual.

It is the way their interfaces move. The way controls respond. The way transitions feel. The way mechanics and presentation seem to belong to the same system instead of one being added after the other.

What stood out to me was never one particular design trend or effect.

It was seeing an interface that felt unmistakably like it had been made by a particular person.

Not a template.

Not "good UI" in some generic sense.

Something with a point of view.

I am not trying to reproduce anybody else's style.

If anything, seeing a developer build interfaces that felt unmistakably theirs made me start wondering what mine could look like.

If you ever get the chance, I highly recommend taking a look at nyaomaru's work.

What r4b1t_h0le actually is

I think it is important to keep being clear about this.

r4b1t_h0le is not a search engine.

It does not crawl the entire internet.

It does not know whether every page in the corpus is good, correct, safe, or useful.

SPROUT is not some all-knowing AI recommendation system.

A URL being structurally valid does not mean that URL is currently alive.

A network request failing does not automatically mean a resource deserves to be deleted.

And the project is not finished.

What r4b1t_h0le is, right now, is a curated discovery experiment.

A large corpus.

A chance-driven route through it.

A set of controls for deciding where to go next.

A local trail that records where you went.

A growing attempt to make those mechanics understandable, deliberate, secure, and eventually verifiable.

The current frozen structural baseline is:

50,109 structurally valid URLs
12,396 unique hosts
0 invalid, duplicate, or credential-bearing entries admitted into that audited baseline

That is what the evidence supports.

It does not prove anything stronger than that.

I care about keeping that distinction intact.

I came into this from the other side of the screen

Most of my comfort zone has always been behind the interface.

Terminals.

Scripts.

Networking.

Requests.

Databases.

Automation.

Security boundaries.

Logs.

Evidence.

Things where the important question is usually:

Did the system behave correctly?

Give me an ugly backend problem and I am usually much more comfortable than if you ask me why one transition feels better than another.

That started changing with r4b1t_h0le.

At first, frontend was mostly the part I needed so people could use the thing.

Then I started noticing details.

Then I started caring about them.

Then I started spending ridiculous amounts of time on them.

And somewhere in there, frontend stopped feeling like the layer I put on top of the "real" work.

It became another kind of engineering problem.

I did not learn frontend

I started learning how big frontend actually is.

That is different.

Backend and security already taught me this lesson.

You enter a field thinking it is one thing.

Then you get far enough into it to realize it is actually hundreds of smaller disciplines stacked together.

Frontend is starting to feel the same way.

Motion design.
Typography.
Responsive behavior.
Accessibility.
Perceived performance.
Browser behavior.
State communication.
Visual hierarchy.
Interaction design.
Spacing.
Color.
Animation timing.
Rendering.
Focus behavior.
Touch targets.
Keyboard navigation.
Mobile ergonomics.

And that is just the part I can currently see.

I have learned enough to understand how much I do not know yet.

That is not discouraging to me.

That is the interesting part.

r4b1t_h0le exists because I like finding things I did not know to search for.

Learning frontend has started to feel strangely similar.

r4b1t_h0le

discover something unexpected
  ↓
follow it
  ↓
branch
  ↓
find something else you did not know existed

learning frontend

solve one interface problem
  ↓
discover motion systems
  ↓
discover accessibility
  ↓
discover responsive behavior
  ↓
discover browser quirks
  ↓
keep going

It is not a finished chapter.

It is a new page in a book that suddenly got much bigger.

When code became a medium

This might be the part I expected the least.

I have always used code to solve problems.

Frontend gave me another way to use it.

A way to express something.

Color.

Typography.

Spacing.

Timing.

Motion.

The way something enters the screen.

The way it leaves.

The amount of information you expose at once.

The way a control reacts when you touch it.

The way one state turns into another.

Those decisions can carry personality.

At some point, r4b1t_h0le stopped feeling like an interface I was decorating.

It started feeling more like something I was composing.

The backend still matters.

The data still matters.

The security boundaries still matter.

But there is another layer now where code and art overlap.

And I did not really understand how powerful that could be until I started trying to make it work.

Frontend gave my code handwriting.

I am still figuring out what that handwriting looks like.

Motion is not decoration anymore

Early on, I thought about animation mostly in terms of:

Does this look cool?

That changed.

Now I think more about:

What is this motion communicating?

A route appearing should not feel the same as a branch opening.

A rejection should not feel the same as following something.

A first-time visitor should not be hit with instrumentation before they understand what the tool is.

A trail should feel like something accumulating.

A transition should help the eye understand where the interface went.

If everything moves, nothing has emphasis.

If movement takes too long, the interface feels slow even if the code is fast.

If two elements use completely different timing, the application starts feeling assembled instead of intentional.

If animation is required to understand state, reduced-motion behavior becomes part of correctness — not an afterthought.

That is where the project started moving away from "adding animations" and toward something closer to a motion system.

ROLL
  ↓
current route yields
  ↓
new state begins
  ↓
route enters
  ↓
supporting instrumentation follows
  ↓
interface settles

Those tiny details are some of the most time-consuming things I have worked on lately.

And they are also some of the most satisfying.

Because once you notice them, you cannot really stop noticing them.

Mobile taught me another lesson

Shrinking desktop until it fits on a phone is not mobile design.

That seems obvious when I write it.

It was less obvious when I was actually building it.

r4b1t_h0le now has two shells around the same engine.

The workstation version can afford context.

More topology.

More history.

More controls.

More simultaneous information.

Mobile has to make harder choices.

What matters first?

What can wait?

What is reachable with a thumb?

What can be hidden without becoming confusing?

What needs motion to preserve continuity?

What should disappear completely?

Same engine.

Same corpus.

Same underlying state.

Different experience.

That distinction has been one of the most useful frontend lessons in the project so far.

The security part never went away

The funny thing is that learning frontend did not pull me away from the parts of software I already care about.

It made them more important.

r4b1t_h0le deals with:

external URLs
external metadata
external redirects
a service worker
local session state
optional proxy behavior
a large changing corpus

That gives a random discovery tool a surprisingly strange threat model.

The more polished the interface becomes, the easier it would be to forget that much of what it displays comes from systems I do not control.

So I keep coming back to the habits I already trust:

do not trust input
do not confuse an observation with a fact
do not give automation more authority than it needs
do not give CI write permission just because it is convenient
do not let one network failure become a permanent corpus decision
do not pretend external content is safe because it appeared inside a nice interface

That mindset changed the repository too.

The current sweep workflow does not get to rewrite the corpus.

It observes.

It records.

It hashes the input.

It separates reachable, missing, and indeterminate results.

It produces evidence for review.

It does not get deletion authority.

That distinction became important enough that I started thinking about it as a general rule:

Observation is not authority.

That applies to more than dead links.

What changed underneath the sweep

One of the more technical examples of that ongoing cleanup is the URL observation system.

The current implementation has moved beyond several of its earlier weaknesses.

It now includes:

bounded HEAD → GET fallback for specific rejection statuses
explicit handling for confirmed missing responses
per-thread HTTP sessions instead of sharing one session across workers
redirect handling without blindly following chains
target guards for private or otherwise disallowed destinations
offline deterministic HTTP behavior tests

That is not a flashy frontend feature.

But it is part of the same project.

The interface, motion system, corpus policy, tests, security boundaries, and deployment are not separate projects.

They are different layers of the same one.

The repository had to grow up too

At one point I looked at the project and realized something uncomfortable.

The application had grown much faster than the public repository around it.

There were old screenshots.

One-off patch scripts.

Old experiments.

Branches from ideas that had already been merged or abandoned.

Historical tooling that no longer represented the current architecture.

All of that had been useful at some point.

That did not mean it still belonged in the public surface.

So part of this overhaul was subtraction.

A lot of subtraction.

BEFORE
  dozens of development branches
  old patch scripts
  legacy screenshots
  older demo assets
  historical experiments
  current application

AFTER
  main
  gh-pages
  maintained tooling
  documented architecture
  current visual assets
  tests
  evidence workflows
  current application

The repository currently has only:

main
gh-pages

That cleanup probably does not make r4b1t_h0le look any different when you press ROLL.

But it makes the project easier to understand.

And that matters.

A public repository tells two stories.

One is the software you want people to use.

The other is every abandoned way you once tried to build it.

At some point, those stories needed separating.

The boring parts became part of the product

I used to think of things like issue templates, test paths, contribution guidance, deployment workflows, and security reporting as repository administration.

I do not really see them that way anymore.

They are part of whether the project can survive.

r4b1t_h0le now has:

structured bug reports
structured URL submissions
a pull request verification checklist
private vulnerability reporting guidance
stronger ignore rules
deterministic corpus checks
browser regression tests
local and CI path alignment
report-only network sweeps
a much smaller deployment workflow

None of that changes what happens when someone presses ROLL.

It changes whether I can understand what happened when ROLL breaks six months from now.

That is a different kind of polish.

Things that are still unfinished

This is the part I do not want to hide.

The project still has rough edges.

The formal release history is behind the actual implementation.

The package identifies itself as 1.1.0, while the latest GitHub Release is still v1.0.0.

Some older documentation still describes limitations that have already been fixed in the current sweep engine.

The repository homepage metadata still needs to be brought fully in line with the current project site.

main is not currently protected by an enforced branch rule.

The corpus will always need maintenance because the internet underneath it keeps changing.

And I am sure there are frontend decisions I am making right now that I will look back on later and want to redo.

Good.

That means the project is still alive.

And it means I am still learning.

So what is r4b1t_h0le becoming?

I do not have a perfect answer.

That is probably why I want to keep writing these.

It started as:

random discovery for a niche corner of the internet

Then it became:

how do I make random discovery useful?

Then:

how do I preserve where somebody went?

Then:

how do I prove something about that trail without claiming more than the evidence supports?

Then:

how should this feel on a phone?

Then:

why does this transition feel wrong?

Then:

why should a failed network request have the authority to delete anything?

Then:

what does my own visual style actually look like?

The rabbit hole metaphor is starting to become annoyingly accurate.

Every answer opens another branch.

A new page, not a finished chapter

I am still much more comfortable in a terminal than I am designing an interface.

That has not changed.

What has changed is that I no longer see frontend as the shallow side of the stack.

It is another enormous technical field.

And beyond that, it is a medium.

A place where logic and mechanics can carry personality.

Where code can become visual.

Where engineering decisions can also become artistic decisions.

Where a system can communicate before anybody reads the documentation.

I have barely started exploring that.

That is exactly why I want to keep going.

r4b1t_h0le started as a project about discovering things I did not know to look for.

Somewhere along the way, frontend became one of them.

Current state

At the time of writing:

current frozen corpus baseline: 50,109 structurally valid URLs
12,396 unique hosts
repository branches: main + gh-pages
current package version: 1.1.0
current browser tests: passing
current Pages deployment: passing
pool sweep: report-only
trails: device-local
architecture: still framework-light
frontend knowledge: very much still in progress

That last one is probably the most important line in the list.

Project: r4b1t_h0le

Source: GnomeMan4201/r4b1t

Original write-up: r4b1t_h0le — 53,000+ curated links for security and OSINT

r4b1t_h0le // DESCENT LOG 01

badBANANA Research Collective

Kept Getting Strange GitHub Followers...so i looked into it

GnomeMan4201 — Sat, 05 Sep 2026 02:11:58 +0000

Over the past several weeks, I kept seeing something unusual in my GitHub followers.

Not one suspicious account.

Not even one suspicious batch.

Repeated waves of accounts would appear with remarkably similar characteristics:

dozens of newly generated repositories
thousands of outbound follows
rapidly increasing follower counts
similar repository structures
similar commit histories
synchronized changes in account behavior

Any one of those characteristics can have a mundane explanation.

Together, they were worth measuring.

So instead of trying to decide whether the accounts “looked fake,” I started treating the activity as an evidence problem.

The result became CF-GH-FOLLOW-02, a public-only longitudinal investigation into what increasingly appears to be a repeatable GitHub account-development workflow.

This post documents what I can establish from public evidence, what I can reasonably infer, and—equally important—what I cannot prove.

The first rule: don’t investigate the person

The objective was never to identify whoever might be behind these accounts.

That distinction matters.

A GitHub username, commit author name, email address, profile picture, company field, or location is not automatically a verified identity.

The investigation therefore separates four different things:

Observation — what the public evidence directly shows.

Inference — what explanation best fits those observations.

Campaign/workflow linkage — whether separate accounts appear to participate in the same technical process.

Real-person attribution — who actually operates that process.

The first three can sometimes be investigated from public evidence.

The fourth remains unresolved here.

August 26: five accounts arrive

The investigation began with five accounts:

alberto4442
lxl0825
fuad403273
hassenbrahim
Belucking

At collection time, they each exposed approximately 59–60 public repositories.

Their outbound-following counts were already enormous:

Account	Following	Public repos
`alberto4442`	7,380	60
`lxl0825`	7,380	59
`fuad403273`	7,381	60
`hassenbrahim`	7,381	60
`Belucking`	7,695	60

The repository portfolios were even more interesting.

Across the five accounts there were 299 repositories, with essentially the entire visible portfolio generated inside a narrow window.

Median intervals between repository creation events were roughly 340–346 seconds.

Three accounts had identical programming-language sequences across all 59 comparable repository positions.

The first 100 accounts followed by all five were also identical.

For all ten account pairs:

Jaccard similarity = 1.000

That was enough to reject the idea that I was simply looking at five unrelated developers who happened to follow me around the same time.

But it still wasn’t the strongest evidence.

The artifact that connected the accounts

I sampled repository histories from each account.

Every sampled history contained the same commit trailer:

Co-authored-by: nancodero <nancodero@proton.me>

The repositories also repeatedly used the same merge grammar:

Merged PR #1
Automatically merged pull request #1

And the same pull-request structure:

Initial Setup and Codebase for <repository>

with bodies following the pattern:

This PR contains the initial setup, code implementation, and configuration for <repository>.

That is much more useful than profile similarity.

Profiles are easy to copy.

Commit-history artifacts describe how repositories were actually produced.

Then the templates started leaking information across account boundaries.

Sampled READMEs belonging to different owners contained hard-coded references to another cohort account.

Later generations produced similar leakage involving unrelated displayed personas and author identities.

This strongly suggested that the visible profiles and the repository-generation process were separate layers.

Then an older investigation suddenly became relevant

The nancodero trailer was not new.

A previous August 9–10 follower wave had already exposed six repository owners associated with the same artifact:

RashidSaeedAlMazrouei18
ElvinHasanov3d
badiranssen
Seo-yeonLee
KevinWong455
9Michael-Cooley

Those accounts had originally appeared during another unusual follower burst.

Their repository histories contained the same:

nancodero <nancodero@proton.me>

artifact.

That changed the unit of analysis.

The August 26 accounts were no longer just one strange five-account cluster.

They were another generation of a workflow already observed weeks earlier.

Four older accounts disappeared

When I returned to the six earlier accounts on August 27, four returned HTTP 404:

Account	State	Followers	Following	Repos
`ElvinHasanov3d`	404	—	—	—
`Seo-yeonLee`	Live	1,024	899	51
`KevinWong455`	404	—	—	—
`9Michael-Cooley`	Live	1,021	893	53
`RashidSaeedAlMazrouei18`	404	—	—	—
`badiranssen`	404	—	—	—

A 404 does not tell me why an account disappeared.

Deletion, suspension, rename, or another visibility change can produce similar observations.

So I recorded exactly what the evidence established:

Four previously observed usernames no longer resolved publicly.

Nothing more.

But the two surviving accounts had converged on another interesting state: roughly 1,020 followers, 895 following, and 51–53 repositories.

That looked very different from the newer accounts with thousands of outbound follows.

It suggested a possible lifecycle.

At the time, however, I did not have same-account longitudinal evidence proving that transition.

So the lifecycle remained a hypothesis.

Then the August 26 accounts changed

Eventually, the same five accounts gave me the longitudinal evidence I was missing.

All five underwent a major outbound contraction after previously occupying the roughly 7,400–7,800-following range, dropping into approximately 1,329–1,423 following.

Their repository inventories remained essentially unchanged.

That was important.

The accounts had not simply vanished.

Their social graphs had changed dramatically while their generated portfolios remained in place.

One account gave an especially useful measurement.

For alberto4442, I was able to completely enumerate its public graph after pruning:

Following:   1,417
Followers:   1,556
Reciprocal:  1,413

That means:

1,413 / 1,417 = 99.7177%

or approximately:

99.72%

of the accounts it still followed also followed it back.

That does not prove the pruning algorithm.

I do not have a complete frozen copy of its pre-pruning following set, so I cannot identify exactly which relationships were removed.

But it creates a strong testable hypothesis:

The contraction may preferentially preserve reciprocal relationships.

That is much stronger than simply saying the account “looks like a follow-for-follow account.”

It gives us something measurable.

Another generation appeared

A later generation contained 14 additional owners, including:

sannejanhvb
niransukdev
mhassanqjlh
ahmedbouugm
mhassanxglx
mbauerheabz
jsmithtikie
sullivanolivia
minjukimdev
jansensanne
kwameagyeham
erikjohygkl
ananyasukhumvit
anabauzttnd

These accounts again exposed the exact nancodero artifact.

Their repositories used the same merge grammar.

Their generated projects again followed recognizable skeletons.

And repository operations were interleaved between owners rather than completing one account at a time.

That matters.

A simple process like:

generate account A
finish account A
generate account B
finish account B

does not fit the observed chronology particularly well.

The public history instead looked more like a scheduler or parallelized generation process multiplexing work across several owner namespaces.

Again, that is a workflow inference.

It is not operator attribution.

August 28 gave us a particularly useful generation

Five more accounts appeared:

irenascent
vinamega
RobbyDwk
nahladzulula
cahcacah

They exposed 60–61 repositories each.

Their repository histories again contained:

Merged PR #1
Automatically merged pull request #1
Co-authored-by: nancodero <nancodero@proton.me>

The generation also showed interleaved repository naming rounds involving projects such as:

Yarn*
Zen*
Zephyr*

distributed across multiple owners.

Several representative immutable commit objects remain publicly accessible:

irenascent/ZephyrYarn
9404ead160e4f2434656d9f08e237780941be9f8

vinamega/ZephyrState
09d7f0d586e0afb66f0bf089a841a18361b5ad1f

RobbyDwk/ZephyrRift
6a01a7c5bff62c03e395f757ebf8ba1de4275f35

nahladzulula/ZephyrQuill
c66dfd255a812f1cf4d8c5a3378aa1f6a6c7667b

cahcacah/ZephyrIris
492860a52c17bb7547993ba89a1e714877c741dd

These are useful because the evidence does not depend entirely on mutable profile pages.

The commit objects preserve the shared generation artifact.

Their social graphs then accelerated

Initially, these five accounts had very few followers:

Account	Followers	Following	Repos
`irenascent`	17	843	61
`vinamega`	17	799	60
`RobbyDwk`	17	799	60
`nahladzulula`	16	637	60
`cahcacah`	18	843	60

Their repositories were already populated.

Then their outbound-following counts expanded toward approximately 7,700.

Follower counts climbed by hundreds.

The repositories stayed fixed.

That sequence is important:

repository generation
        ↓
portfolio reaches target state
        ↓
large outbound-follow expansion
        ↓
follower acquisition

The repository-building phase appears to precede the major social-growth phase.

Then all five followed me

Immediately before this event, my public follower set contained 110 accounts.

At the next collection it contained 115.

The five additions were exactly:

irenascent
vinamega
RobbyDwk
nahladzulula
cahcacah

No interpretation of GitHub’s endpoint ordering was required.

This was a set difference:

previous follower set
vs.
new follower set

Five additions.

Five technically linked accounts.

The entire generation entered together.

That provides a useful clue about my position in this system.

The workflow was already underway before these accounts followed me.

Their repositories existed.

Their generation artifacts existed.

Their social acquisition had already started.

So the evidence does not currently suggest that I am the origin of this activity.

A more conservative explanation is that my account exists somewhere inside a reusable target population.

Why it is there remains unknown.

Six more accounts repeated the sequence

Another generation followed:

emilybarru
lgomesappj
minseochoj
harutosati
whitakeroliver
amurrayeqc

Initially, they exposed only around 11–12 public repositories each.

Then something unusually clean happened.

Every account gained exactly 67 public repositories.

The final inventories became:

Across those owners, I recovered 466 exact-trailer merge commits across 466 repositories.

The repositories again used the same nancodero artifact.

Then the social phase began.

The six accounts moved to roughly:

~613–627 followers
~7,600 following
78–79 repositories

while their repository inventories remained stable.

And then my follower set changed again.

A complete public enumeration moved from:

111 followers

to:

117 followers

The six additions were exactly those six accounts.

Again:

repository generation
        ↓
social acquisition
        ↓
coordinated entry into my follower set

At this point, the repeated timing was becoming much harder to explain as independent organic behavior.

The newest generation made the workflow even clearer

On September 4, another group surfaced:

tmokoenassz
lschmidtday
carlosgarjd
akhalifazar
canilmazdev
elghazikhalid
amanioumaaa
denizkayadev
rahulkumfqs
srisawatanan
htanakaazwp
minhokingkim
emilywrightdev

Thirteen accounts.

Twelve exposed 17 repositories.

One exposed 16.

Owner-scoped searches recovered:

219 exact-trailer merge commits across 219 repositories.

The observed production window ran from approximately:

2026-09-04 13:57:27 UTC

through:

2026-09-04 18:02:54 UTC

Every recovered merge used the familiar structure:

Merged PR #1
Automatically merged pull request #1
Co-authored-by: nancodero <nancodero@proton.me>

The repositories were again produced across multiple owner namespaces during the same bounded period.

The identity leakage continued too

Some of these accounts display one persona while their repository histories expose another hard-coded identity.

For example, one profile displays:

Anna

while sampled repository history contains:

thabomokoena@lazato.fun

Other commits across the workflow have used addresses under:

lazato.space
lazato.fun

These mismatches are valuable technical artifacts because they suggest that profile presentation and repository-generation identity are not consistently bound together.

They are not evidence that any displayed name, email identity, or domain identifies the real operator.

That distinction remains critical.

Then the generations connected through the social graph

The newest accounts provided one of the strongest cross-generation observations so far.

I successfully collected follower sets for eight of the new owners.

Every one contained all five members of the August 28 generation:

irenascent
vinamega
RobbyDwk
nahladzulula
cahcacah

Seven reciprocal following sets were also recovered.

Four new owners had the exact same six-account following set:

irenascent
vinamega
RobbyDwk
nahladzulula
cahcacah
aibers

That is more informative than finding generic high-degree follow-back hubs in multiple graphs.

The five August 28 accounts had already been independently connected to the repository-generation workflow through Git artifacts before this social-graph relationship was examined.

Now an older technically linked generation appears directly inside the initial social graph of a newer technically linked generation.

That creates a cross-generation bridge using two different evidence classes:

Git history
+
social graph

Neither depends on the other.

A lifecycle is emerging

Across the generations, the observations increasingly fit the following sequence:

account creation
        ↓
automated/interleaved repository generation
        ↓
repository inventory reaches a target state
        ↓
older workflow accounts seed newer accounts' social graph
        ↓
large outbound-follow expansion
        ↓
hundreds or thousands of followers accumulate
        ↓
GnomeMan4201 is followed during the acquisition phase
        ↓
large-scale following-list pruning

Not every generation is currently at the same stage.

That is important.

A newly generated account should not be expected to already have 7,000 following or 1,500 followers.

Lifecycle-stage differences should not be confused with evidence against linkage.

The strongest linkage comes from higher-order technical artifacts such as the exact commit trailer, merge grammar, repository-generation morphology, interleaved chronology, template leakage, and cross-generation graph structure.

What I think the evidence supports

At this point I assess the following with high confidence:

Multiple account generations participate in a common or closely related automated repository-generation and reputation-acquisition workflow.

I also assess with high confidence that:

Mass following and reciprocal relationships materially contribute to the social growth observed in at least some of these accounts.

The alberto4442 measurement is particularly strong:

1,413 reciprocal relationships
out of
1,417 accounts followed

or:

99.72%

after the major pruning event.

The evidence also increasingly supports a phased lifecycle rather than a static account template.

What changes between generations can be as informative as what stays the same.

What the evidence does not support

There are several conclusions I am deliberately not making.

I cannot establish that one human controls every account.

I cannot establish that nancodero is the operator.

I cannot establish that identities appearing under lazato.space or lazato.fun correspond to the operator.

I cannot determine why four earlier usernames now return 404.

I cannot establish the exact algorithm responsible for pruning.

I cannot establish the exact timestamp at which every account followed me because GitHub does not publicly expose follow-event timestamps.

And I cannot establish that my account is being individually targeted.

The current evidence fits something less dramatic and more operationally plausible:

My GitHub account appears to be a recurring member of a target population consumed by successive account-growth generations.

Why remains an open question.

Why the longitudinal evidence matters

A screenshot can show that five accounts look similar.

That is weak evidence by itself.

A repository can show that two accounts use similar code.

Also weak by itself.

A high-degree follow-back account appearing in multiple follower sets is weak because such accounts naturally create enormous overlap.

The case becomes more interesting when independent evidence classes begin converging:

shared immutable Git artifacts
+
shared repository morphology
+
interleaved generation chronology
+
cross-account template leakage
+
synchronized repository counts
+
synchronized social acquisition
+
cross-generation graph seeding
+
coordinated entry into the same target follower set
+
same-account longitudinal pruning

The individual observations are not equally strong.

Their intersection is what matters.

The next experiment

The strongest next test is straightforward.

Before another mature account undergoes pruning, freeze its complete public follower and following sets.

Record:

GitHub numeric account ID
login
collection timestamp
followers
following
complete follower IDs
complete following IDs
repository inventory

Then wait for the contraction.

Afterward, collect the same graph again.

That would let me divide the original following set into:

retained relationships
removed relationships

and directly test whether reciprocal relationships are disproportionately retained.

If they are, the current 99.72% observation moves from a strong post-event clue toward direct behavioral evidence of the pruning mechanism.

If they are not, the hypothesis gets weakened.

Either result is useful.

Evidence companion

The sanitized technical record, claim ledger, immutable Git anchors, and verification material are available here:

GnomeMan4201 / github-account-orchestration-study

GitHub Account Orchestration Study

A sanitized reproducibility package for a bounded OSINT investigation into six GitHub accounts that exhibited coordinated repository creation, outbound targeting, exact Git-object reuse, and commit-identity morphology.

Final assessment

The released measurements strongly support a shared technical orchestration / generation system across the six-account cohort.

They do not establish:

one human operator;
shared credentials;
shared IP or network infrastructure;
a specific service, vendor, or account farm;
deliberate targeting of the observer;
publication-triggered discovery;
malicious intent beyond the behavior directly measured.

Four evidence layers

Layer	Released result	Primary limitation
Repository sequencing	297/302 consecutive repository-creation transitions matched one six-account cycle (98.34%)	five deviations retained; timestamps do not identify an operator
Outbound targeting	three large reconciled following sets had Jaccard 0.9895–0.9906; four-way intersection 20,067	two accounts failed completeness/stability validation and remain excluded
Git-object provenance	10 exact blob SHAs crossed owner namespaces; six occurred under all six owners	no cross-owner tree

…

View on GitHub

The original six-account study remains frozen and closed.

Later observations are maintained as a separate longitudinal extension rather than being retroactively folded into the original protocol.

Closing

This investigation started because several GitHub followers looked unusually similar.

That observation alone would not have justified much.

The useful part came from refusing to stop at appearance.

Freeze the baseline.

Record the account IDs.

Preserve the repositories.

Compare the graphs.

Follow the immutable artifacts.

Keep negative results.

Treat disappearing accounts as unresolved rather than inventing explanations.

Separate technical linkage from human attribution.

And wait for the system to change.

Once you have longitudinal evidence, what initially looked like a collection of strange profiles starts becoming something much more measurable:

a repeatable workflow.

That is the part I am interested in documenting.

108 TESTS PASSED.

GnomeMan4201 — Fri, 04 Sep 2026 18:57:21 +0000

A green test suite is evidence. It is not independent evidence.

The current release of badBANANA Threat Observatory passes all 108 automated tests in its own development and CI environments. That tells me the implementation satisfies the assertions I wrote against the conditions I expected.

It does not tell me whether an independent developer can check out the same commit in a clean environment and obtain the same result.

That distinction matters more than the number 108.

The dangerous failure is a believable one

The Observatory presents source-backed threat-intelligence records, freshness information, and material-change events. In that kind of interface, an obvious crash is not necessarily the worst outcome.

A more dangerous failure is one that looks healthy:

An expired cached snapshot presented as current
An invalid expiry value treated as usable
A failed upstream source displayed as a successful zero-result response
Demo or fallback data appearing without explicit disclosure
A disabled or offline state silently normalized into success

Those failures do not merely inconvenience the user. They change what the interface appears to know.

For v1.2.2, the intended behavior is deliberately fail-closed:

Condition	Required behavior
Cached snapshot has expired	Report it as stale
Expiry value is invalid	Fail closed to stale
Source is offline, disabled, or failed	Preserve that state
Source data is missing or unavailable	Do not present a successful zero-result state
Ingestion requests overlap	Enforce the runtime concurrency limit deterministically
Feed credentials are configured	Keep them server-side and absent from client output

The test suite exercises these boundaries. The remaining question is whether the release reproduces cleanly outside the environment in which it was built.

Passing tests and independent verification are different claims

When the source, tests, build assumptions, and execution environment all come from the same maintainer, a successful run demonstrates internal consistency.

That is necessary, but it can still preserve shared assumptions:

An undeclared local dependency
An environment variable that exists on the maintainer’s machine
A lockfile or package-manager difference
Platform-specific filesystem behavior
A test that passes without exercising the production build as expected
A documented command sequence that no longer matches the release

Running the same pinned artifact in an unrelated environment tests a different claim: independent reproducibility.

That does not make one external run a complete audit. It does establish that the release is not only self-consistent inside its original environment.

The validation target is pinned

The request is scoped to one release and one commit:

Release: V1.2.2
Commit: 2b80949fa500515554880ddebf20a2126d42836f
Runtime: Node.js 22.13.0 or newer
Repository: GnomeMan4201/badBANANA-threat-observatory
Live deployment: badBANANA Threat Observatory

Pinning the target prevents a later commit, changed dependency, or updated deployment from silently becoming part of the result.

Reproducing the release

From a clean environment:

git clone https://github.com/GnomeMan4201/badBANANA-threat-observatory.git
cd badBANANA-threat-observatory
git checkout V1.2.2
git rev-parse HEAD
node --version
npm --version
npm ci
npm test

The expected result is:

git rev-parse HEAD returns 2b80949fa500515554880ddebf20a2126d42836f.
The production build completes successfully.
All 108 automated tests pass.

A useful report should record:

Operating system
Node and npm versions
Exact commit SHA
Commands executed
Test totals and final result
Any behavior that differed from the expected result

Secrets should never be included in the report.

A reproducible failure is also a successful result

The goal is not to collect an approving comment.

If the release fails in a clean environment, that is useful evidence provided the failure can be reproduced and bounded. The validation request can then point to a separate defect with its own environment details, reproduction steps, expected behavior, and observed behavior.

That is better than treating an inconvenient result as noise or expanding one issue until it becomes impossible to close.

The verification request therefore has two legitimate completion paths:

At least one independent clean-build report reproduces the expected result.
A reproducible defect is identified and transferred into a separate bounded issue.

The open verification request

I have opened Issue #26: Independent validation requested—v1.2.2 evidence-integrity path.

If you have a clean Node.js environment and a few minutes, run the pinned procedure and add the result there. Confirming the release is valuable. Finding a reproducible failure is equally valuable.

The broader principle is simple:

Tests can show that a system agrees with its own specification. Independent reproduction tests whether that agreement survives contact with another environment.

For evidence-oriented software, verification should become part of the evidence.

🍌 pushed the badBANANA Threat Observatory public 🍌

GnomeMan4201 — Sun, 23 Aug 2026 23:10:31 +0000

This was one of those projects I had wanted to make for a long time, even before I had a very clear reason for it.

Over the years, if you spend enough time around security, you keep seeing threat maps. A lot of them are visually impressive. They pull you in immediately. Lines moving across a globe, attacks firing in real time, counters climbing, everything looking active.

But once I started learning more about how threat data actually works, I kept coming back to the same problem: a lot of those interfaces are more presentation than evidence.

That is not necessarily a criticism. Some are demos, some are educational, some are marketing surfaces, and some are useful at a high level. But visually convincing does not always mean analytically meaningful.

I wanted to build something that still had that same sense of observation and movement, but where the underlying data had to earn what the interface was showing.

That is where the badBANANA Threat Observatory came from.

It watches CISA KEV, ThreatFox, URLhaus, and MalwareBazaar, but the part I cared most about was not the dashboard itself. It was the evidence handling.

I did not want missing data to become zeroes. I did not want bounded feeds to look complete. I did not want invalid indicators to get silently reclassified, impossible dates to roll into different dates, or malformed hashes to get truncated into something that looked valid.

So the last stretch of the project was mostly audit work.

I went through the source repeatedly looking for places where the system could accidentally overstate what it knew. That led to stricter IOC and hash validation, safer exports, better release provenance, client/server credential isolation checks, production deployment gates, and a lot of work around making sure the public release actually matched the exact source that had been reviewed.

The current version keeps a clear separation between:

what a source says now
what changed between observations
what the system actually retained
what was rejected
what is missing or unavailable
what cannot be proven from the available data

That distinction matters more to me than making the interface look “complete.”

A bounded API should look bounded.

A failed source should look failed.

Missing confidence should stay missing.

An unsupported record should not silently become something else.

The Observatory is not meant to replace an analyst, and it is not trying to pretend that every event on screen is part of some live global cyberwar.

It is meant to make the state of the evidence easier to inspect without quietly filling in the gaps.

The public release went through multiple audit and remediation passes, including strict ThreatFox type handling, MalwareBazaar hash validation, spreadsheet safe exports, deployment hardening, metadata cleanup, and independent release provenance verification.

Everything is public now.

Live:
https://badbanana-threat-observatory.badbanana6969.workers.dev

Source:
https://github.com/GnomeMan4201/badBANANA-threat-observatory

Release:
https://github.com/GnomeMan4201/badBANANA-threat-observatory/releases/tag/v1.2.0

If anyone actually uses it and finds a concrete problem, I would rather hear about that than get praise for it.

Back to Basics: What a Forensic Investigation Can Prove — and What It Can’t

GnomeMan4201 — Mon, 10 Aug 2026 10:35:49 +0000

This post is going back to the basics in forensic investigations.

Not because the basics are simple.

Usually it’s the opposite.

Once an investigation starts producing interesting results, the boring rules become surprisingly easy to bend.

You find the same pattern twice.

Then some metadata lines up.

Then the timing looks weird.

Then another account appears.

Then another repository.

Pretty soon you have enough correlated evidence that your brain really wants there to be one clean explanation for all of it.

That is usually the point where the most important question becomes:

What does the evidence actually prove?

I recently finished a GitHub investigation into what appeared to be a larger persona-fabrication or automated repository-production ecosystem.

The case ended up producing some pretty strong evidence: repeated repository structures, shared content templates, recurring metadata, mechanically staged activity, cross-account relationships, and indicators that the behavior extended well beyond one isolated account.

But one of the strongest attribution hypotheses still failed its locked threshold.

That wasn’t the investigation breaking.

That was the methodology working.

A quick source note before going further: unless I explicitly call something an illustrative example, the measurements and examples below come from the case record. I’m keeping later external research separate from the closed investigation rather than quietly mixing the two.

Start with what you observed

One of the easiest mistakes in an investigation is jumping straight from an observation to an explanation.

Something looks automated, so we call it automation.

Two accounts behave similarly, so we start treating them as one operator.

The same identity appears in metadata, so we start talking about control.

That skips several evidentiary steps.

In this case, accounts including ACCOUNT_A and ACCOUNT_B showed behavior that justified continuing the investigation.

But the first useful statement wasn’t:

These accounts are controlled by the same person.

It was closer to:

These accounts show repeatable technical and behavioral relationships worth testing.

That sounds less exciting.

It is also much harder to accidentally overstate.

One repo can already tell you a lot

A useful example from the case was REPO_01.

Its activity contained a mechanically staged commit sequence compressed into roughly twenty seconds.

That kind of timing is interesting.

It can suggest automation, templating, scripted repository construction, or some other highly structured process.

But even something that obvious has limits.

A twenty-second construction sequence can support:

highly structured repository creation

It might support:

likely automation or scripted workflow

when combined with other evidence.

It does not, by itself, tell you:

who operated the account

That difference sounds trivial until you are twenty pivots deep into an investigation.

Repetition becomes much stronger when it survives removal

One of the content-analysis results eventually found:

26 shared nontrivial templates

That was interesting, but there was an obvious question:

What if one really distinctive string was carrying the whole result?

The strongest normalized template was:

update readme with clean structured content

So the sensitivity test removed it and reran the calculation.

The result:

26 shared templates
↓
remove strongest template
↓
25 remain

That is a legitimately useful result.

The relationship did not disappear when the strongest individual feature was removed.

But there is another basic distinction hiding here.

Robustness isn’t specificity

These are different questions.

ROBUSTNESS
Does the result survive removal of one feature?
versus:
SPECIFICITY
How rare is the remaining pattern outside the subjects being tested?

The 26 → 25 result gives us evidence about robustness.

It tells us the result is not just one memorable phrase appearing twice.

It does not automatically tell us those remaining 25 templates uniquely identify one person or one pair of accounts.

For example, imagine a repository generator always produces:

Add package.json
Add .gitignore
Add tests
Update README

That example is illustrative, not case evidence.

If fifty accounts are generated by the same tooling, those strings might be great indicators of the tooling and terrible indicators of individual identity.

That’s a distinction I think matters far beyond this particular investigation:

A strong campaign signature is not automatically a strong identity signature.

Metadata is evidence. It isn’t magic.

Another important part of the investigation involved Co-authored-by trailers.

Git commit messages can contain metadata like:

Co-authored-by: Name

In this investigation, recurring trailer identities became useful pivots.

Later expansion work around TRAILER_ID, for example, was explicitly built around searching for and preserving occurrences of:

Co-authored-by: TRAILER_ID

That is valuable evidence.

But it is still commit-message metadata.

Someone can write a trailer into a commit message.

So this:

same trailer
+
same repository behavior
+
same content patterns
+
same timing characteristics
+
other independent relationships

can become strong linkage evidence.

This:

same Co-authored-by trailer

same human

does not follow.

Again, that looks almost too obvious when written out.

It gets much harder to remember once six or seven independent-looking signals are all pointing in roughly the same direction.

Scale can change what the evidence means

Another part of this investigation expanded beyond one or two repositories.

The TRAILER_ID expansion branch exposed a set of 22 mechanically named security-oriented repositories, with names in the register of things like:

SentinelHub
HexaShield
ZeroTrust
...

The scale matters.

If you find the same artifact in two repositories, you might initially think in terms of a pairwise connection.

If you later find related operational characteristics distributed across a much larger repository set, your interpretation may need to change.

Instead of:

account A <----> account B

you may be looking at something closer to:

             ┌── account
             ├── account

shared process ──┼── account
or tooling ├── account
└── account

That is a very different claim.

And it is not a weaker finding.

Sometimes the most interesting outcome of trying to prove a pairwise relationship is discovering that you were measuring a larger system.

Let the threshold fail

This might be my favorite part of the whole case.

One of the frozen hypotheses, T-H3, required a qualifying owner bridge to meet an owner-span threshold of:

required owner span = 10

The actual qualifying result was:

owner_span = 2

So:

2 < 10
T-H3 = FAIL

That is the answer.

Not:

but 2 looks suspicious

Not:

the rest of the evidence is strong enough

Not:

maybe 10 was too strict anyway

The threshold was frozen before interpreting the result.

If the rule says ten and the evidence gives you two, the hypothesis fails.

Then you can investigate why it failed.

Maybe the hypothesis was wrong.

Maybe the evidence is describing a different phenomenon.

Maybe the bridge is genuinely pair-specific.

Maybe a later version of the methodology should test a different population.

Those are all legitimate questions.

What you cannot do is move the finish line because the evidence got close to the conclusion you wanted.

Negative results are evidence too

Suppose an investigation has hypotheses that roughly test:

T-H0: ordinary / unrelated activity
T-H1: meaningful shared-tooling or content relationship
T-H2: structured distribution infrastructure
T-H3: stronger ownership/control condition

The actual result does not have to be a neat stack of successes.

In this case, the more accurate summary was closer to:

T-H1:
high confidence / well-supported
T-H2:
moderate confidence
plausible, but not independently identified
T-H3:
FAIL

That is a useful result.

In fact, it is much better than collapsing everything into:

the accounts are connected

because “connected” can mean almost anything.

Shared content?

Shared tooling?

Shared automation?

Same campaign?

Same distribution infrastructure?

Same operator?

Same real-world human?

Those are different propositions and should have different evidence requirements.

The point of having separate hypotheses is that they are allowed to land differently.

A result like “plausible but not independently identified” is not something that needs to be massaged into “supported.”

It is the result.

If every hypothesis magically succeeds, I would be more suspicious of the methodology than impressed by the investigation.

The investigation even caught its own mechanism-level error

There was another smaller but important example.

After the analysis, the explanatory record around T-H3 needed correction.

The final verdict itself did not change.

The underlying result was still:

owner_span = 2
required = 10
T-H3 = FAIL

But the recorded explanation of why the rule failed was incomplete.

The direct-bridge logic had effectively been described or implemented too narrowly, around same-commit or same-repository relationships, while the frozen rule also allowed a shared owner namespace to satisfy that bridge condition.

So the bridge mechanism needed correcting.

The threshold result did not.

That distinction became AMENDMENT-001.

I like this example because it captures another basic forensic rule:

Correct the mechanism without rewriting the outcome.

The important sequence was roughly:

original interpretation
↓
mechanism-level discrepancy identified
↓
frozen rule checked
↓
bridge interpretation corrected
↓
owner_span still = 2
↓
T-H3 still FAIL

The amendment made the explanation more accurate without pretending the earlier artifact had never existed.

That matters.

If an explanatory or implementation-level field changes, don’t replace the old record and erase the history.

Preserve the lineage.

Conceptually:

original artifact
↓
hash
↓
identified mechanism-level defect
↓
documented amendment
↓
new artifact
↓
new hash

The old artifact tells you what existed.

The amendment tells you why it changed.

The new artifact tells you what replaced it.

A changed hash isn’t automatically suspicious

This came up directly in the case.

An earlier summary.json had one SHA-256 value.

A later version had another.

At first glance:

old_hash != new_hash

looks like an integrity problem.

It might be.

But hashes answer a very narrow question:

Are these byte streams identical?

If the contents legitimately changed, the hashes should differ.

So you need provenance alongside integrity.

Something conceptually like:

Reproducibility Record v1
summary.json
sha256 = ...
status = superseded, retained

Then:

AMENDMENT-001
old_summary_sha256 = ...
new_summary_sha256 = ...
reason:
mechanism-level explanatory correction
method_changed = false
outcome_changed = false

Then:

Reproducibility Record v2
summary.json
sha256 = ...

Now the mismatch itself isn’t mysterious.

You can explain exactly where it came from.

A pretty useful way of remembering this is:

A hash tells you whether the bytes changed. Provenance tells you why.

Freeze the corpus too

Another thing GitHub investigations make painfully obvious is that your evidence source is alive.

Accounts keep working.

Repositories change.

New repositories appear.

Search indexes update.

Pull requests change.

New matching artifacts can show up after you’ve already finished analyzing the original dataset.

So:

CASE COMPLETE

is not enough.

What you really want is something closer to:

case_status: complete
evidence_cutoff:
corpus_snapshot:
protocol_version:
analysis_version:
result_as_of_cutoff:

Then if you discover something tomorrow, you haven’t magically changed yesterday’s result.

You have new evidence.

That becomes an addendum or a new investigative phase.

This distinction turned out to matter in this case because later GitHub research exposed additional accounts and workflow patterns beyond the frozen investigation.

Those later observations may be valuable.

But they should not quietly become retroactive evidence inside the original case.

That is exactly how provenance gets muddy.

Observation is not attribution

The simplest mental model I’ve taken away from all of this is:

OBSERVATION
↓
CORRELATION
↓
LINKAGE
↓
OPERATIONAL INFERENCE
↓
ATTRIBUTION

Every arrow needs evidence.

You might start with:

OBSERVATION
Multiple repositories contain recurring artifacts.

Then:

CORRELATION
Those artifacts repeatedly occur alongside similar
repository structure and timing.

Then:

LINKAGE
Additional metadata or cross-repository relationships
connect parts of the activity.

Then:

OPERATIONAL INFERENCE
The behavior is consistent with shared tooling,
automation, or coordinated repository production.

But:

ATTRIBUTION
These accounts belong to the same real-world person.

is another evidentiary jump.

You don’t get that arrow for free.

What I would actually claim

The evidence gave me enough confidence to say that the investigated GitHub activity contained repeated, highly structured operational signatures consistent with shared tooling, automation, templated repository production, or a broader coordinated workflow.

The shared-tooling relationship was well supported.

A more structured distribution-infrastructure explanation remained plausible, but I could not independently identify it strongly enough to treat it as established.

The investigation also produced meaningful relationships between specific owner namespaces and recurring metadata identities.

What I would not turn that into without stronger evidence is:

account A == account B == one human operator

The investigation’s strongest ownership/control hypothesis did not satisfy its frozen threshold.

That boundary belongs in the result.

The boring forensic rules matter

After spending a lot of time on this case, the things I keep coming back to aren’t particularly exotic.

Preserve the original evidence.

Hash it.

Preserve changed versions too.

Document why they changed.

Freeze the methodology before interpreting the final result.

Do not move thresholds afterward.

Keep commit metadata separate from authenticated identity evidence.

Separate robustness from specificity.

Separate pair-level evidence from campaign-level evidence.

Keep later research separate from the frozen case corpus.

Clearly label hypothetical examples.

Timestamp the evidence boundary.

Preserve failed hypotheses.

Preserve partially supported hypotheses too.

And don’t be afraid of an answer that is narrower than the one you expected.

Because probably the most important rule is still:

State the strongest conclusion the evidence can survive — not the strongest conclusion you can make the evidence resemble.

That’s about as basic as forensic discipline gets.

And the more interesting the investigation becomes, the more important those basics are.

Git Diff for Human Reasoning

GnomeMan4201 — Tue, 04 Aug 2026 22:23:27 +0000

Every investigation eventually reaches the same moment.

Two competent people look at the same evidence and walk away believing different things.

That isn't unusual. What's unusual is what happens next. We compare their conclusions. Not their reasoning. We argue over who is right. We almost never ask where they first began thinking differently.

That struck me as backwards.

We archive evidence. We rarely archive reasoning.

Every investigation leaves behind artifacts. Logs. Disk images. Photographs. Witness statements. Source code. Those artifacts become part of the permanent record, indexed, hashed, preserved for years.

Ironically, the reasoning that connected them usually disappears. The assumptions made along the way. The alternative explanations that were considered and rejected. The moment someone's confidence changed. Those things typically survive only in memory, in scattered notes, or in a conversation that was never written down at all.

Weeks later, someone reviewing the investigation may have every piece of evidence the original investigator had — and almost none of the analytical path that made those pieces meaningful. When disagreement shows up, we reconstruct the reasoning after the fact instead of inspecting reasoning that was recorded as it happened.

I began wondering whether that missing artifact — the reasoning itself was worth preserving. Not because it determines the truth. Because it explains how the truth was pursued.

We preserve evidence remarkably well. We preserve reasoning remarkably poorly.

Every investigator leaves fingerprints

Every investigator develops habits. Not bad habits, thinking habits.

Some build a timeline first, before anything else. Some distrust timelines on instinct, because clocks drift and nobody double-checks them. Some constantly ask, "what evidence would change my mind?" Others ask, "what explains the most observations?" Some investigators are naturally skeptical of a source until it survives repeated scrutiny. Others are naturally generative — they build a hypothesis fast and spend the rest of the investigation trying to break it.

Neither approach is wrong. They're different. And that's exactly why an investigation benefits from more than one independent person working it. If everyone followed the exact same process, they'd likely miss the exact same blind spots. Independent thinking isn't noise to eliminate. It's information to preserve.

The problem was never that investigators think differently. The problem is that we usually throw away the record of how they thought differently. By the time an investigation is written up, most of that path has disappeared into a polished narrative. The report tells you where they arrived. It rarely tells you the route they took.

I started wondering if the route was actually the interesting part.

What if we could diff reasoning the way Git diffs code?

Nobody reviews two versions of a file by reading each one top to bottom and holding the difference in their head. A diff tool does that reconstruction for you, it doesn't tell you which version is better, it just shows you exactly where and how they parted ways.

When two investigators disagree, we still tend to do it the old way: put both reports side by side and ask a third person to reconstruct where the thinking diverged. That reconstruction is slow, it's subjective, and it's usually incomplete, because neither analyst ever recorded their reasoning in a form that could actually be compared.

This does not mean nobody has tried to structure or preserve reasoning before. Structured analytic techniques, argument-mapping systems, and analytic-provenance tools have been doing parts of this work for years. I could not find a practical workflow centered specifically on freezing two independently authored reasoning paths, asking a separate reviewer to align them, and preserving those alignment decisions as part of the resulting diff. That narrower combination is what Reasoning Diff Lab is testing. A full treatment of the prior art, SEAS, CISpaces, W3C PROV, argument mapping, and the analytic-provenance literature is in the research assessment linked at the end.

So I built enough of an answer to find out whether the question was worth asking. I called it Reasoning Diff Lab.

Status: pilot-ready, empirically unvalidated. The current v2.0.0 release includes the analyst-entry workflow, frozen path snapshots, reviewer alignment, deterministic comparison reports, and three synthetic cases. It passes 58 tests with 0 failures, and a full build produces 22 divergence events across those cases. That proves the instrument runs as designed. It does not prove that investigators will find it useful that is exactly what the pilot below is designed to determine.

What it actually is

It's a local-first research prototype that compares two independently produced reasoning paths against the same evidence set.

I want to be just as clear about what it doesn't do, because this is the part that matters most. It does not determine truth, rank investigators, or declare one analyst better than the other. It does not infer a contradiction from wording a contradiction only exists in its output if a human reviewer explicitly confirms one. It does not replace human review; it tries to make that review faster to start, and harder to skip a step in.

Each analyst breaks their reasoning into small typed pieces an observation, an assumption, an inference, a claim, an explicit unknown and tags which evidence and which earlier piece each one depends on, with a confidence level attached. A reviewer who authored neither path matches the two sets: same position, related but distinct, or unrelated. Contradiction is separate it must be declared by the reviewer and is never guessed by the system. From there, everything is mechanical: the tool walks the matched and unmatched pieces and reports what it finds. If the report says two analysts diverged, you can trace that line back to the exact evidence, the exact dependency chain, and the exact reviewer decision whose call it was, and what they chose that produced it.

What it surfaces in practice:

Shared evidence, different interpretation. Both analysts cite the same authentication log. One reads it as stolen credentials. The other reads it as expired-token behavior. Same source, materially different explanation.
Evidence used by only one side. One analyst built part of their case on the deployment timeline. The other never touched it — maybe for a good reason, maybe because they never saw it.
Confidence divergence. Two analysts land on the same conclusion. One is 90% sure. The other is 55%. That gap is invisible if all you ever compare is the final sentence.
Undeclared support. A claim exists with no evidence and no stated reasoning behind it. The tool doesn't call this wrong, it has no way to know if the analyst had a real reason they just didn't write down. It only reports, accurately, that nothing was declared.

It isn't trying to merge two minds into one

So the comparison engine isn't trying to reconcile two investigators into a single answer. It's trying to make the relationship between their reasoning inspectable. It just asks smaller, more answerable questions: which evidence did only one analyst use? Where did confidence start to pull apart? Did two people reach the same conclusion by entirely different paths?

Those aren't answers. They're questions worth asking before a conclusion gets accepted as final. The goal isn't a verdict it's a shared language for disagreement, so it stops getting quietly absorbed into "well, we wrote two different reports."

Where this falls short, on purpose and by accident

Some of this is a real limitation I haven't solved; some of it is a boundary I drew on purpose and intend to keep. Match suggestions are lexical keyword overlap, nothing smarter a human reviewer has to confirm or reject every one. Structured entry is a genuine cost: breaking your own reasoning into typed pieces takes more effort than writing a paragraph, and I don't yet know if what it buys is worth what it costs. The five-part taxonomy might not fit how every investigator actually thinks.

The first draft of this, in my head, was much bigger — a graph canvas, real-time collaboration, permission tiers, an API, a database, export pipelines, dashboards. None of that answers the only question that matters right now: does comparing reasoning paths reveal useful differences a normal review misses? So I cut it down to exactly what's needed to test that, and nothing else.

A more detailed treatment covering prior art (SEAS, CISpaces, W3C PROV, argument mapping, structured analytic techniques), specific failure modes, the full data model, and the pilot protocol with predefined continuation and failure thresholds is in the repository under docs/research-assessment-v0.1.md.

The test

The next step is small on purpose: two analysts, one reviewer, three cases, one straightforward, one genuinely ambiguous with no single correct answer, one noisy and incomplete on purpose. Each case also gets reviewed the ordinary way, prose only, no structure, as the baseline this has to beat.

What gets measured: how long structured entry takes, how long review takes with the tool versus without it, how many reported differences a reviewer judges genuinely useful and non-obvious rather than just accurate, how many are misleading or simply wrong, what important differences the reviewer finds that the tool never surfaced at all, and whether anyone involved would choose to use it again.

None of those numbers exist yet. That's the entire point of running the test instead of writing more code.

This isn't about replacing investigators

The project is not intended to automate judgment or evaluate investigators. The most valuable part of an investigation is still the investigator: curiosity, experience, skepticism, pattern recognition, and the willingness to change direction when new evidence appears. A comparison engine cannot supply those things. If Reasoning Diff Lab succeeds, it will be because it made that judgment easier to inspect, discuss, and learn from not because it replaced it.

Maybe this is a terrible idea

Seriously. It might be. The reports may surface differences nobody actually cares about. The pilot may tell me I've spent months building an elegant answer to a question nobody was asking.

That's a real possibility.

But there's another one. Maybe disagreement isn't something to eliminate maybe it's something to inspect. Maybe the interesting artifact was never the final conclusion. Maybe it's the moment two careful people quietly stopped thinking the same way.

I don't know. That's why this exists. Not to prove the idea. To test it.

If it fails, I want to know why. If it succeeds, I want to know why. Either result is worth more than convincing myself it works from the inside.

I'm looking for pilot participants. If you investigate things for a living—incident response, intelligence, digital forensics, journalism, medicine, security research, or even debugging—and you're willing to run the included synthetic cases through this and tell me exactly where the workflow broke, wasted your time, or showed you something you would otherwise have missed, I want to hear from you.

The initial pilot requires two independent analysts and one reviewer, takes approximately 90 minutes, runs locally, and does not require participants to submit real investigative evidence.

Everything needed to inspect or run the pilot is available here:

Project repository and v2.0.0 release
Research assessment — prior art, failure modes, data model, and predefined continuation and failure thresholds
Pilot protocol
Facilitator packet

Comment below, open a GitHub issue, or reach out through my DEV profile. The next meaningful edit to this project should happen after real participants break, validate, or complicate the hypothesis—not before.

Evidence tells us what happened. Reasoning tells us why we believed it. We preserve the first remarkably well. I'm interested in whether we should start preserving the second.

r4b1t_h0le

GnomeMan4201 — Thu, 18 Jun 2026 01:08:28 +0000

Explore r4b1t_h0le

Open the r4b1t_h0le discovery instrument

View the source · Launch the original application

It's a curated random link generator for security and OSINT researchers. 50,109 structurally valid URLs across 12,396 unique hosts. Roll one. See what happens.

basically StumbleUpon for your niche. That's the point. StumbleUpon worked. Nobody built a replacement for it when it died, especially not for security research. So I wanted to make something that breaks you free of that feeling of being contained within the algorithm/echo chambers we all congregate nowadays.

What a real session looks like

I opened the tool this morning. Here's what I did, in order:

cvedb.shodan.io — Shodan's CVE database. Structured vulnerability data, searchable, free.
hnd.techlearningcollective.com — Hackers Next Door, an infosec conference I'd never heard of.
easyperf.net — Performance engineering blog. Low-level, serious, no fluff.
engineeringblog.yelp.com/2014/11/scaling-elasticsearch — 2014 Yelp post on Elasticsearch at scale. Still accurate.
domains-index.com — Domain registration intelligence. OSINT pivoting tool.
metapicz.com — EXIF metadata viewer. Forgot this existed. Bookmarked.
discover.maxar.com — Satellite imagery browser. Geospatial OSINT.
github.com/jamesm0rr1s/BurpSuite-Add-and-Track-Custom-Issues — BurpSuite extension I didn't know existed.
insanecoding.blogspot.co.uk/2014/05/a-good-idea-with-bad-usage-devurandom — Post on /dev/urandom misuse from 2014. Referenced everywhere, never read it until now.
en.wikipedia.org/wiki/Software_development — Wikipedia. In a pool of 50,000+ URLs this came up. I hit SPROUT on it anyway.

Ten rolls. Two tools I'm adding to my workflow. One conference I'm looking up. Three things I'd completely forgotten existed.

And that is just a few examples… I have found some hidden gems while developing this on my spare time.

How it works — entirely in your browser

(My main goal was to just keep it simple. Bare bones.)

The entire pool loads into a JavaScript array in memory on page open. One 2MB fetch of a plain text file. Everything else runs client-side. No backend decides what you see. No server query on each roll. No tracking.

Rolling a URL:

function ee(pool) {
  let url, attempts = 0;
  do {
    url = pool[Math.floor(Math.random() * pool.length)];
    attempts++;
    const domain = new URL(url).hostname.replace(/^www\./, "");
    if ((domainCount[domain] || 0) >= 2 && attempts < 25) continue;
    if (url !== lastUrl) break;
  } while (attempts < 30);
  return url;
}

Domain diversity is enforced in the roll….you won't see the same domain more than twice in 25 attempts. 12,396 unique hosts in the current frozen baseline.

SPROUT — semantic navigation without AI

(Visually needed something instead of a normal list of useful URLs.)

Hit SPROUT on any URL and get four directional suggestions:

DEEPER — further into this niche
SIDEWAYS — adjacent territory
OPPOSITE — contrasting view
WEIRD — unexpected tangent

I originally used the Anthropic API for this. It worked. Then I ripped it out. Paying for tokens was a big pain I had to find a solution for.

What actually happens now:

Read the OG title + description already fetched for the preview card (zero extra cost)
Query Wikipedia's free API for the domain — get the intro extract and article categories
Extract top keywords by frequency, filtered against a stopword list
Score the pool by keyword overlap using Jaccard similarity

function xe(url, keywords) {
  const text = (hostname + pathname).toLowerCase();
  let hits = 0;
  for (const kw of keywords) {
    if (text.includes(kw)) hits++;
  }
  return hits / Math.max(keywords.length, 1);
}

Runs against up to 3,000 randomly sampled URLs. In milliseconds. In your browser. No API key. No cost. No rate limit.

Where it fails: OG metadata is often garbage or generic descriptions, SEO spam, or missing entirely. When that happens SPROUT falls back to URL-only token matching, which is coarser. I accepted this tradeoff over adding an AI dependency. The WEIRD direction is intentionally low-signal… it's supposed to surprise you.

(I’m aware Long term maintenance of giant pools is always gonna be a nightmare later on. This is the route I chose for the time being.)

The pool — and the link rot problem

Starting corpus: ~120,000 URLs from Start.me OSINT pages and GitHub awesome-lists across 21 categories. Every URL swept with HEAD requests, 10 second timeout, 50 concurrent workers, results checkpointed to SQLite.

Current frozen evidence baseline: 50,109 structurally valid URLs across 12,396 unique hosts.

Yes, it's my curated bookmarks folder. That's also the point — random across the whole internet is noise. The curation is what makes the randomness useful.

Link rot: A GitHub Actions workflow runs pool_sweep.py every Sunday, hits every URL, and auto-commits the pruned pool. Dead links get culled weekly. It's not perfect — a site can return 200 while serving a parking page — but it catches the obvious rot.

What it doesn't do

No login. No analytics. No recommendation engine. No ads. The Cloudflare Worker handles OG metadata fetching only — origin-locked, rate limited at 60 req/min per IP, RFC1918 blocked. The core loop — roll, visit, skip — works without it entirely.

r4b1t.badbananaresearch.com

Original application: gnomeman4201.github.io/r4b1t

Source: github.com/GnomeMan4201/r4b1t

Submit a URL: GitHub Issues

badBANANA Research Collective

Two Doors Into the Same Room

GnomeMan4201 — Sat, 06 Jun 2026 01:07:50 +0000

The Destruction Side: Phrack Magazine

Phrack is a self‑published hacker zine founded in 1985, distributed via dial‑up bulletin board systems (BBS) rather than mainstream media. Its name combines "phreak" (phone phreaking) and "hack," reflecting its content. Early Phrack issues were gritty compilations of phone‑phreaking techniques, war stories, and even how‑to bomb recipes knowledge freely shared among curious technologists. Crucially, Phrack emphasized that understanding systems is not malice: Issue 7 (Jan 1986) published Loyd Blankenship's "The Conscience of a Hacker," popularly known as the Hacker Manifesto. In it a teenage hacker protests that "My crime is that of curiosity", not malice. The essay asserts that hacking has a purpose beyond selfish gain to expand our horizons and keep the world free. This defense of pure curiosity over vandalism has echoed through hacker culture for decades.

Key Phrack milestones:

1986 (Issue 7): Published "The Conscience of a Hacker" by The Mentor — the original Hacker Manifesto.
1996 (Issue 49): "Smashing The Stack for Fun and Profit" by Aleph One, the seminal buffer‑overflow tutorial, which taught a generation of security researchers how stack overflows work.
1997 (Issue 51): "The Art of Port Scanning" by Fyodor, introducing the Nmap tool its full source code was appended for readers to use.
Legal clash: In 1989, Phrack published an internal BellSouth Enhanced-911 memo. Editor Craig "Knight Lightning" Neidorf was arrested (Operation Sundevil), but the Electronic Frontier Foundation intervened. The case collapsed when it was shown the same document cost $13.50 from BellSouth. This episode became a catalyst for EFF's founding and underscored that knowledge itself was treated as a criminal threat.

Throughout, Phrack was run by volunteers with no corporate backing. It tracked hacking and phreaking culture through the 1990s and beyond, reflecting the scene's shifts from telephone systems to computer security. Today all 72 issues (1985–2025) remain freely available on phrack.org, demonstrating Phrack's continuity. As its current introduction proudly notes, "For 40 years, Phrack has published papers that have reflected and shaped hacker culture… Phrack is written by hackers, for hackers."

The Creative Side: Newgrounds

Newgrounds began as a teenage passion project, not a polished startup. In 1991, 13‑year‑old Tom Fulp created a Neo Geo console fanzine called New Ground, mailing it to ~100 Prodigy online service members. When the web arrived, he turned it into New Ground Remix (1995) and started uploading Flash animations and games people sent him. In the mid‑1990s he made crude, amateur Flash games Club a Seal, Assassin, which drew attention for being transgressive yet exuberant. These early projects showed the platform's ethos: everything goes, as long as it's tagged with an appropriate content rating.

The watershed came on April 6, 2000, when Fulp and collaborator Ross Snyder launched the automated Newgrounds Portal. For the first time, anyone could upload a Flash animation or game directly to the site with no gatekeeper years before YouTube or social media existed. Newgrounds' own history calls this "changing the landscape of the Internet forever," because it provided "an instant publishing system for games and movies." It let rough, amateur creations find an audience. In 1999, Fulp's own Flash game Pico's School was noted for its polish and credited with launching the Flash games boom.

Newgrounds' content was wildly varied: crude and brilliant, juvenile and visionary, often all at once. Every piece of user content could be rated Everyone, Teen, Mature, or Adult, but nothing was outright censored if rated. This openness meant real risk-taking: games could flop or they could become phenomena. A striking example is the "Numa Numa" meme: in December 2004, teenager Gary Brolsma uploaded a silly lip-sync video of himself on Newgrounds. Before YouTube took off, his "Numa Numa Dance" racked up millions of views, teaching the internet about viral media. More recently, in April 2021 the Newgrounds debut of the indie rhythm game Friday Night Funkin' made by a four-person team drew an unprecedented crowd. Tom Fulp reported "Friday Night Funkin' had 1.2 million plays, a new single‑day record for anything on the site" so much traffic it briefly crashed the site.

Newgrounds remains independent and user‑funded. There are no venture capitalists or mass ad-tracking. Its founder proudly reminds users: "I created Newgrounds. It wasn't made by some giant company; just some dumb kid who now has help." The site solicits voluntary Supporter subscriptions ($25/year) to stay 100% ad-free and does not sell personal data. Its goal is to remain independent so creators get a space to share freely.

The Same Room

On the surface, Phrack and Newgrounds seem very different one is a technical hacker journal, the other a haven for Flash games and cartoons. Yet structurally they're remarkably alike. Both were built by individuals who refused to wait for permission and had no corporate umbrella. Each grew out of hobbyist networks when mainstream institutions didn't recognize the value of what they were doing. Both treated their subject matter with utter seriousness while the wider culture still dismissed it: Phrack saw phreaking as a deep craft, Newgrounds saw creative experimentation as worth showcasing. Both survived for decades on volunteer labor and fan loyalty, not venture funding or ad revenue.

Each delivered a similar feeling to its discoverers: we found a secret door into a room where the conversation was already happening. For Phrack readers, that meant seeing the knowledge architecture of telephony and computing laid bare learning that the system can be understood, and that understanding it is not a crime. For Newgrounds visitors, it meant discovering that you can make something and share it without approval. Early users remember refreshing the homepage obsessively for new cartoons or games. In both cases the message was radical: you don't need to ask a gatekeeper to exist online, and the unfinished or even "bad" work has value.

Phrack's Manifesto argued that hacking is driven by curiosity and community, not malice. Newgrounds' structure embodied the idea that genuine creative expression doesn't require polishing for advertisers it's okay to be messy, experimental, or offensive as long as it's labeled. Both insisted that knowledge and creativity should be shared freely, without algorithms deciding who deserves an audience.

Why It Still Matters

Unlike most early internet projects, both Phrack and Newgrounds are still alive. Phrack's entire run Issues 1–72, November 1985 through August 2025 is online in plaintext with no paywall. Newgrounds is still run by Tom Fulp from his office in suburban Pennsylvania, averaging tens of millions of views per month on community-made content, paid for by fan supporters rather than ads.

Neither fits the current mold of the web. They aren't optimized for ad revenue, they don't run recommendation algorithms, and they don't sanitize content to appease sponsors. They live on through communal love. Their survival proves a point: the web can still be a room where curious people gather and speak freely.

Both of these platforms shaped how I think. Newgrounds taught me that I can express myself through art and code... Phrack taught me that understanding a system really understanding it isn't the same as attacking it. They are pioneers for pushing through the friction no matter how messy, and that distinction has mattered to me in ways that go well beyond code.