The Privy mindmap — the path ahead
Part 2: self-sovereignty through impact
Henri Stern
|May 27, 2022
We believe building in the open is core to building better data infrastructure. Accordingly, we are proud to present the Privy mindmap — this second part runs through the work ahead for Privy and how we build for a future of data ownership. For more on how Privy works today, check out part 1.
Self-sovereignty through impact
Too much of web3 today is built around visions for how protocols can shape the space over decades, rather than focused on helping developers ship safer, more delightful products today.
We believe data self-sovereignty will come from pragmatic, usable software that helps developers build great products right now and enable us to move web3 beyond purely financial use cases. To that end, our first order of business at Privy is to make it easy for developers to take on user data safely in web3 today.
We are starting with very simple APIs to help developers securely manage user data but this is not where things end. Through this work, we set the basis for sovereign data systems in which developers define schemas (data needs) but the users control permissions (data access) and can easily grant or revoke access to their data.
How do we get from here (user data management) to there (self-sovereign data)?
No Wizard of Oz on our way up the yellow brick road
We do this by building Privy along three core epics:
A more user-controlled Privy 🥸
A more integrated Privy 🤝
A more decentralized Privy 🫥
These epics mean building at the cutting edge of product design, applied cryptography and distributed systems, respectively.
I’ll break these down in turn. While each deserves its own write up, I’ll cover some high level ideas and specific roadmap items we’re especially excited about for each.
User-controlled Privy — 🥸
Today both schema (what data is needed) and permissions (who can access it) in Privy are set by developers. This enables them to securely take on user data without having to store it on their stack or risk data leakage through db misconfigurations or a breach of their perimeter.
While this introduces very little friction for the user, the end-goal is to enable sovereign data, by which users have full visibility and ultimately control over their data.
The path forward is simple:
secure data management — > permission transparency — > user control
We start with enabling developers to easily take better care of their user data and protect their users. Thereafter, we give users the tools to understand how their data is being used. This means building transparent audit logs by which users can track data accesses. Privacy is about control over data and informed consent. Let’s keep users in the know.
This then allows us to move to user control — enabling users to grant or revoke data access reactively.
A user granting data permissions to a dapp they just signed onto
User control is key to data resiliency and composability. Enabling users to break out of silos and take their data with them from app to app will unlock amazing new experiences in web3.
At a technical level, the journey involves the following:
🖖 User-centric auth — a datastore is only as secure as its authentication is trusted. We’ve already integrated Sign-In With Ethereum (SIWE) as a first example of user-centric auth whereby users authenticate with Privy directly rather than having to trust third-party auth
🪟 User facing audit logs — better privacy policies in which you see exactly what data a company has on you and how they are choosing to use it.
🌍 Global namespaces for data—we need standards around user data names and namespaces so users can effectively control data across platforms. How else can we know that Uniswap and Fractional (e.g.) mean the same thing you do when they request an “address?”
🤨 Reusable UX components—reusable, open-sourced UI to enable users to set permissions as they begin sessions (you can think of iOS perms when you turn on an app) that can be audited and improved to prevent dark patterns and give users consistent experiences across apps and platforms.
💪 Data control centers—where users can easily track what services have access to what data, and revoke access as their needs evolve.
A sample view of the user data control center we are envisioning
Permissions are a major unsolved problem on the web. Data self-sovereignty means reshaping how we think through informed consent on the web and is one of the most exciting systems and product design questions we face today! This work must be built atop open standards so users are not tied to a single service provider.
Integrated Privy — 🤝
How do we let developers do more to delight their users with less (data)?
Safer data will unlock whole new experiences in web3, provided it is easy to integrate into apps. The fallback for developers remains dumping data into siloed dbs. So the name of the game is to make sovereign data not just safer but more powerful and easier to integrate than its captive alternative.
We want to unlock new capabilities for devs without requiring them to become domain experts or build in increasingly complex stacks.
This epic revolves around the following:
🔗 Native web3 integrations — Integrating with web3 wallets directly to use self-sovereign cryptographic materials; integrating with smart contracts to react to on-chain events (to trigger notifications or auditable permissions changes) and write attestations to the chain (to write integrity proofs on-chain and make permissions delegation resilient).
🥩 Bridging web2 data — Integrating meatspace (real world) data into the web3 experience means being able to process it with web2 tools when needed. This means integrations with sendgrid, twilio, docusign to bridge on-chain experiences with off-chain rails.
🛠️ Use of better primitives — Privy must be modular and upgradable so it can make the most of cryptography as primitives improves. Integrations with ZKPs and TSS will enable us to improve system auditability without compromising on privacy.
As we start down this path, we’ve built Privy’s sendEmail() call to enable developers to send emails to on-chain address without having to pull down user emails.
The `sendEmail()` demo we’ve built :)
Can we improve system visibility and auditability for everyone without leaking data? Can data be processed without anyone decrypting it? Can we continually grow the set of coordinated trusted parties needed to perform actions on behalf of users?
Web3 has spawned a renaissance in cryptographic research. Modern data systems must make use of novel cryptography in order to cut down on tradeoffs made between privacy and usability!
All of the above is predicated on opening up Privy’s core platform so developers can integrate into it themselves. You should not have to use Privy-built integrations if you do not want to. Optionality is decentralization’s complement in our quest to bring about data sovereignty. We seek to build modular tooling with strong, sane defaults for developers and users.
This brings us to our third epic.
Decentralized Privy — 🫥
When it comes to data sovereignty decentralization is a means to an end. The end is ownership.
Real control over a system comes from having options about how to integrate it across layers of a stack. You shouldn’t have to trust Privy-built systems if you don’t want to. To that end, Privy is built for gradual decentralization.
This epic is about system architecture rather than user experience. It breaks down across
key control and encryption management,
permissions enforcement and auditability, and
storage
🔑 Key control
Non-custodial Privy is coming. Users should control their data using the same keys they use to control their digital assets. Data pipes in web3 must be built on non-custodial rails.
This begins with a deeper integration into wallets (beyond auth) so PII is encrypted under user keys. We are excited to collaborate with wallet providers in building for a more sovereign future as key management evolves.
🤝 Permissions
If a user encrypts their own data, who decrypts it when they’re not online? We agree with Moxie: people do not want to run their own servers.
Permissions delegation is a key part of Privy’s design. Today, Privy is your user’s data guardian: it enforces permissions on their behalf. The next phase will be to open up delegation so users can choose who enforces permissions for them. Ultimately, this means going back to the chain as the transparent backstop for permissions control (read on-chain permissions using TSS).
The evolution is as follows:
trust Privy (but verify) → choose who you trust → trust no single party
Actionable auditability is a system invariant throughout.
💾 Storage
Privy’s threat model today is built around data leakage, not censorship resistance. This is why we’ve started with cloud storage. It is cheap, reliable, fast.
Nonetheless, it is also subject to centralized control. You should be able to decide where you want your data stored. Privy was built modularly so the storage brick can be swapped out. This means opening up so your data can be hosted on Privy’s AWS account, another third party’s GCP instance, Filecoin, an IPFS cluster, your home machine, etc…
In conclusion: It takes a village
Now is the time to build for self-sovereignty. The web3 stack today is like the universe after the big bang: molten matter slowly shaping into planets. Tooling sets standards through usage — we believe the best privacy tooling is that which gets used.
Accordingly, Privy’s main goal today is to enable developers to easily build great products without putting their users at risk. With this, we are working so users take back control over their data online.
We cannot predict our stack’s future but we can help shape it by building delightful tooling today. Through greater transparency, intuitive controls, strong standards and integrated tooling we believe web3 will be the nexus through which users take back control over their data online.
If you’re building data standards in the space, holler, we can’t wait to build with you!
If you’re as excited to shape this new stack as we are, please join us! We’re hiring.
If you’re taking on your users’ data, reach out, we’d love to help you build right for them.
