Our own posts help a tag pass the bot-wave test

[wintermeyer]

Before a tag is offered as busy elsewhere, its posts are counted by author server, and a tag written by too few of them is dropped as a bot wave. This installation counts as one of those servers. On a topic that is mostly our own members writing, our own echo therefore helps the tag past the very gate meant to catch a single source — measured on troet.cafe's #vutuv, the census saw six author servers including ours, and on mastodon.social's, three including ours. Nobody sees it directly; it decides what the feed offers.

Our own host should not count towards that diversity, for the same reason it no longer counts as a find. The posts themselves are already refused at ingest, so this is the one place the echo still speaks.

Where: author_entry/2 in Vutuv.Tags.ExternalTagClient, read by Vutuv.Tags.Trending.verdict/3.

An AI agent wrote this text in my name. I know that is problematic.

[wintermeyer]

Built in PR #2202.

The issue's numbers reproduce exactly. Re-measured against the live timelines on 11 September 2026: troet.cafe's #vutuv carried 40 statuses over 6 author servers, 35 of them ours; mastodon.social's carried 40 over 3, 38 ours. Both figures are the ones the body names.

What the fix is, and why it sits one layer above where the body pointed. ExternalTagClient.author_entry/2 now refuses a status ExternalPost.written_here?/2 says was written here — the same predicate the pull asks at ingest, asked of the author's host and of the permalink, so a relay that relabelled one of our posts is caught too. It drops the statuses, it does not subtract from the domain count, and the measurement is the reason: take our 35 out of troet.cafe's #vutuv and five foreign servers remain, which still clears min_author_hosts: 4. An exclusion that only fixed the diversity metric would have offered that tag anyway. Run through the shipped function against the real timeline, as this installation and then as vutuv.de:

as localhost  troet.cafe: sampled=40 hosts=6 bots=0 offered=true
as vutuv.de   troet.cafe: sampled=5  hosts=5 bots=0 offered=false

The invariant the rule must not break: it may only ever remove evidence we produced ourselves, never a stranger's. So a host that merely contains ours (mirror.<host>, not<host>) stays a stranger, and a tag with a genuine crowd out there keeps being offered with our posts simply absent from its figures — that is its own test, asserting author_hosts == 4 and sampled == 16 where the fixture also holds five of ours.

Volume and bot share, the second half.

• Volume stays inflated and cannot be cleaned. /api/v1/trends/tags carries name, url and seven days of {day, accounts, uses} — no author — so a remote server's uses counts our federated posts and there is nothing in that answer to subtract. It does not have to be: a tag busy here and nowhere else runs out of sample. That is now a real gate rather than an argument — #vutuv on troet.cafe falls to five statuses and is dropped by min_sample: 10, not by the domain count. The cost is that such a tag still becomes a candidate and still spends one of the eight census slots; that is written into the moduledoc so a thin offer is not later misread as a fetch failure.
• Bot share is now measured over strangers only, which is strictly the stricter direction as long as nothing of ours is flagged a bot: the same count of bots over a smaller denominator. Ten bot statuses beside ten of ours read as 40 % and passed; alone they read as 80 % and do not. Its own test.

Both directions, over the live corpus. The dev database is no corpus here — the nightly production copy has none of the external-tag tables, because none of this milestone has shipped to production yet. So I measured the source, as #2179 did: today's pass over the ten configured servers produced eight vetted candidates, and the rule changed nothing in either direction — 8 offered before, 8 after, no tag lost, none gained, because not one of those eight timelines carries a single vutuv.de status. The losers are therefore a class rather than a list: a tag whose fourth author server, or whose tenth status, is us — which is the tag this issue exists to drop. I also asked whether any single author host decides any of today's eight, ours or anybody's: none does.

Browser pass, German, own dev server on its own port, typeof window.liveSocket === "object" and connected, <html lang="de">, requests read from the server log. A live pass over the real ten servers logged asked: 10, listed: 9, offered: 8, failed: 1 (det.social answered 429, the rate limit #2128 met) and the row drew Gerade sehr aktiv auf anderen Servern: with 70smoviestaughtme, FensterFreitag, JukeboxFridayNight, WindowFriday, neverforget and German separators (Heute 2.048 Beiträge auf 7 Servern, never 2048). No tag changed, as measured. To see the exclusion work in the running server against real servers I pointed :fediverse_tag_host at mastodon.nz — a real author on #JukeboxFridayNight and not one of the ten, so the source list stayed the same — and re-ran the pass: that tag's census fell from 40 statuses over 11 author servers to 27 over 10, #70smoviestaughtme from 40/13 to 39/12, every other tag untouched, and the row kept all five pills because no verdict flipped. Then restored.

Dead ends and things worth knowing.

• min_author_hosts alone would not have fixed this, which is the finding that shaped the change. Five of troet.cafe's six #vutuv servers are foreign.
• There is no live tag today whose offer turns on one author server. So the honest browser answer is "nothing changed", and the demonstration had to be constructed.
• The census does not ask the blocklist about the authors it counts, only about the server it queries — parse/2 does that for the pull, authors/2 does not. So a status from an operator-blocked instance is still a distinct author server and still counts in the bot share. That is this issue one gate lower, and it is out of this issue's scope: it needs its own measurement. Worth filing.
• Fediverse.own_host?/1 parses its argument twice (local_host?/1 and tag_host?/1 each normalize the same string), so a stranger's status pays four URI.parse where two inputs exist. Measured at ~13 ms of CPU per hourly pass, i.e. noise, and the predicate has seven callers including the follow gate — not something to change on the side of this.
• @census_limit's 40 is now the size of the ask, not of the sample. Fetching a second page to refill a sample thinned by our own echo would cost a round trip per tag to rescue the tag we want dropped, so it is declined in the comment rather than left open.

An AI agent wrote this text in my name. I know that is problematic.

[wintermeyer]

Shipped in 0a1e90aac. The refusal sits in the census itself rather than in the verdict's domain count, because taking our 35 statuses out of troet.cafe's #vutuv leaves five foreign servers — still more than the gate wants — so an exclusion that only fixed the diversity metric would have offered that tag anyway. Dropping the statuses instead makes all three figures the gate reads (author servers, sample size, bot share) describe strangers, so a tag busy only here runs out of sample rather than borrowing ours. Volume stays inflated and cannot be cleaned: the trending endpoint carries no author, which I confirmed against the live API.

An AI agent wrote this text in my name. I know that is problematic.