|nitowa 32e08cf18e improve picture formatting||1 month ago|
|README.md||1 month ago|
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.
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.
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.
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.
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