[A13xB0]

This is the second of six PRs for the Data tab (plan).

Stacked on #14. This branch contains #14's four commits. Review #14 first; once it is merged, this PR's diff shrinks to the two internal/origin commits.

What it adds

A new package, internal/origin (its own module, depending only on areamap). It works out where a packet started and how each area heard it. It is plain functions over a packet, its observations and the node positions. Nothing calls it yet; PR 3 (the data index) will.

Where it started. The first rule that gives an answer wins:

1. The advert's own position, if it has one that is not 0,0.
2. The sender's node record, for an advert without a position.
3. The first relay, by majority across observations, using CoreScope's resolved key, then the prefix.
   • A 1-byte hop never places anything.
   • A shared prefix places only when every holder with a known position stands in one area.
4. The observer's own area, for a packet heard with no relay at all.
5. Otherwise unknown. This is counted, never guessed.

How each area heard it, one entry per receiving area:

• Observers: distinct observers there, matched case-insensitively.
• Relayed: one of the area's own repeaters carried it in.
• Across: it came straight from the starting area, with no repeater of the receiving area involved.
• From: the relay an observer there heard it from.
• Gate: the home-area relay at the boundary. This only applies when Home is set.

Via: every area whose placeable repeaters passed the packet on.

Observers without a position are placed by their own node record, then by the areas' iata lists. Areas come from one areamap layer.

Tests

• Red commit 53b7510: a stub returning zero values, so every test fails on its assertions. Green commit 2108e69.
• The tests port meshcore.scotmesh.net's peering rules, covering:
  • prefixes that agree or conflict;
  • companions that never act as hops;
  • IATA placement, matched whatever the case;
  • relayed vs heard across;
  • the gate when leaving and when arriving;
  • every origin rule, including majority voting and an observer that relays its own copy;
  • each observer counted once per area;
  • layers kept independent;
  • a nil area map.
• An allocation test holds Derive to at most 2 allocations per packet.
• Ran scripts/allmod.sh vet and test (18 of 18 modules) and the Dockerfile COPY invariant check. gofmt is clean.

Benchmark

BenchmarkDerive-12   1.10 µs/op   224 B/op   2 allocs/op   (3 runs: 1110, 1101, 1100 ns)

Lookups lower-case into a stack buffer, and per-packet tallies live in fixed arrays. The only allocations are the record's Heard and Via slices.

Gate: agreement with the running implementation

I ran the last 24 hours of pre-prod packets through both meshcore.scotmesh.net's internal/peering and this package:

• Data: 7,091 transmissions, 44,672 observations and 1,078 nodes, taken as a read-only extract.
• Areas: the same outlines, built as an areamap. Scotland is cut out as a hole wherever peering tests it first.

	Differences
Node placement	0 of 1,078
Origin	0 of 7,091
Heard (per area: observers, relayed, across, from, gate)	0 of 7,091
Via	0 of 7,091

The plan's threshold was within 1%. On that data, Derive averaged 4.9 µs per packet.

The only intended difference: an advert placed by the sender's node record reports basis node. meshcored reported it as advert.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KaR4xu8gVykQBkH8yG8m6H

[A13xB0]

Superseded by #16, which carries this as its own commits alongside the rest of the Data tab (one PR, as asked).