I'm building a parallel internet, and it's called The Thinnernet
A proposal for a “parallel internet” called The Thinnernet argues for a lightweight, latency-conscious alternative to today’s bloated, ad- and tracker-heavy web, drawing inspiration from efficient early smartphone platforms and “lite” app modes. Commenters question whether this is truly a new network or simply a call for leaner websites and apps, probing how it would be implemented in practice, how carriers or QoS would be involved, and whether any new stack can overcome network effects. The exchange branches into comparisons with projects like Gemini, Gopher, Reticulum, and Internet2, and into a broader debate over whether the future should prioritize minimal, text-centric experiences or rich, highly interactive applications.
Scope and Vision of “Thinnernet”
- Not a new physical internet or low‑level protocol; positioned as a parallel, “bike‑lane” style virtual network on top of existing infrastructure.
- Focus is on lightweight, predictable experiences for common tasks (news, mail, appointments, etc.), emphasizing latency bounds and efficiency.
- Relies on existing tech (e.g., QUIC over UDP, QoS, “lite” app modes) and coordinated design across device, OS, ISP, and server.
- Core idea: developers and platforms intentionally offer low‑data, fast modes as first‑class citizens.
Confusion and Skepticism
- Several commenters say the proposal is unclear: Is it a protocol, a physical network, QoS regime, or just a design ethos?
- Some note that metaphors about undersea cables and “parallel internet” blur, rather than clarify, scope.
- Others think it boils down to “efficient websites and apps,” not a genuinely separate network.
- Doubts about feasibility: coordination and discipline across ISPs, device makers, and app developers are seen as unlikely.
Web Bloat, Efficiency, and Business Models
- Strong agreement that web bloat and slow sites (especially on poor connections) are real problems.
- Many point to ads, tracking, analytics, and marketing as primary drivers of bloat, not inherent technical needs.
- Suggested mitigations: adblocking, size‑limited site “clubs,” low‑bandwidth fallbacks, “basic web” modes, and voluntary developer guidelines.
- Tension: some want aggressively small pages; others insist modern use cases (rich apps, 4K video) must remain possible.
Alternative Protocols and Minimalist Webs
- Interest in text‑centric, anti‑commercial, browser‑light ecosystems: Gemini, Gopher, Hyphanet/Freenet, Reticulum, mesh/LORA experiments, Arcan‑net, BBS/SSH communities, SmolNet/Yesterweb.
- Acknowledged issues: lack of content, poor discoverability, network‑effect disadvantages, and limited application scope.
- Some see these spaces as welcome refuges from tracking and monetization, even if niche.
Design Philosophies and Governance
- Pushback against framing ideas as “what a famous tech figure would have done”; viewed as cliché and a weak argument.
- Debate over opinionated, vertically integrated design vs. design‑by‑committee and open, forkable ecosystems.
- A referenced set of criteria for “HTML replacement” (open, neutral, powerful, easily monetized) is widely criticized as unrealistic, internally conflicting, or undesirable—especially the monetization focus.