The card offers tags that are suddenly busy on other servers

[wintermeyer]

When a conference runs or something happens, a topic goes from nothing to hundreds of posts within the hour, and a member here hears of it only if they already follow that tag. Every Mastodon server publishes its trending tags with a seven-day history, without a login and for one request each, so a row under "In your feed right now" can offer what is spiking elsewhere, one click to follow it. On the day this was written #warntag stood at 1,045 uses against a median of 3 on the days before, trending on seven of the eight servers asked.

The trap is that the loudest tag is often a machine. #mow4 trended on all eight the same day: 40 of 40 posts from one domain, all 40 flagged as bots, all within ninety seconds. Both defences come free with the answer we already fetch, since a server marks bot accounts itself and the spread of authors across domains sits in the same response. A spike also shortens that tag's fetch interval at once, rather than waiting for the measured rate to catch up.

Where: the trending endpoint of each configured server, beside the fetcher from the sibling issue.

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

[wintermeyer]

[wintermeyer]

Built in PR #2159 (branch claude/external-tag-trending-2129).

The hypotheses in the body. The headline one holds and is now measured: on 10 September 2026 #warntag stood at 5,994 uses across the ten shipped servers against a median of 25 on the six days before, and it trended on 10 of the 10 that answered at limit=20 (the body's "1,045 uses, seven of eight" was one server's figure and one day's list). #mow4 is real too, and worse than described: it trended on 9 servers, and its timeline on troet.cafe was 40 of 40 statuses from social.prepedia.org, 40 of 40 flagged as bots — not "40 of 40 within ninety seconds", the forty spanned 8.6 hours. Two claims do not hold:

• "Both defences come free with the answer we already fetch" is false. /api/v1/trends/tags carries name, url and seven days of {day, accounts, uses} — no author, no domain, no bot flag. Both defences need the tag's own timeline, which is a second request. So the pass spends one GET per server plus one census per candidate it is about to offer (capped at eight).
• The spread does not catch a bot wave. #mow4 trended on 9 of 10 servers, because a farm that federates widely trends everywhere. Spread is a real gate — it drops one-server local noise — but the bot defence is what stops #mow4, and without it the row would have offered it second.

