Better Internet

The World Wide Web is constantly undergoing a restless campaign of enshittification; worse design choices, worse maintenance, worse technical implementations, etc. Web pages, for example, were designed to be 85% of content worth reading, 10% HTML and 5% CSS. Nowadays, millions of jobs are having a seemingly endless competition to output text in the most inefficient ways (only for them to be replaced by LLMs):

On the other hand, if we come to analyze the core technology that powers the modern web (as in, the set of technologies that comprise this platform, such HTTP, HTML, CSS, JavaScript, etc.), we quickly realize that the "clearnet" is built on a fundamentally centralized infrastructure; at its core, the conventional internet framework is the backbone of the web, and it relies on a hierarchical and bureaucratic system that enforces control at multiple levels, such as:

Another issue is the web client monopolization; where Google's Blink and Mozilla's Gecko dominate the browser market, shaping web standards and phasing out features that don't align with corporate interests. I have yet to be convinced that any Chromium or Firefox fork offers any meaningful value proposition over providing a sense of privacy by simply ticking off telemetry in the settings (LibreWolf and Mullvad Browser), prioritizing customizability and usability over privacy (Zen and Floorp), being a closed-source crypto-shilling honeypot (Brave), or being unusable in the "modern web" (Pale Moon, GNU IceCat, QuteBrowser). Other independent browsers (Surf, BadWolf) lack necessary features and are resource-heavy sometimes due to the dependency on bloated frameworks (e.g., WebKitGTK+), and terminal browsers are literally useless beyond file manager previewing and printing HTML to standard output. The only remaining hope is Ladybird, a promising browser because of the reputation that SerenityOS earned it, though there's a bunch of orange flags on the project itself (e.g., being sponsorized by ProtonVPN and PCH, and having ties to IBM and Quad9), so it's out of the question that the software will be milked in some way, especially considering that it's licensed under a permissive license (the BSD 2-Clause License) allowing proprietary forks.

Despite the many occasional attempts at concocting solutions by making "decentralized networks," the vast majority of internet activity still occurs within this centralized framework (even for protocols such as SMTP, IMAP, IRC, XMPP, FTP, RSS, NNTP, etc., which are much better solutions than the modern web infrastructure, regardless of their pros and cons, as they gave out a protocol for every use-case, and you could use your own client with an interface you like in whatever way suits you instead of being dictated). Most of the proposed networking solutions (e.g., Tor or I2P) also fail due to both user adoption issues and fundamental design flaws.

This article will provide a reimagination of the most important aspects of the web as an attempt to make a roadmap towards a seemingly perfect solution, rather than ignoring the fact that shitty technology exists and doing nothing about it in the name of the "proliferating standards." Surely, Software Alternatives Are Harmful, but when it's impossible to "improve" a certain kind of software due to how shitty it is, then it's much better to move on.

How shitty standards stick around.

Inappropriate application of xkcd #927: Standards.

It will touch the following points:

Networking ~

