Republication and Amplification

What a republication question asks of the record

This page is written for counsel deciding what a technical record can contribute to a republication or amplification question in an internet defamation matter. It is not written for the subject of the content and does not address what can be done about the content itself. Whether a given act amounts to republication is a legal question; what follows is what the records show about the act.

The useful thing about this element is that the legal test is asked about facts only the technical record answers. Was the content modified, and how? Did it move? Was it re-promoted to a fresh audience? Was it copied, and in which direction? Those all have observable, dateable answers, and an examiner who produces the change record — precisely dated, described in neutral terms, and hashed — has done the part that is technical and stopped where the argument begins.

The failure mode is the opposite: an examiner who calls a change a republication, or a repost amplification with an audience attached. Both are conclusions the record does not carry.

The change record, and what a diff can and cannot date

Four categories of artifact carry most of the weight, and all are collectible.

• Modification. A diff between archived versions shows what text changed and between which two observations. That places a bound on when a change happened — after the earlier capture and by the later one — not a timestamp for the edit. Crawl-driven archives are sparse, so the bound is often wide, and stating its width is part of the finding.
• Movement. A URL change, a domain migration or a redesign that reissues content at new addresses leaves redirect chains observable as 301 and 302 responses in captured HTTP headers, changes to rel=canonical, sitemap entries carrying lastmod dates, and archive captures at both addresses.
• Re-promotion. A return to the homepage, an entry in a newsletter archive, a fresh social post linking the same URL, an updated byline stamp, a dateModified value in the structured data, and re-entry in an RSS or Atom feed are each separately observable.
• Content management revisions. A defendant's own publishing system usually keeps a revision row for every save. That row set is the closest thing to a change log anyone gets, it is deleted by routine database maintenance, and it survives only if it is named specifically and early.

What none of these produce is intent. A dateModified value moved because something wrote it; the record does not say what, or why.

How one court applied the single publication rule to a website

The most-cited American application of the single publication rule to web content is Firth v. State of New York, 98 N.Y.2d 365, decided 2 July 2002. As the opinion reads (read 15 August 2026), the court observed that "communications accessible over a public Web site resemble those contained in traditional mass media, only on a far grander scale," and described the trigger this way:

"Republication, retriggering the period of limitations, occurs upon a separate aggregate publication from the original, on a different occasion."

"The mere addition of unrelated information to a Web site cannot be equated with the repetition of defamatory matter in a separately published edition of a book or newspaper."

I report that as decided and do not extend it. Whether the rule governs in a particular forum, how a limitations period runs, and whether a specific change amounts to a separate aggregate publication are legal questions.

What matters to a technical examiner is the phrase "the mere addition of unrelated information." Relatedness of an addition to the disputed passage is a factual distinction before it is a legal one, and it is what a version-by-version diff makes visible: whether the disputed sentences were touched, whether the surrounding article was rewritten, whether the page was reissued whole. Producing that comparison, and declining to characterize it, is the technical contribution.

Share counters, and the three things they do not count

Everything true of view counters is true of share counters: unaudited totals produced by undisclosed logic, provisional, adjustable afterward. Three problems are specific to shares.

Deletion is invisible in the counter. A repost later deleted may or may not decrement the displayed figure, and the operator does not publish which. Today's count is not a count of reposts that currently exist.

A quote-post and a plain repost are different acts — one adds the sharer's own words and one does not — and platforms frequently aggregate them into one displayed number, or split them inconsistently between interface and API. An examiner who reports the figure without saying which acts it aggregates has reported a number of unknown meaning.

Enumeration is generally not possible. Listing who reshared a post requires programmatic access the major platforms have restricted, on terms that change often enough that I would check them on the day. An examiner can usually observe the aggregate figure and document a sample of visible resharers, and cannot produce a complete list. Say so, rather than letting a sample imply completeness.

Establishing that two pages carry the same content

Where content has been copied across many sites the forensic problem is well-posed and the methods are mature. There are two, answering different questions.

Exact duplication. Extract the text, normalize it — Unicode normalization, whitespace collapse, boilerplate removal — hash it, and compare hashes. Scriptable, reproducible by anyone with the same inputs, and explainable without a whiteboard.

Near duplication. Scrapers introduce small edits, so exact hashing fails and shingling with MinHash or SimHash is used instead, producing a similarity score that survives minor changes. That requires the examiner to state the shingle size and the similarity threshold, and here is the part that matters: the threshold is a choice, not a fact. The research for this site found no standards-body publication and no accepted forensic threshold for near-duplicate text. Treat that absence as a finding. The threshold has to be justified from the data in the matter — by showing where the score distribution separates, and reporting how the matched set changes at neighboring thresholds — rather than by citing a standard that does not exist. An opinion that does not disclose it is not reproducible.

