Avoiding Consumer Lock-ins with the Decentralised Web
This is the third blog post in our series exploring aspects of the Arweave’s decentralised, permanent web. You can catch up with the other parts here and here.
If you are like me, you have been an avid user of Google’s Gmail service since the first few months of the ‘private’ beta over a decade ago. Over this time, Google has rendered a fantastic service to us, with consistent releases of new features, fast and reliable service (I can only remember it being offline once when I needed it), and the simplicity that only great products can provide.
Over this period, I have also given out my personal Gmail email address to hundreds of people — many of whom only have this mechanism of contacting me. Google has also sold access to my profile (pseudonymously), mined the messages that my friends and I exchange, and (sometimes inadvertently) exposed my communications to dozens of governments around the world.
When Gmail began, these privacy violations were yet to be enumerated, or even (by me, naïvely) imagined. Yet, very shortly after Gmail was launched I begun giving my friends my Gmail address as the primary source of getting in touch — perpetually attaching myself to a service whose integrity I could not be sure of and perhaps should not have trusted. Google’s advertising and data privacy policies have shifted just as frequently as the manipulation of their search engine results. Once I had begun to give this address to my contacts, I (the consumer) was ‘locked-in’ to using the service provided by Google, whatever that might entail, until I informed all of my contacts of a new mail address to reach me at. Even if I had changed provider and burdened all of my friends with the confusion of multiple addresses for one person in their contact list, I could never be sure that this new mail provider would continue to avoid the same practices that led me to switch away from Gmail in the first place.
Such is the way of the centralised web.
Developer and Consumer integrity
In her recent blog post, Dani Grant enumerated the potential effects of ‘developer integrity’ on decentralised technology adoption. Dani’s point is that centralised products and services lack ‘developer integrity’, because they can make sweeping changes in their protocol at a moment’s notice. These changes can cause huge problems for developers, breaking products built on top of these centralised services, in turn disrupting any business they have built around these integrations. Decentralised networks, however, cannot easily or rapidly make such changes, and so have more ‘developer integrity’ as developers can place more trust in their offerings. This increased integrity will therefore accelerate adoption of decentralised technology.
Permaweb apps apply this concept not just to developers, but to consumers, too. As well as giving developers confidence that their applications will not be shut down or broken without warning, consumers of permaweb apps can also be confident that developers cannot deny access or worsen offerings to end-users. With a permaweb app address, as a consumer what you see is what you always get. This is not to say that developers cannot update permaweb apps — they can — but once published, previous versions of the app cannot be retracted or altered, new versions can only be added to the permaweb.
Centralised Vs Decentralised platforms
To make this point explicit, consider Weavemail, a service that we quickly hacked together in order to test the limits of the permaweb app development framework that we recently released. Anyone with an Arweave wallet can use Weavemail to send and receive messages, in a (mostly[1]) private and totally decentralised manner. Because Weavemail lives on Arweave’s permaweb, you can be confident that as long as you know the address of this transaction, and there is an available Arweave node to serve it to you, your access to this mail client as it currently exists simply cannot be denied, or changed.
This means that in future, no matter what we the developers desire, we cannot add intrusive ads to the page, nor sell your data to any interested parties.
With this permaweb address safely bookmarked, you can be sure of the integrity of your access to this service. While this kind of ‘consumer integrity’ may not be useful for all webapps — perhaps we do not care if our access to the ‘I has a bucket’ website is changed or denied — this can certainly make a difference for the services with which we entrust our core online presence for long periods of time. It is our expectation that in the same way developer integrity will drive developer adoption of decentralised networks, consumer integrity will drive consumer adoption of decentralised versions of the core web services that we all depend upon.
Fancy trying out Weavemail? Grab some tokens here and shoot me a mail at vLRHFqCw1uHu75xqB4fCDW-QxpkpJxBtFD9g4QYUbfw. We’re offering 10 AR to the first 100 people to send their first Weavemail!
All the best,
-arweave-sam
[1] While Weavemail message contents are private, some metadata is publicly available: anyone, anywhere, can track which addresses are sending and receiving Weavemail, and how many characters those messages contain. We do not recommend that you use Weavemail for important communications at the moment, as it is currently just a prototype. Weavemail’s current limitations could be easily overcome by the implementation of a slightly more complex cryptographic protocol. If you are interested in making an improved version of Weavemail, why not fork the Github repo?