The usage of anonymous networks is the only way to anonymize IP addresses while continuing to use them. They can't simply be cut out unless people:

  1. Create mesh networks to connect one device to another, wired or wirelessly (which is low range and requires population density).
  2. Join black market ISPs (which isn't a practical idea since fiber cables are expensive and heavily regulated by the government).
  3. Acquire ham radios in every household (which is extremely slow if not military-grade technology and also heavily regulated by the government for some reason, but what isn't?).
  4. Manage to overthrow governmental entities somehow and take over already existing physical infrastructure (such as cell towers) to repurpose it to their advantage.

This is because the "botnet" is not only software, but rather also physical infrastructure, social groupthink, and legal framework. Unless we restructure society as a whole, all we can do is simply apply bandages, the same way encryption is a bandage (since governments already have quantum computing).

The proposed "band-aid" solution should serve to be an anonymizing overlay network whose data is encrypted and transmitted from one peer to another through a dynamic and smartly randomized multitude of volunteer-maintained nodes, each of which is a participating user in the network. Each node is identified in the network database by a unique cryptographic identity derived from a public/private key pair, which is used to encrypt and decrypt data, verify it, and prove authenticity, all without relying on IP-based identification. Node selection is determined by historical performance, with nodes assigned different priorities based on efficiency, balancing both anonymity and speed in an optimal way. The closest protocol which embodies this idea is I2P.

Although the proposed solution solves the "IP address" problem, it requires the contribution of a handful of volunteers to run nodes in the network in order to be functional, otherwise, it would be unbearably slow. This is a problem, however, because adoption is a huge issue in terms of feasibility; people aren't tech-savvy enough to understand data transmission, let alone how their own computers work. Embedding an alternative protocol directly into consumer hardware is also impossible, not only because of the corporate stranglehold over firmware and manufacturing pipelines, but also because it defeats the entire point, which is that only people who understand how computers work should be using them in the first place (and for that reason, Gatekeeping Is Essential for the Survival of Communities). Hence, the only way to propagate the usage of the protocol is to focus on the growth of the competent minority who actually care to understand technology and how things work. Widespread adoption under the current circumstances is neither realistic nor idealistic, as anything that becomes too "popular" amongst a society largely compromised of idiots inevitably invites infiltration, dilution, and mass exploitation by other idiots of the same caliber, as I noted before.

Anyhow, coming back to the protocol specifications. To get rid of monopolization (such as the one on the clearnet regarding site domain names), discoverablity of content on the proposed solution would be decentralized; every piece of data is identified by a random cryptographic hash. Discoverability in the protocol is up to the people willing to distribute hashes for people to save (through mediums like manual exchange, search indexes, forums, trackers, etc.), and it's not managed by the protocol itself. Moreover, data distribution relies on the decentralized (i.e., peer-to-peer) model, where any device (or server) with access to specific data chunk can help distribute it if both the senders and recipients are online. This approach mirrors the underlying mechanics of torrenting, in which files are split into smaller parts (chunks), and these parts are shared simultaneously by multiple peers to maximize distribution efficiency and reduce reliance on any central server. Additionally, users can optionally assign one or more dedicated nodes to act as persistent hosts for data, which allows greater reliability and uptime, even when recipient peers are intermittently offline.

Rather than relying on a monolithic "web browser" as a universal access point, each type of interaction on the protocol (e.g., websites, textual or verbal communication, file distribution, video streaming, social presence, multiplayer gaming, etc.), which are listed below, can be handled by specialized clients which may fetch static files, maintain live connections, or handle real-time data streams, depending on the use case.

File Transfer ~

The file transfer layer should be fully decentralized and operate on a trustless, peer-to-peer swarm model (akin to a fully anonymized iteration of BitTorrent). Any participant in the network should be able to "seed" any file, provided they possess the relevant chunks, and there is no requirement for an authoritative central host.

When a client requests a file (by its cryptographic hash), it queries the overlay network for peers currently advertising pieces of that content. The file is split into uniformly sized encrypted chunks, which are distributed across the swarm and reassembled client-side. As downloads occur, the client may simultaneously upload the same chunks to other peers, allowing distribution to scale naturally with demand.

Because the network routing inherently obfuscates the origin and destination of data through multi-hop encrypted tunnels (akin to I2P's "garlic routing"), the swarm does not expose the origin or destination of the data in plain form. A file remains available as long as at least one complete copy of its chunks exists somewhere in the network, whether on transient peers or on optional dedicated seed nodes maintained for persistence.

Discoverability ~

Discoverability is claimed by the community; users maintain and distribute file repositories, indexers/trackers, search indexes, and "webrings."

Metadata ~

Files are an immutable truth; community context is subjective. Therefore, metadata (e.g., comments, ratings, organizational tags, and content filtering) is never baked into the host file. It exists as an independently distributed sidecar. Clients can choose to fetch and overlay this data, entirely divorcing the raw information from public commentary.

Direct Connection ~

A direct connection layer should exist for cases where a user wants a private interactive session with a remote machine, not a publish/subscribe model. SSH is the clearest example; an encrypted connection for administration, maintenance, and remote shell access. In the proposed network, this kind of session should be treated as a first-class transport mode rather than a special exception.

Unlike file transfer, a direct connection is stateful and latency-sensitive. It requires stable routing, authentication, and enough continuity for interactive input and output to remain usable. The protocol should therefore support ephemeral session channels that can carry shell traffic, port forwarding, remote command execution, and other administrative tasks without exposing the underlying machine directly to the public internet.

This layer isn't about publishing content, but it's about reaching a specific host, proving identity, and maintaining a secure private channel for whoever is authorized to use it. That makes it useful for infrastructure operators, system maintainers, and anyone who needs remote access without surrendering control to a centralized service.

Ecosystem ~

Once the network layer, file transfer layer, and direct connection layer exist, the rest of the ecosystem becomes a matter of specialized clients built on top of the same transport. Different kinds of content demand different protocol implementations while sharing the same infrastructure underneath; personal websites, distributed version control systems (like Git), forums, imageboards, email, instant messaging, audio-visual communication, real-time video synchronization (like CyTube and Syncplay), document collaboration, etc. While the "Better Software" standards apply for these programs, below are some extra comments for the client implementations.

Personal Websites ~

Personal websites should focused solely on the content, like RSS feeds. They must be stripped down to purely semantic, structural formats (e.g., a strict unstyled HTML, raw Markdown, text documents based on the Gopher/Gemini protocol, etc.). These files would be fetched from the swarm and rendered locally through a "document viewer" client rather than a "web browser." By relying entirely on structural markup rather than visual styling, the data remains pure, universally legible, and completely divorced from the author's arbitrary design preferences.

The very existence of CSS is harmful, too. Authors should never have been given control of style because it doesn't concern them as writers, rather, it should be the responsibility of the client. While some people know about "user stylesheets," a feature the web was supposed to have where users could have their own stylesheets that would be applied to pages they view, the feature is often obscured in directories like ~/.mozilla/ (or requires the installation of third-party extensions like Stylus). This is because it could never have worked in a platform not designed for it. That CSS is available to page authors means page authors will write it and will expect theirs to be honored, and will edit the HTML according to that. However, their styles will conflict with user styles in the HTML, and there's no way to ensure the result will be coherent and won't interfere with the usability of the page.

User stylesheets are how things always should've worked, but they can't when author stylesheets are part of the expectations of the platform.

Instant Messaging ~

Upon launching the client and starting a new session, the content list is empty. The user is expected to add a new contact by sending a temporarily generated (ephemeral) "invite ID" to the other peer, since the protocol is mainly identity-less to avoid the problem of metadata. After the other peer accepts, a sort of "tunnel" is created and both peers can exchange plain text messages. Tunnels are confidential, they contain all data and messages, and can be exported to other sessions and other devices. Transmission of data is peer-to-peer, and the protocol is extensible in a similar vein to XMPP.

Important extensions for this "peer-to-peer" and "identityless" protocol include; "bouncers" (for the assignment of third-party bouncers that store messages until the receiver comes online), "hosters" (for the assignment of third-party hosters that store messages indefinitely), and "identities" (for the assignment of an identity ID or more to the user, which is a random unique cryptographic hash that other users can use to directly connect and create tunnels with the user, and can be exported).

There's also the usual extensions from XMPP (MUCs, encryption, attachments, avatars, reactions, stickers, etc.), of course. Moderation on multi-user chats takes a whole new concept as well (see: Against Moderation).