itty.bitty, new from the design leader at Dropbox. Itty.bitty uses the URL to contain the text of a Web page. The page can have 2,000 bytes, or about 170-200 words, if you’re going to support legacy Web browsers such as Internet Explorer.
No hosting server is required, and as the data sits after the # symbol. What comes after the # is meant to be page-position related, and as such it never gets sent to the server.
The base64 link code is not pretty…
But the same link/page displays as…
This link is the page.
Scripting and hyper-linking is enabled in such pages, so long as it all fits in the URL length. The code can’t do images, but you can do old-school ASCII-art.
The main drawback seems to be that you’re going to have to be 1000% sure that your text is exactly as you want it before you make the link… because there’s no after-post editing for errors or updating of dead hyperlinks in the page.
In which case you’d ideally consistently version and date-stamp the
">How it works
bit, as…
">How it works (v.0.1 | 14/07/2018)
…so that people and search-tools can discover later updated versions of the same content. Otherwise the itty.bitty system risks becoming an intertwingled mess of half-baked and old/broken stuff that you (and probably Google) won’t want in search results.
I’m guessing that advanced Web browsers such as Brave will soon ‘add a feature’ in relation to this, by enabling much longer data-carrier code to be read from URLs. Perhaps also some simple automatic “…and can we find a later version of this itty.bitty.site?” query, done inside the browser. There would, however, also have to be some sort of dynamic ownership hash embedded in the page, to protect against impersonation of the page-author. Perhaps the system of authoring an ownership-hash and datestamp could be combined into a simple ‘one-click operation’ in a desktop authoring tool.
Anyway, it’s one example of the coming uncensorable Decentralized Web.