Direction of copying, and evidence of common operation

The more valuable question is not whether two pages match but which came first and whether one party operates both. Several artifacts speak to it.

• A canonical tag pointing back at the origin. Automated scrapers frequently copy the rel=canonical element along with the text, leaving a self-identifying artifact of copying inside the copy.
• Feed fingerprints. Content republished from an RSS or Atom feed carries the feed's characteristics: truncation at the excerpt length, feed-specific entity encoding, images absent because they were never in the feed, and the feed's date format.
• Hotlinked assets. Images still served from the origin's own delivery network show that the copy never fetched and rehosted the originals.
• Shared account-scoped identifiers. Analytics measurement IDs, ad publisher IDs, affiliate tags and identical tracking snippets appearing across otherwise unconnected sites are strong evidence of common operation, because those identifiers are issued to a registered account rather than typed in by anyone. This is one of very few open-source signals in this subject that leads toward an account holder rather than a cluster of pages, and it is under-used.
• Ordering evidence. The earliest archive capture of each copy, feed timestamps, and the earliest Certificate Transparency entry for each hostname. RFC 9162 (read 15 August 2026) describes such a log as "a single, append-only Merkle Tree of submitted certificate and precertificate entries," and a Signed Certificate Timestamp as "the date and time at which the certificate or precertificate was accepted by the log." That is a public, independently operated, cryptographically verifiable anchor for when a hostname existed. It says nothing about what the site said.

AI answers repeating the content

This is the newest surface here and the one with the least settled record. Three things can be said carefully.

First, there are two different phenomena. A retrieval-grounded output — a search summary, or an assistant with live retrieval — surfaces and paraphrases a page that exists and can usually be identified from the citations displayed; that is an amplification question about an underlying publication. A parametric output asserts something the model produced without a retrievable source — a claim about the operator's own output, with different evidence.

Second, the evidentiary problem is reproducibility and it is severe. Outputs are non-deterministic and vary with the account, the session, the personalization state, the retrieval index and the model version, which the operator changes without notice. There is no public archive of AI answers, and no web archive can capture one, because the answer did not exist before the query. Contemporaneous capture is the only route, and it records more than a screenshot: the exact prompt, the interface and any exposed model version, the account state, the date and time with the zone, and the complete output including citations.

Third, the step almost everyone skips: run the prompt again, a stated number of times, and report how often the statement recurred. A reproduction rate is a real finding either way, and only available if somebody tried. Capture the interface as well as the answer: the disclaimers a product displayed and the version it was running are facts about a moment that nothing archives.

Where section 230 sits, and the word 'user' inside it

One statute governs much of the argument here and is constantly paraphrased incorrectly, so it is worth reading in its own words — 47 U.S.C. § 230(c)(1) (read 15 August 2026):

"No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider."

Two textual features get missed. The immunity runs to a "provider or user" — the word "user" is in the statute — and § 230(f)(3) defines an information content provider as "any person or entity that is responsible, in whole or in part, for the creation or development of information."

Whether any of that protects a particular sharer is a legal question and not one I answer. The technical consequence is worth stating: because added commentary and the shared underlying item are separable in the statute's own terms, they have to be separable in the evidence. That means collecting each reshare as a distinct object — its own permalink, timestamp, author and added text, captured in full — rather than as a number appended to the original post. A share count does not distinguish these acts. A collection built one reshare at a time does.

What the spread record honestly shows

For a retention decision, the record here shows this and no more. Presence: these copies existed at these addresses on these dates. Sequence: this copy was observable before that one, to the precision the captures allow. Common operation, sometimes: where account-scoped identifiers are shared. Change: what text differed between two observed versions.

And what it does not show. It does not show audience: fifty scraper copies with no traffic are fifty copies, not fifty audiences. It does not show who caused the spread, because automated scraping is indiscriminate and a copy on a content farm is evidence of a content farm rather than of a campaign. And it is never complete — search coverage is partial, scraper sites are often excluded from indexing on purpose, and copies inside apps, private groups, newsletters and messaging platforms are invisible from outside.

So every count is a floor. The defensible sentence is "at least N copies were located by the following methods," with the methods named. "The content was copied N times" is not available from any method I am aware of.

Frequently Asked Questions

Published 2026-08-15