Solving the Web3 Wallet Problem with PeerPiper.io on Arweave
This article was written by Mitchell for Arweave News.
Web3: an open, distributed web of decentralised protocols, allowing us to own and exchange interoperable assets across decentralised datasets and interfaces via dApps (Decentralised Applications).
These digital assets are, of course, stored on Distributed Ledgers using keypairs; and by providing keypair signatures, we (and dApps) can access, use and move them.
But, as it stands, dApps are limited by wallets and their accessibility, and users are required to download and install multiple wallets for their browsers and devices. When all that’s needed is safely providing signatures, why is this? And what do these limitations mean for the growth and adoptability of Web3?
Fortunately, in order to build PeerPiper, Doug Anderson has had to create a new wallet paradigm leveraging decentralised storage on the Permaweb.
Flexible keychains (not inflexible wallets)
Doug from PeerPiper.io has brought a common misnomer to light:
“In the crypto space, where we keep our keys is called a wallet. I find this term really misleading, as there are no funds stored there — only access to secrets which could unlock funds or data. So I am renaming the “wallet” to a “keychain” as it’s a place you keep your keys, not your money. Not sure if this will stick in the community, but it makes more sense to me at least.” – PeerPiper: Introducing a Next-Gen Web3 Keychain + Storage Scheme
Adding ‘keychain’ alongside ‘wallet’ is powerful semantics, perhaps welcoming new levels of specificity in how users (and maybe developers) think about Web3 assets and interactivity: “What wallet do I need for this?” becomes “What keys do I need for this?” .. and “What wallet will I integrate with?” becomes “How can I work with a user’s keys?”.
Today, interacting with Web3 applications requires users to:
- Download a wallet to create a keypair (often for each chain)
- Have those wallets available on the device when using the dApp
- Approve transactions (sign) from the wallet through a seperate window/app
After doing this, users end up with multiple wallet applications for multiple chains which are not compatible with each other and are not usable across operating systems, and on iOS an intermediary app like Wallet Connect is often required. To just provide signatures, that’s a lot of work to still be platform-restricted.
Even though these wallets provide a functional interface to view, send and receive funds or assets, when it comes to signing dApps that are multi-chain and multi-platform, beautiful siloed wallets aren’t what we need.
Enter the Portable Encryption Wallet / Keychain
Doug Anderson is developing PeerPiper.io to allow users to save, sell and share encrypted data.
There are 3 major developments within PeerPiper to make this happen and the third is the Portable Encryption Wallet/Keychain.
The user experience is still being fine-tuned, but here’s what we know so far:
Infinite dApps, chains and identities – one iFrame component
This new paradigm of Web3 signing leverages iFrame, a native HTML element compatible across all web browsers on all operating systems. iFrame is a way to embed a web document/page within the current web document/page (check it out).
In the iFrame, users will load in their own custom keyfile (from their local device) containing whichever keypairs for the chains and protocols they choose – since keys are identities, it may be reasonable to have multiple keyfiles for different purposes.
The iFrame will then store the keyfile as a browser cookie, and allow dApps to communicate with the keys via the iFrame. Cookies exist only on that particular browser, when a user switches devices or browsers, they will load in their keyfile from their local device again.
One iFrame component to handle a keychain with multiple keypairs means that users can take multiple cross-chain identities across any operating system.
Open source and deployed to Arweave (or anywhere)
Since Doug made the code open-source, dApp developers will be able to work with the same keyfile.json standard template to communicate with a user’s keys across any platform. And, since a version of the iFrame will be hosted on Arweave and IPFS, developers will know exactly what code they are getting if they embed the default iFrame straight into their dApp.
Furthermore, the potential for this new paradigm extends beyond the browser as Doug explained in a private message:
“There’s also some really great work going on with rust in WebRTC which means you could connect directly from the browser to a non browser, like on your desktop, mobile, or server, which would add a lot of flexible secure environments to the mix”
For now, the Portable Encryption Wallet supports the encryption standards used in Arweave (RSA) and Solana (ed25519); and with the code being made open-source, it is likely that other cryptographic standards which support more protocols like Bitcoin (secp256k) will be added before long.
Without even mentioning PeerPiper’s first two major developments: ArLog and Re-encryption, and acknowledging the original inspiration for PeerPiper, the wallet development alone brings a fantastic new suite for Web3 users and developers to securely and flexibly communicate.
More flexibility without compromised Security
When asked about the security and potential exploits of using iFrame, here’s what Doug said:
“Since the domain origins are different, browsers keep them apart by default. Any known exploits are usually from XSS attacks, cross-site-scripting. You can reduce this risk by not using content delivery networks (CDNs) and using content addressed identifiers (CIDs) like how IPFS and Arweave does it (essentially a content hash)”
This is great, flexibility is often compromised by security; Doug knew this and found an answer where we can have both.
made the code open-sourceCurrent wallets, which often begin as browser extensions and move out to Mobile Apps, or maybe even stand alone as Desktop Apps, are secure and great for creating keypairs, managing funds, and interacting with a specific blockchain, no doubt.
But an open, decentralised web is not about interactions with one particular blockchain; Decentralised Applications which aggregate the various functions and purposes found across Web3 will require the flexibility (and inherent UX) that this new Portable Encryption Wallet paradigm allows.
Fresh air and green fields
The dApps we see today as NFT Marketplaces, DeFi Platforms or Social Media Platforms are generally leveraging data from one particular blockchain; but, as users acquire assets across multiple chains that are interoperable, opportunity arises for dApps to leverage and present data across multiple chains, providing multi-protocol experiences.
Being open-source, multi-chain and multi-platform compatible, this new Portable Encryption Wallet paradigm breaks down a lot of barriers users have with current Web3 applications, but what about new dApps? What fresh innovation might there be? We will see.
In the meantime, stay in tune with PeerPiper’s pre-alpha developments here.
Doug’s original inspiration for PeerPiper which he shares in his first Open Web Foundry (OWF #5 Community Spotlight) presentation is about having one place to easily update and share personal data from (like his address, as he moved a lot). I feel these improvements to everyday life are a beautiful basis for technology to be built; and I give big thanks to Doug for being so patient and generous with his time and knowledge in understanding and answering my questions so well about PeerPiper and this new wallet paradigm.
