Sascha's Toolbox

The Tag That Shouldn't Work: Platform Fragmentation and the 144-Byte Payload

The Tag That Shouldn't Work: Platform Fragmentation and the 144-Byte Payload

A digital ecosystem is defined by where its gatekeepers choose to place friction.

Consider the NTAG213. It is a blank NFC sticker, roughly 6mm across, consisting of an antenna coil and a microscopic silicon die. It costs a few cents at volume. It holds exactly 144 bytes of user-writable memory. In the context of modern infrastructure, 144 bytes is nothing—barely enough space for an HTTP request header. Yet, in the physical world, it is enough to entirely redefine the operational flow of a hardware system.

Elegoo’s Centauri Carbon 2 3D printer reads one of these NTAG213 stickers on every spool it loads. In a fraction of a second, the printer ingests the material type, color, optimal print temperature, and filament family, configuring its hardware parameters automatically. The tag format is proprietary. Elegoo does not publish the specification.

And yet, you can write these tags from a web browser.

The project is called AnySpool (anyspool.de)—a reverse-engineered NFC tag writer that operates entirely client-side. But this is not a product announcement or a triumph of independent development. It is a functional workaround that exposes a much more interesting systemic reality. When you attempt to bridge commodity hardware with open web standards, you inevitably collide with the administrative and political boundaries of platform monopolies.

The Payload Problem

To understand the friction, you must first understand the mechanism. The NTAG213 format is well-documented, organizing its 144 bytes of user memory into 36 pages of 4 bytes each. Elegoo’s specific implementation ignores standard NDEF (NFC Data Exchange Format) records, opting instead for a raw, 96-byte custom payload.

Reverse-engineering this payload from genuine spools revealed a rigid hex structure. The data block contains a 4-byte hex string defining the material type, a 2-byte subtype identifier, a filament family code, and a color modifier byte. Modifying a spool’s intended hotend temperature or retraction speed does not require interacting with the printer’s firmware; it only requires mapping the correct hex values to the correct memory pages on the sticker.

Writing this payload to a tag via the web should be trivial. The W3C Web NFC API is a mature specification. On Android, using Chrome, the implementation is remarkably clean. A JavaScript call to NDEFReader.write() or issuing raw commands via the API requests user permission, activates the device’s NFC radio, and commits the payload. One API call, one physical tag, one seamless interaction. It is a textbook example of how the web can interface with physical infrastructure.

For edge cases or complex formatting, you construct an array of raw A2 (Write) commands, pass them through the interface, and the silicon handles the rest. It works.

Apple’s WebKit Moat and the Browser Fragmentation Tax

If the technology is standard, and the silicon is capable, the failure state must be administrative. This brings us to iOS.

On an iPhone, none of this web-based NFC functionality exists. This is not a hardware constraint. Apple has shipped NFC chips in iPhones since the iPhone 6, and iOS 11 introduced Core NFC, allowing native iOS applications to read and write tags with high reliability. The hardware is exceptionally capable, and Apple markets it heavily for Apple Pay, Wallet passes, and AirTag tracking.

The limitation is entirely policy-driven. Under App Store Review Guideline 2.5.6, Apple has historically forced all third-party browsers on iOS to use its proprietary WebKit rendering engine and JavaScript Core. When you install Google Chrome or Mozilla Firefox on an iPhone, you are not installing the Blink or Gecko engines; you are installing a custom UI skin over Apple’s WebKit.

Because Apple dictates WebKit’s feature roadmap, and because Apple has chosen not to implement the Web NFC API (or WebUSB, WebBluetooth, or WebSerial), these APIs are dead on arrival for iOS web users.

This is the Browser Fragmentation Tax. It is a structural advantage designed to force developers out of the open web and into the App Store, where Apple commands a 30% revenue share and absolute editorial control over software distribution.

The European Union recognized this anti-competitive bottleneck. The Digital Markets Act (DMA), which went into effect in early 2024, explicitly named Apple as a gatekeeper and mandated browser engine choice on iOS within the EU. In theory, this meant Google could ship the true Blink engine on iOS, bringing Web NFC and other hardware APIs with it.

In practice, we witnessed a masterclass in compliance theater. Apple announced support for alternative browser engines, but attached a web of administrative constraints. The alternative engines are restricted to the EU. Developers must meet complex entitlement requests. Most critically, to qualify, a browser developer must demonstrate a threshold of 1 million average monthly users over the prior 12 months, or be an established entity.

