zzem

This is soo cool. I've also came up with and been exploring this concept, as a side interest, on and off from 2017 - it is the thing that got me originally interested in SynBio. So happy that it finally got an "official" name and recognition. It is the next major thing to happen after AI.

The DNS name resolution is actually not done by your system or ISP, but by a DNS over HTTPs (DoH) service (Cloudflare 1.1.1.1 resolver). Cloudflare seems to be respecting the TTL as returned by the authoritative name server for your domain, so if you are able to specify a short TTL for a TXT record in your domain control panel, any changes made to the website should be live within that time.

Sorry, but I don't understand your point. How is this "degrading critical infrastructure" and "increasing the cost of market entry"? It's also not using someone else's resources - DNS hosting is a web service like any other. You pay for it either as a part of domain registration/renewal cost (when DNS hosting is included in the registrar's offer) or separately (e.g., Route53 or "Advanced DNS" offerings).

At the moment, it does, but we plan to release a Docker image of the relay server so that anyone would be able to spin his/her own relay or use any other existing public relay.

The triweb platform is still a work-in-progress, and there is a lot left to be done, released, and documented. The Banner app is mostly just an early demo of how TWAs are built and how they may be deployed to domains, that I thought may be interesting to HN.

Thank you for your insights. I understand the concerns you've raised, but there's also another side to DNS that's often overlooked: its role as a globally available, distributed database for storing small amounts of data linked to domain names.

Now, I'm not saying that people should start to host their files on DNS, but for simple, personal "banner" like pages that say "Hi, I'm X, love cats, catch me on @email" that should be OK, may be easier than setting up a separate hosting, and make the web more inclusive for non-technical users. Storing and transferring a few hundred bytes for this purpose under a distinct namespace/zone in a niche use case should be well within the capacity of the existing DNS software and infrastructure. We already have other standardized, dedicated classes of informational ("Layer 7 data") DNS records like HINFO and RP, so why not store a piece of text that would have a meaning for humans and present it in a nicely formatted (themes) and accessible (HTTP) way.

The way I see it is as a scale: DNS TXT records may be ok to use for small, simple, informational pages; - static hosting (GitHub Pages, Cloudflare Pages, etc.) should be used for longer texts, pages with custom assets (e.g., images), or multi-page sites; - SSGs and dedicated platforms for blog and bigger websites (Jekyll, Wordpress, etc.); - VPSes, EC2, Lambda, Firebase etc. for bigger things; - ending probably with dedicated servers, networking, and own ASNs for big online platforms. There is always some amount of data or activity above which one should switch to the next level, but switching to it requires additional knowledge and resources; and the other way around, buying and maintaining a dedicated server just to host a simple, static website with low traffic is an overkill.

Also, one thing about the app's architecture may be worth highlighting: The app uses a pre-set DoH provider (currently Cloudflare) to resolve DNS queries on the client-side, so the impact on the DNS ecosystem is close to none as only the source DNS server and the DoH resolver store and transfer these TXT records. Such setup also protects sites against mitm attacks. If the traffic becomes too big for Cloudflare infrastructure (if that's even possible), we can always setup and switch to our own dedicated DoH endpoint. Similarly, if the DNS hosting provider thinks it's abusing their servers, they can increase pricing or limit the number and/or length of TXT records their customers can setup for a single domain.

Using DNS for website content storage is indeed unconventional and somehow controversial, but I wouldn't say it is a bad idea per se. TXT records were designed to store arbitrary data (up to 4.000 bytes per single record) and the app is meant to be used for small websites with a few paragraphs of text, as managing anything bigger than through a domain control panel is rather painful.

I think the main advantage is the ease and speed of use for people who want a simple, business-card-like website or a holding/landing page.

The main disadvantage is that due to the UI/UX of domain control panels, managing anything more than a few paragraphs of text gets messy really quickly. But that could be actually an advantage, as the DNS is not particularly well suited to serve large amounts of data, and the app itself is meant for small and simple websites.