A publisher choosing between hidden-service-only and clearnet visibility is not choosing between invisible and visible. A Tor onion address can be advertised worldwide and open to anyone who knows it. An ordinary HTTPS site can place its protected content behind authentication, while its domain, login page, or leaked URLs may still appear in search results. Visibility is the combined result of network reach, address distribution, indexing, authentication, and the publisher’s own promotion.

The useful decision is therefore not “Do we want people to find us?” Every publication needs some discovery path. The decision is which audiences should reach which edition, through which intermediaries, with which privacy assumptions, and at what operational cost.

Three common visibility models

Hidden-service-only means the publication is available natively through Tor, I2P, or both, without an ordinary public-web edition or clearnet proxy. Readers must use the relevant network software and obtain a valid onion address or I2P Destination. This model keeps the audience relationship centered inside privacy networks and avoids creating a conventional DNS and web-hosting route merely for convenience.

Hidden-only does not mean undiscoverable. A publisher can announce an address through trusted directories, address-book publishers, established profiles, mailing lists, print, partner sites, or direct messages. It also does not mean private. A public onion service is normally open to anyone who has the address, and an I2P Destination can be redistributed. When access must be restricted, the project needs authentication—such as Tor onion-service client authorization or an application login—not hope that the address stays obscure.

Dual publishing means maintaining a native hidden-service endpoint and an ordinary clearnet edition. The editions may share an application, draw from the same publishing system, or be operated separately. This model lowers the adoption barrier for readers who do not use Tor or I2P and gives privacy-network users a native route. A clearnet site can also advertise its onion counterpart with Tor’s Onion-Location mechanism, helping Tor Browser users switch intentionally.

Dual publishing expands the system. It adds DNS, certificate, edge or hosting dependencies, another monitoring route, more logs, and more opportunities for content or configuration to drift. If both editions reveal the same organization, correlation may be acceptable and even desirable. If the publisher is trying to keep identities or infrastructures separate, synchronized content, timestamps, headers, analytics, error pages, and administrative habits require a more careful review.

Opt-in bridging or proxy exposure leaves the native hidden service as the source while a separate service provides selected clearnet access or discovery. This can broaden reach without making ordinary public exposure the default for every project. The bridge is an intermediary: visitors interact with it, and its privacy, caching, logging, content-handling, and abuse processes matter. A clearnet gateway does not give a conventional browser all the protections of a native I2P or Tor client.

The Darknet Proxy visibility guide documents its role as an optional discovery, access, and promotion layer in the Invisible-Internet ecosystem. It is separate from hidden-service hosting and should be enabled by publisher choice. That separation allows a project to begin hidden-only and add broader discovery later instead of treating clearnet exposure as irreversible default infrastructure. For a fuller analysis, see Discovery Without Default Exposure: Directories, Proxies, and Opt-In Promotion.

Discovery and access control solve different problems

Discovery answers, “How does an intended reader learn a valid address?” Access control answers, “What must that reader prove before the service responds?” Mixing those questions produces fragile systems.

Search-engine indexing is one discovery mechanism for the clearnet. Publishers can use crawlable links and metadata to invite it or a noindex directive to ask cooperative search engines not to list a page. That directive is not a security boundary. A crawler must fetch the page to see it, other crawlers may ignore it, and anyone with the URL may still connect. Authentication or network restriction is required for private material.

Tor onion services use self-authenticating addresses outside ordinary DNS. Publishers can distribute those addresses directly, through reputable directories, or from an authenticated clearnet property. Tor’s Onion-Location header or HTML metadata lets an HTTPS site declare its onion counterpart to Tor Browser. Client authorization adds a separate credential requirement when merely knowing the address should not be enough.

I2P separates cryptographic Destinations from human-readable local names. Readers can add a Destination directly or learn mappings through chosen address-book subscriptions and jump services. There is no central naming authority guaranteeing that every reader resolves a human-readable name identically. An I2P publishing plan should therefore specify both the memorable name and a verifiable underlying Destination.

Directories and proxies can make addresses easier to find, but they also introduce curation, trust, and complaint-handling relationships. A publisher should understand listing policies and how corrections or removals work. A directory listing is promotion, not ownership of the service identity; a proxy view is access through an intermediary, not the native route.

Each additional route changes operations and exposure

A dual-published site can use one backend with multiple front doors. That is easier to update consistently, but a mistake or outage can affect every edition, and identical application behavior can make the relationship obvious. Separate deployments create stronger operational separation and potentially better failure isolation, but they cost more to patch, monitor, synchronize, and recover. The right choice follows the threat model.

Clearnet exposure also introduces ordinary Internet metadata and infrastructure relationships. DNS queries, certificate issuance, edge providers, public IP handling, browser third parties, and conventional analytics may all become relevant depending on the design. A reverse proxy can reduce direct origin exposure for web traffic, but provider documentation is explicit that an origin may still be discoverable through unproxied records, historical data, mail services, or other leaks. “Behind a proxy” is a control, not a guarantee of invisibility.

The hidden edition has its own operational signals. Tor Project guidance notes that service availability and web-server behavior may reveal information to an observer. I2P publishers must manage tunnel uptime and Destination distribution. Running both networks can add resilience only if failures are sufficiently independent and operators can maintain both. Two routes pointing at one unbacked-up database are not two resilient publications.

Support and moderation must follow every public route. Readers need a way to report broken addresses, impersonation, abuse, or content concerns without forcing the publisher to reveal private contact details unnecessarily. The service operator needs a documented response path. Privacy-oriented publishing works better when complaints are routed through process rather than sent indiscriminately to upstream providers.

Consider the audience burden too. Hidden-only readers must install or configure appropriate software. Clearnet readers gain convenience but may arrive with different privacy expectations. A bridge may be useful for evaluation and discovery while native addresses remain clearly labeled as the privacy-network routes. Explain the difference instead of allowing visitors to assume that all front doors provide identical protections.

Practical Takeaway

Write a one-page visibility decision before deployment:

  1. Audience: Name the people who need native Tor, native I2P, ordinary web access, or a temporary bridge.
  2. Publication identity: State whether all editions are intentionally linked or whether separation is a requirement.
  3. Discovery: List the authenticated announcements, directories, address books, partner links, or search channels that will distribute each address.
  4. Access control: Decide whether each route is public to anyone with the address, protected by an application account, or restricted with network-level credentials.
  5. Infrastructure: Record whether routes share a backend, database, logs, analytics, media store, and administration path.
  6. Intermediaries: Document what a proxy, directory, DNS provider, certificate authority, or edge service can observe and what policies it applies.
  7. Operations: Assign updates, monitoring, backups, recovery, corrections, and complaint intake for every route.
  8. Exit plan: Explain how a clearnet edition or bridge can be retired without losing the native service identity or confusing readers.

Start with the smallest model that serves the real audience. Add clearnet reach when its benefits justify the additional dependencies and exposure; add a bridge when readers understand the intermediary; and remain hidden-only when that is a deliberate community and risk choice. Whatever the model, publish accurate expectations: an address can be widely visible without revealing a conventional destination, and a route can be difficult to discover without being private.

Sources and Further Reading