Skip to content

Topsites and infrastructure

A Scene site is a private infrastructure node used by trusted participants and affiliated release groups. It is not a public download portal, tracker or searchable streaming catalogue. “Topsite” usually implies a site with valued affiliates, reliable infrastructure and standing within part of the Scene, but there is no universal ranking authority.

Modern public evidence still supports the basic site model: release groups publish into private infrastructure, automated systems announce and replicate releases, and category rules determine whether a release is valid. The exact present-day network is not publicly observable.

What a Scene site consists of

A site is not one program or one directory. It is a layered system combining server hardware, storage, transfer services, access control, release automation, metadata and private coordination.

Layer Components Purpose
Compute and network One or more servers, high-bandwidth connectivity and operating-system services. Keep transfers, scripts and databases available with low latency.
Storage Large disk pools, historically including RAID, with local archive and backup policies. Retain complete releases and reduce the effect of a failed disk. RAID improves availability but is not itself a backup.
Transfer daemon An FTP-family server process; glFTPd is the best-documented historical example. Accept authenticated connections, expose directory trees and enforce accounts, permissions and commands.
Sections Separate areas such as applications, games, audio, film or television. Apply different access, retention and local policy to different release categories.
Accounts and roles Siteops, affiliates, couriers/racers, nukers and other trusted users. Give each role only the directories and commands required for its work.
Affiliate workspace Restricted areas used by affiliated groups before or during publication. Keep unfinished material separate until the group is ready to PRE the release.
Release automation Zipscripts, completion checks, event hooks and category-specific validation. Observe uploads, verify expected files and mark a release complete.
Integrity data SFV files, CRC values and archive/file checks. Detect missing, incomplete or corrupted files during transfer.
Dupe data Local release history and connections to broader dupe or PRE information. Warn that equivalent work may already exist before a duplicate is accepted.
PRE and announce layer Publication command or event, timestamping, announce services and private channel output. Establish the release event and distribute its metadata to eligible participants and services.
Race and credit layer Transfer statistics, weektops, upload credit, ratios and exemptions. Measure contribution and site-specific performance. Not every site weights these systems equally.
Quality control Local nukes, unnukes, nuke reasons and imported status information. Record defects, rule violations and later reversals without physically erasing every copy.
Coordination Private IRC or equivalent channels, sitebots, invitations and status messages. Connect human participants to automated site events.
Security and audit Encrypted connections, network restrictions, compartmentalized permissions, logs and account removal. Limit exposure and contain the effect of a compromised account. Exact present-day measures are not publicly verifiable.

The layers interact rather than operate as isolated products:

server + network + storage
            |
            v
transfer daemon + accounts + sections
            |
            v
release upload + SFV/integrity + dupecheck
            |
            v
completion + PRE + announce
            |
            +--> race / credit statistics
            +--> IRC sitebot and coordination
            +--> nuke / unnuke status
            +--> replication to other eligible sites

Transfer daemon and directory tree

The daemon is the service users connect to, but the visible directory tree is shaped by scripts and permissions. A user may see only selected sections, while an affiliated group can have access to a restricted preparation area and site staff can manage commands and status across the site.

Historically, glFTPd combined a transfer daemon with Scene-oriented commands and scripting hooks. It also maintained local logs used for functions such as dupe searching. Other daemons and private implementations existed, so “topsite” never meant “a glFTPd installation” by definition. The book-derived software history is summarized in Software & tools.

Zipscript and completion logic

Zipscript is a historical umbrella term for server-side routines triggered while release files are uploaded. Depending on the era and section, these routines could:

  • read the SFV and determine which files were expected;
  • verify CRC values and reject or mark damaged files;
  • report missing and completed files;
  • calculate transfer and race statistics;
  • create status markers or update the directory presentation;
  • trigger completion and announce events;
  • apply local section or naming checks.

The name survived even when a release was not literally a ZIP archive. Modern implementations and exact checks are private and category-dependent.

Metadata path versus file path

Release files and release metadata do not need to follow the same route. The payload can move between sites while a smaller announce event is sent to a bot, PRE service or status database.

release files  --> private site replication

release name   --> announce / PRE metadata / status services
timestamp      -->
nuke state     -->

This separation explains how a public pre database can record the existence of a release without possessing or serving its contents.

Security is part of the architecture

Trust is enforced technically as well as socially. Accounts are scoped to roles and sections; private preparation areas protect unfinished releases; channels and sitebots restrict who can observe events; logs make misuse attributable to a handle or account.

At the same time, every additional bot, database connection or cross-site account expands the attack surface. Historical sources repeatedly show the tension between convenience, automation and compartmentalization. Public research can describe that design problem, but it cannot provide a reliable inventory of current site security.

Historical model, not a build guide

Most detailed public descriptions come from historical NFOs, magazines, manuals, court records and Martin Paul Eve's Warez: The Infrastructure and Aesthetics of Piracy. They establish the architecture and vocabulary, not the exact software or configuration of a current site.

What a site does

Function Description
Initial publication Affiliated groups publish completed releases into category-specific areas.
Distribution New releases are replicated across other eligible private sites.
Automation Site scripts track completion, announce releases and expose status information to trusted coordination services.
Validation Releases can be checked for duplicates, missing files, technical defects and rule violations.
Archive Sites retain category-specific collections for their members and affiliates. Retention policies vary.
Local governance Operators decide membership, affiliates, sections and site-specific policy.

A site participates in the network, but it does not command release groups or other sites.

Sections and affiliations

Sites divide content into sections such as games, applications, music or video. Section names and coverage differ between sites.