Also worth knowing: the trending endpoint is public even on the three servers that refuse the tag timeline without an account (chaos.social, sueden.social, freiburg.social, #2128's finding) — all three answered 200. So status: "account_required" does not gate who is asked, and a tag whose only sample refuses is dropped for lack of evidence rather than for the refusal.

Suddenly busy, not busy. A tag is offered when today's total across the servers listing it clears 25, is at least 5× the median of the six days before, and at least 2 servers list it. #xbox is the calibration case and the reason the rule reads a week: 130 uses today against a median of 78 — more than most tags ever see, and exactly what #xbox does every day. Ranking is by volume, the ratio is only the gate, because a tag going 0 → 30 has an unbounded ratio and is not the news. Each pill wears those seven days as six quiet strokes and one accent bar.

The bot defence, calibrated over ten trending tags × forty statuses. Distinct author domains: 1 for #mow4 on troet.cafe, 2 on mastodon.social, 13 to 26 for everything else. Bot accounts as the remote server flags them: 39–40 of 40 for #mow4, at most 10 of 40 for anything else. So min_author_hosts: 4 and max_bot_percent: 50 sit in wide margins. A sample under ten statuses says nothing and the tag is dropped — failing closed.

A spike shortens the pull at once. Vutuv.Tags.ExternalPosts.hurry/1 puts every pair of a spiking tag back to the cadence floor, due now — deliberately no strike reset and no store, so the next pass measures the real arrival rate and the pace drifts out again on its own when the event ends. It runs on every spiking candidate, before the vetting: hurrying a tag somebody already chose is a different question from offering one to somebody who did not.

One pass, every server, one clock. refresh/0 runs on the fetcher's existing two-minute tick and returns immediately unless a server is due (TAG_TRENDING_INTERVAL_MINUTES, 30), then asks all of them — the spread is a count of servers, and a pass that asked three of ten would answer it from three. Vutuv.Tags.TrendCheck is that clock: uniform, with no backoff, because a divergent one would bring a recovered server due alone and empty the offer. Calibrated: with the skip branch made a no-op, the unworkable server is still returned by due_servers/0 after a full pass — and here that does not wedge one item, it makes the whole pass run fifteen times too often, because the pass is due when any server is.

What shipped. tag_trends (the offer, replaced wholesale per pass) and tag_trend_servers (the clock), both plain additions and N-1 safe. Vutuv.Tags.Trending (the judgement, the offer, follow/2), Vutuv.Tags.ExternalTagClient.trending/1 and .authors/2 (the two new asks, sharing the timeline path's pin, blocklist and refusal classifier through one get_json/2), VutuvWeb.PostLive.TrendingTags (the row), one event in the feed.

One press does three things. It mints the tag here if nothing answers to it yet, follows it, and names the servers it is busy on as sources — otherwise following #InternationalSandwichASong would subscribe a member to a topic nobody here has ever written about. Minting goes through Tags.mintable_hashtag?/1 + find_or_create_tag_id/1, the same gate a #hashtag in a post body passes, so the row cannot mint anything the composer would not (#日本語 was in today's real list and is filtered out for exactly that reason). The offer is the permission: a pushed name that is not in tag_trends is refused rather than minted.

The browser pass, German, against the real ten servers, as a freshly registered throwaway account on a port and an origin of its own (127.0.0.1, so the shared Chrome's localhost session was never touched). window.liveSocket connected. The first pass logged Trending tags: 10 server(s) asked, 7 offered, 0 pull(s) hurried, 0 skipped, 1 failed — det.social answered 429, which is the same rate limit #2128 met. The row drew warntag, InternationalSandwichASong, iPhoneDuo, AppleEvent, DoorsDay under Gerade sehr aktiv auf anderen Servern:, with warntag folgen. Heute 5.597 Beiträge auf 9 Servern, an einem gewöhnlichen Tag 22. — the German separator, never a run-together 5597. #mow4 was not on it, though it was the second-loudest candidate. #xbox was not either. One press minted warntag, followed it, and stored vutuv, troet.cafe, mastodon.social, social.tchncs.de — the cap of three other servers — the chip above turned to 4, and the row dropped it. Two minutes later the pull brought 51 posts back from those three. Measured geometry: every pill is exactly 40 px tall and none overflows the rail's 261 px content channel (InternationalSandwichASong truncates); below md the rail is display: none and scrollWidth == clientWidth.

The three repairs from the #2128 review, each reproduced first and then calibrated:

1. The blanket rescue in SourceServerProbe.probe/2. Reproduced with a NodeInfo link document whose rel is an object, so to_string/1 raises Protocol.UndefinedError: the answer was {:error, {:unreachable, "troet.example"}} and the server was unpickable for a day. The rescue is scoped to the optional figures leg now; the timeline's verdict stands and the row simply shows none.
2. whole_number/1 without an upper bound. Reproduced: DBConnection.EncodeError … expected an integer in -9223372036854775808..9223372036854775807, got 9300000000000000000, raised out of check/2 — i.e. out of the member's own handle_event. And the same hole existed one file over: ExternalTagClient had grown a second unbounded copy for the trending history, feeding three more bigint columns. Both now go through one Vutuv.SocialFeed.Post.whole_number/2, beside clamp_bytes/2, whose own doc records the same "two callers wrote it twice" story.
3. A hostname longer than a hostname. BlockedInstance.host_format/0 bounds the shape and not the length, so TagFollowSource.refusal/1 now asks both — the same place the was soll das defect was fixed, so the message is "… ist kein Servername." and nothing leaves the machine.

Dead ends and things worth knowing.

• uses / accounts looked like a free bot detector and is not. #mow4 read 2.0 and #warntag 1.65, while the legitimate hashtag game #InternationalSandwichASong read 4.2 — the ratio separates games from conversations, not machines from people. Only the timeline census works.
• The bot farm has forty accounts, not one. accounts: 297 in #mow4's history looked like a crowd; the timeline showed 40 distinct accounts on one domain, every one flagged. Counting accounts is not counting people.
• The offer is a cache with no reconciliation on purpose: each pass deletes and rewrites it in one transaction, which is why nothing has to decide what two passes disagreeing about a name means.
• A Postgrex NOT NULL violation during the dev smoke test proved the outer net by accident: it raised out of replace_offer/2, ExternalPostFetcher's rescue caught it, and every clock had already been stamped — so a bad store cannot wedge the pass.
• Not this issue's, and still open. The row lives in the feed's rail, which is hidden md:block, so it is desktop-only — filed as The tag card and its server picker cannot be reached on a phone #2157. author_hosts / bot_posts / sampled are stored as the audit trail for the one defence this feature turns on, and nothing reads them yet; the pass's log line would be the cheapest first reader. median/1 is now the third private copy in the tree (Vutuv.References.Checks, Vutuv.BookMetadata), and two of the three disagree on an even-length list. And the "label + slate pill row" recipe this row draws is a fourth copy of markup that VutuvWeb.UI should own — left alone deliberately, because ui.ex is one of the three files whose design rule has to be kept in sync and that is a proposal rather than a drive-by edit.

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

[wintermeyer]

Shipped in 8790c3d: the card offers what is spiking on the servers in TAG_SOURCE_SERVERS, judged on the seven-day history rather than on volume, because #xbox at 130 uses a day is busy and never news. Re-measured against the live ten while reviewing, #mow4 still trended on 8 of them and would have stood second, and its own timeline was 40 of 40 statuses from a single domain with all 40 flagged as bots — so every candidate is now sampled before it is offered, which is a second request per candidate and the reason this issue's "one request each" premise does not hold. One press mints the tag here, follows it, and names the three busiest servers as its sources.

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

[wintermeyer]

What the blind review measured beyond the merge, recorded so none of it is lost.

The bot defence holds with wide margins — over today's eight vetted candidates, author domains were 1–2 for the bot wave against 9–25 for every legitimate tag (threshold 4), and bot share 97.5–100 % against 0–8 % (threshold 50). #mow4 was rejected on both gates with a full 40-status sample, not a thin one. The hole is inherent and worth knowing: a farm spread over four or more domains that does not self-declare its accounts as bots passes both gates, because both facts are the remote server's own to state. A tag whose busiest server rate-limits us is also dropped even when a second server holds a perfect crowd — vet/2 asks one server only.

Small defects left standing, none merge-blocking:

• A residual overflow the repair did not close. Post.whole_number/2 bounds each server's day, but fold/3 sums across servers with no ceiling: two servers each reporting 5×10¹⁸ fold to 10¹⁹ and raise DBConnection.EncodeError out of replace_offer/2. The transaction rolls back and the clock is already stamped, so the old offer survives — one clamp away, same class as the repair.
• vet/2 has a single clause matching %{hosts: [host | _rest]}. Safe only because fold/3 seeds hosts with one entry; a FunctionClauseError one refactor away.
• Trending.follow(nil, name) would raise, unreachable only because mount/3 redirects an anonymous socket first.
• A stale comment at feed.ex:4038 still says the tag card appears only once a tag is followed; rail_filled?("followed_tags", _) returns true unconditionally.
• The servers == 1 singular branch ships untested. The German is right, so it is coverage, not a bug.

Two pre-existing overflows of the same class, outside this feature, found while measuring: lib/vutuv/fediverse/media.ex:348 puts a stranger's content-length into a bigint with no ceiling, and credentials.ex:147/241 puts the WebAuthn signCount — a 32-bit unsigned value the client states — into an int4 column on both the registration and the login path, bypassing every changeset. The second is filed separately.

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