The practical effect of this policy is that the barrier to entry is high enough to prevent any meaningful, agile independent browser engine from shipping on iOS. Apple achieved technical compliance with the DMA while preserving the exact structural advantage the legislation was intended to dismantle.

The downstream consequence for developers and users is a two-tier implementation reality. On Android, you build a web app once, and it interacts with the physical world. On iOS, you are forced into an architectural compromise: either absorb the Total Cost of Ownership (TCO) of maintaining a native Swift app, or ship a degraded web experience and explain to users why their £1,200 device cannot execute a standard W3C API that a £180 Android phone manages effortlessly.

For AnySpool, the iOS path is a brutal concession to this reality. The web app generates a raw hex command string. The user must manually copy this string to their clipboard, open a third-party native iOS app called NFC Tools, navigate to an advanced menu, paste the payload, and execute the write command.

It works. It is entirely functional. But it is profoundly inelegant. The inelegance is not a failure of the developer; it is the direct manifestation of a platform policy that the EU attempted to address, and which Apple successfully blunted.

What a Commoditized Supply Chain Makes Possible

The reason a project like AnySpool can exist at all is that the underlying hardware supply chain is completely commoditized. NTAG213 stickers ship directly from manufacturers in Shenzhen for roughly €0.04 per unit.

Elegoo’s decision to build an ecosystem feature on top of this format is a prime example of an architectural mismatch. They attempted to create a walled garden using a standard, globally available, off-the-shelf component.

History provides ample evidence that proprietary formats deployed on commodity hardware serve only as a temporary moat. The moment a motivated actor reverse-engineers the payload format, the hardware lock evaporates. This is the exact dynamic that unraveled Keurig’s K-Cup DRM, HP’s ink cartridge authentication chips, and countless other attempts to enforce artificial scarcity through unencrypted silicon. Elegoo’s NFC implementation was always going to be mapped; the only variable was the timeline.

If you do not utilize cryptographic signing—if you rely purely on the obscurity of a hex structure—your moat is an illusion.

What AnySpool Actually Is (and Isn’t)

As a piece of software, AnySpool is highly constrained and deliberately narrow. It does one thing: it generates the correct 96-byte payload to allow a cheap sticker to configure an Elegoo printer.

It contains a catalog covering Elegoo’s filament range, translates those selections into the necessary hex blocks, and exposes the Web NFC API where available. It operates entirely in the browser. There is no backend infrastructure, no user authentication, and no data collection. The architecture is explicitly designed to minimize maintenance overhead and liability.

It is also inherently imperfect. The iOS experience, as detailed, is an administrative workaround rather than an engineering solution. Furthermore, because Elegoo does not publish their internal pigment data, the hex codes representing the filament color swatches are approximations.

Even the data sourcing revealed the brittleness of undocumented systems. Building the German localization for the tool required constructing a manual translation table, because the API endpoints for Elegoo’s regional storefronts serve product variants in entirely different structures. The API for the .de store does not mirror the .com store; it is a fragmented system likely built by different contracting teams at different times.

These are the honest limitations of interacting with closed systems. You are not building an integration; you are building an adapter for someone else’s technical debt.

The Pragmatic Pivot: The 144-Byte Reality

Return to the NTAG213. 144 bytes of silicon.

The physical tag does not care about browser engine politics. It does not care about Apple’s App Store Review Guidelines, and it is entirely indifferent to the EU’s Digital Markets Act. It holds 96 bytes of structured data, and it works flawlessly in any NFC-capable hardware that possesses the logic to read it.

The brittleness of this entire ecosystem exists purely above the hardware layer. It is found in the administrative decisions to obscure payload structures, and in the regulatory evasion that prevents a modern mobile browser from communicating with a standard radio frequency.

As the European Commission continues to develop enforcement mechanisms and non-compliance investigations against platform gatekeepers, we must ask a broader infrastructure question: How many other capable, fully-specified web APIs—from local network discovery to hardware serial interfaces—are sitting in the same position? How much utility is effectively blocked on iOS by a business policy dressed as a technical constraint?

AnySpool is a small answer to a highly specific, low-stakes problem. But the regulatory and corporate forces that made the problem exist in the first place are shaping the boundaries of the entire connected world. When we tolerate artificial friction at the platform layer, we permanently limit the agency we have over the hardware we supposedly own.

The architectural breakdown, feature scope, and source references for this deployment are documented in the AnySpool Project Notes.

← Back to all posts