An affiliate is a release group accepted to publish on a site. Affiliation is a relationship between an independent group and an independent site:

  • the group receives a trusted publication and distribution point;
  • the site receives releases and prestige associated with that group;
  • either side can end the relationship;
  • a group can be affiliated with more than one site.

Affiliation does not make the site the owner or leader of the group.

The release lifecycle

group prepares and checks release
  -> release reaches an affiliated site
  -> PRE establishes its publication event and timestamp
  -> announce and pre services record the metadata
  -> racers and automated tools replicate it to other sites
  -> dupe and rule checks may validate, nuke or later unnuke it

The files and the metadata do not necessarily travel through the same services. A pre database can know that a release exists without hosting its payload.

Site and service roles

Role Function
Site operator / administrator Maintains the site, membership, sections, affiliates and local policy.
Affiliate Release group authorized to publish releases on that site.
Racer / courier Moves releases between sites. Manual racing remains part of Scene vocabulary, although routine transfers and announcements are heavily automated.
Announce service Reports new releases, completion events and site activity to a private coordination channel.
Pre service / database Records release names, timestamps, categories, groups and later status changes.
Nuker / validator Applies a documented status when a release is duplicated, broken or non-compliant.
Ruleset signatory A group participating in category standards. This is not a permanent site administrator or global Scene official.

The same person can perform more than one role, and terminology varies between communities and periods.

Coordination and automation

Private IRC channels and automated bots are well documented parts of Scene infrastructure. Bots historically announced uploads, completed releases, races, nukes and site statistics. Scholarly work published in 2021 still describes IRC, bouncer and command systems as core parts of the documented infrastructure.

It is not possible to verify publicly that every current group or site uses the same communication platform. The durable concept is the separation between:

  • a private coordination channel;
  • automated announce and status services;
  • the site that stores the release;
  • external pre databases that retain metadata.

Automation has reduced the importance of a dedicated full-time courier. Speed still matters, but scripts and linked services now handle much of the repetitive coordination once performed manually.

Credits and ratios

Credits and ratios are longstanding site mechanisms, not a universal Scene-wide economy.

Concept Meaning
Upload credit A site can reward data contributed to a section.
Ratio A site-specific relationship between uploaded and downloaded data.
Exempt account Site staff or affiliated groups can be exempt from ordinary ratio requirements.
Race statistics Rankings can measure speed, volume or completion, depending on the site.

Some sites and eras emphasized ratio scores heavily; others emphasized affiliation, role, trust or contribution. A credit balance has no authority outside the site that issued it.

PRE and pre databases

PRE is the publication event that marks a finished release as available within the Scene. Its timestamp is important because many category rules use chronological order to decide who won a race or whether a later release is a duplicate.

A pre database normally stores metadata such as:

  • release directory name;
  • pre time;
  • category or section;
  • release group;
  • nuke, unnuke or other status;
  • occasional reason or correction information.

Pre databases are indexes, not necessarily file archives. Public sites can mirror leaked pre metadata, but access to such a mirror does not make someone a Scene member.

Pre data is also not infallible. Current GAMEiSO rules explicitly account for situations where presites or prebots report ambiguous timing.

Nukes, unnukes and replacements

A nuke marks a release as invalid or defective under a ruleset or site policy. It does not automatically erase every copy.

Status Meaning
Technical nuke Missing or corrupt files, broken media, a bad crack, invalid packaging or another functional defect.
Rules nuke Naming, source, format, proof or another category-rule violation.
Dupe nuke Equivalent content was already validly released.
Local nuke A decision that applies only to one site or its policy.
Network-wide or “global” nuke A status propagated broadly because the underlying release itself is considered invalid. It is shared consensus, not an order from a central authority.
Unnuke Reversal of a previous nuke when the reason was wrong or the release is shown to be valid.

Follow-up tags have distinct purposes:

  • PROPER — another group replaces a technically flawed release;
  • REPACK or RERIP — the original group issues a corrected package or rip;
  • NFOFIX, DIRFIX, SAMPLEFIX or PROOFFIX — fixes a specific supporting component where the category permits it;
  • READNFO — directs attention to important context, but is not itself a repair.

See Tags and terminology for the broader status vocabulary.

Sites versus public distribution

Scene sites are not public seedboxes. A Scene release can later appear on:

  • private or public torrent trackers;
  • Usenet;
  • XDCC networks;
  • direct-download services;
  • streaming portals.

That transition is a leak or downstream redistribution, not the next official stage managed by the originating group. Public uploaders may preserve the original directory, extract it, rename it or build a new repack.

What changed from the classic topsite model?

Classic emphasis More relevant interpretation today
Manual courier chains Automated replication, announce tooling and metadata services handle much of the routine flow.
Ratios define every member Access, affiliation, technical work, trust and site-specific policy can matter more than a universal ratio model.
Physical pre-release media dominates WEB sources and digital delivery are central to many current categories, while retail supply remains relevant elsewhere.
PRE databases are part of one central system Multiple services can record or mirror pre data and can occasionally disagree.
A “global nuke” comes from a Scene authority Status spreads through shared rules and services without a single global administrator.
Public piracy is the bottom of the same organization P2P, DDL, Usenet and streaming are separate ecosystems receiving leaked material.

Limits of public knowledge

Current rules provide strong evidence for PRE timing, dupe bots, scanned sites, nukes and distributed group signatories. Public investigations confirm internationally distributed server infrastructure. They do not reveal a complete live map of current sites, participants or communication systems.

Sources & references

For the relationship between release groups, infrastructure and public networks, see The scene hierarchy.