Irys (✧ᴗ✧) (@irys_xyz): Dev Update #1: The Read Layer, Hardened

Dev Update #1: The Read Layer, Hardened The first in a series. We are going to publish these regularly. The plan is that, over time, they accumulate into something useful for our partners. This week we separated Irys's read layer onto its own domains, rolled out per-transaction subdomains for web content, and made phishing detection a first-class part of the service. This post explains what we shipped, why we shipped it the way we did, and where the read layer is going next. Some context first. If you have built on Irys in the last couple of years, you have probably interacted with three things: the bundler, the gateway, and the CDN. You uploaded data through the bundler, queried it through the gateway, and served it on the web through the CDN. All three lived behind the same domain, irys.xyz, and most of the time that was fine. Over the last several months, the volume of adversarial activity grew faster than the read layer was built to handle. The most visible version has been phishing sites hosted through our CDN. As illicit content increased, irys.xyz started showing up on blacklists, which created reputation problems that reached further into the rest of the stack than they should have. The right answer was to harden it. So we did. What changed today The CDN now lives on its own domains, not on irys.xyz. We have rolled out four new domains for CDN traffic: datachaincdn.com, dataspritecdn.com, datachain-cdn.com, and datasprite-cdn.com. The Irys homepage, the docs, and the bundler are no longer downstream of CDN reputation problems. Web content is now served from per-transaction subdomains. The old format was path-based: node.irys.xyz/<transaction-id>. The new format puts the transaction ID in the subdomain: <sandbox-id>.node.<newdomain>.com/<transaction-id>. This makes static site deployment cleaner and gives every site its own browser security boundary (“sandbox”). Phishing detection and abuse response are now first-class. The detection pipeline has been substantially improved, and reports sent to abuse@irys.xyz are now handled as part of the service. The intent is to reduce the number of cases where bad content gets served at all, and to react faster when it does. For builders, the practical implication is small. Keep using gateway.irys.xyz/<transaction-id> - these read-layer paths are mapped automatically to a healthy new CDN domain. Your apps still work. If you are deploying static sites, you will benefit from the subdomain change. We may rotate or expand the CDN domain set over time, and if we do, we will announce it in our Discord. Otherwise, things should feel quieter and more reliable. That is the goal. Why subdomains, specifically The practical reason is that static site frameworks assume a known base path at build time. Most of them want the root directory, or some other fixed location they can compile against. Under the path-based model, the base path could not be known until after the transaction was signed and uploaded, which meant developers were doing awkward post-hoc rewrites or accepting build-time hacks that should not have been necessary. Putting the transaction ID in the subdomain instead of the path gives developers a stable base path to target. The structural reason is browser security. Under the old model, every static site served through the gateway effectively shared an origin. That meant they shared the same browser security sandbox. A vulnerability in one site could, in principle, reach across to another. We did not observe attacks that exploited this, but the architecture left open a class of risks that should not exist in the first place. Under the new model, each static site gets its own subdomain, which means each one gets its own browser security boundary. Cross-site scripting between sites served on Irys is no longer architecturally possible. That is a much stronger default and a much better foundation for the kinds of apps that builders are starting to deploy on us. Even with these changes, the bundler, gateway, and CDN are still tightly coupled. Fixing that is the bigger work, and it is what the next section is about What we are building next We are in the process of building four data services. Each one is designed to improve a specific part of the experience on Irys and to make the network more reliable as it grows. The CDN service does one thing: serves Irys content on the web safely. It owns the browser sandbox, the phishing detection, and the abuse response. The changes we shipped this week are the start of what this service should look like. The gateway service is what you use when you want to search for or retrieve specific data on Irys. It should be self-hostable. If a team wants to run their own gateway because they care about availability, latency, or independence, they should be able to. And if they want to serve their own application's web content from Irys, they should be able to run a CDN sidecar alongside their gateway. The bundling service handles writes. Its job is to accept data, bundle it, and submit it to the network reliably under any condition. It should be insulated from what is happening on the read side. Part of this week's work was making sure the bundler stops inheriting reputation problems from the CDN. The fetch service, as it is tentatively called, is new, and the work is in early stages. The idea is a service that returns the raw bytes of any transaction to a requester who can supply a valid signed request. No browser rendering, no public web exposure, no general-purpose CDN behavior. Just verified file delivery to authorized parties. Because it never serves browser-rendered content, the surface area for phishing and web abuse drops to almost nothing, which means it should be highly resistant to the blacklisting problems that triggered this week's work in the first place. We expect this to become the most reliable hosted way to retrieve data from Irys, short of running your own node. Each of these will ship and harden on its own timeline. What you should do If you are an existing builder: nothing urgent. Your existing links keep working, your existing apps keep working. You can keep using gateway.irys.xyz/<transaction-id> links as usual. If you run into anything weird as the new domains roll out, tell us. If you are evaluating Irys: this is what we mean when we talk about hardening. A continuous reshaping of the operational layer in response to what we learn from running the network. Dev updates like this one will be where we tell that story as it happens. More to come.