Beginning

The story of this project begins with the appearance of indImm in 2019. This tool allows users to upload files to the Ripple blockchain and then to view or download them via a web interface. The project stirred quite some controversy and was subsequently abandoned soon after.

indImm fascinated me with its creative use of the blockchain, but disappointed with its slow speed, making it effectively useless as file storage. For illustration compare the time it takes to download a 2.5KB file vs a 1MB file.

xrpIO and making things fast

Mostly out of curiosity I set out to replicate and improve what indImm started. The corresponding library, xrpIO, is today available as open source project under the MIT license.

The watercooler pitch for xrpIO is quite simple: Since XRP transactions allow for up to 1kB of arbitrary data to be attached via a memo field, I can effectively write 1kB chunks of data to the Ripple blockchain by sending myself minimum-denominated payments. While the downloads in indImm evidently showed linear speed (hinting at a list-like implementation), xrpIO stores the hash-pointers as tree, increasing the speed by several magnitues. Compare how quickly the same 1MB file from before loads when using this library. (Please be aware that the download may randomly get stuck or fail if the public Ripple node is overloaded. Running a local node is trivial, greatly increases speed and completely avoids this issue but does not yield comparable results with IndImm)

From I/O to application building

My choice of TypeScript as programming language had the fortunate sideeffect of allowing xrpIO to be embedded into websites. The next idea was that I could encode a state change (i.e. function call), write the information with xrpIO and have the website update its state on the fly, based on the ordered application of these calls. Initial prototypes were successfully able to implement this idea, and this allowed me to use the Ripple blockchain as a quasi-database containing state changes.

Naturally, the next step was to standardize the protocol in order to reduce the implementation complexity. The resulting open source (MIT) library was named RJSVM, the Ripple-JavaScript-Virtual-Machine.

Ripple as webserver

Building and deploying such a RJSVM powered website with a client-based rendering framework brought me very close to what indImm is. The eureka moment came when I realized that websites are really nothing more than strings too, so they themselves can be written and read with xrpIO. This would mean that the frontend, application logic and state(-transitions) are all persistently stored on-chain, which although not exactly replicating smart contracts, becomes awfully close to being one.

An lot of engineering with webpack later a functional prototype was created, and the very first fully blockchain-sourced website went live. You can view it under caisar.github.io.

Next steps

The above proof of concept has one obvious weakness: browsers don’t natively speak xrpIO, so a gateway webpage is necessary to download the application. This is what caisar.github.io is. While those gateway pages are able to be shipped with a minimal size (about 1kB) the technology still requires a webserver to serve these files statically. Obviously, the next step is to reinvent the browser, but instead of HTTP it speaks xrpIO.

A prototype is available here: The Tür browser.

As the name heavily implies, the project is somewhat inspired by Tor. While Tor allows traffic to be masked completely, the hidden services themselves are a undeniable weakpoint, that once compromised allow an attacker to turn them into honeypots. Tür on the other hand makes very little effort to mask traffic (it is readable via the blockchanin by anyone) but the “server” is replicated on each Ripple (history)node, making it effectively uncensorable/impossible to capture without breaking the promises the blockchain itself makes (i.e. immutability of persisted transactions).

The tür browser is undeniably still in an early prototypal stage. Next features would include

• Key management: Right now any demonstrative RJSVM application just generates testnet wallets on launch. A mainnet-ready implementation would store wallet keys in the browser and safely expose I/O via a shared secure interface seperating webpages from the browser.
• State storage: For now application state has to be recalculated on every application start. In the future there should be a way to checkpoint RJSVM state on disk to speed up loading time
• The Tür name service (TNS): Hashes as resource identifiers are a workable solution, but they suffer from the same issue that IP addresses do in the internet. People can’t remember them. Baking a nameservice RJSVM into the browser would be a natural improvement.