A RESPONSE TO FACEBOOK / META - THE EXISTENTIAL PROBLEM
There's a reason why The Entity Formerly Known As Facebook is investing unimaginable resources (really, betting the company) on owning the spatial web and metaverse-related technologies.
Yet, one does not have to be a diehard digital rights activist to feel queasy about the current trajectory - a dodgy combination of a vertical-spanning monopoly and poor user experience.
We have a unique chance to kickstart an ecosystem-wide platform based on open standards, portability, interoperability, as well as user privacy and dignity.
THE CURRENT ARCHITECTURES - MEGA KINGDOMS
Metaverse applications built on proprietary engines (e.g, Unity, Unreal) are part of the latest battle in the decades-long war over the soul of the Internet, over whether its destiny is the open web or a fragmented (yet monopoly-ridden) walled garden. Few people realize, however, that the modern web browser includes a powerful AR/VR engine under the hood, and possesses all of the ingredients needed to power an impressively cross-device metaverse experience, from mobile phones to desktops to dedicated AR and VR headsets.
The social aspect of the metaverse (whether it's simple contacts management, feeds, notifications, event invites, and so much more) is currently only possible within the mega kingdoms of Facebook, Google, Microsoft, and the like. This is not an accident or a technological limitation – the involved parties specifically depend on locking down the users' contacts list, relying on the network effect lock-in.
To combat this, projects and standards have kicked off, including Mastodon, Secure Scuttlebut, Project Bluesky, Spritely Institute, The Solid Project, Distributed Web Nodes, and many others.
A BETTER ARCHITECTURE - INVERT THE RELATIONSHIP
The good news is that all of the ingredients already exist for a practical yet radically alternative metaverse architecture. The interdependent mesh of standards and protocols in the decentralized identity space may seem confusing at first, but the main idea is simple:
"Let users bring their own X"
Their own what? Pretty much anything you can think of, starting with their own user accounts, including IDs, usernames, display icons, avatars. Let them bring their own settings and preferences. Let them bring their own credentials bound to those user accounts (this opens up a breathtaking world of new features and interop). And let them bring their own contacts / friends lists – a key strategy that enables us to escape network-effect lock in of the mega kingdoms.
While we're at it, let users bring their own permissioned encrypted cloud storage (a more powerful, open standards, cross-domain equivalent of Google Drive), where those accounts, key pairs, contacts, and more, will be stored.
If you want to get really ambitious (and we do), allow users to bring their own metaverse worlds. A standardized data model of relevant components (scenes, avatars, inventory, behavior, etc) combined with an open source web-based "XR as a Service" platform like Ethereal Engine, allows XR worlds to flourish like websites on the early web.
And finally, you can use the newly emerging and newly standardized techniques of cross-domain authentication, capability-based permissions, digital signatures and encryption, to tie it all together into an interoperable whole.
The Adjacent Possible
- Frictionless portable identity across worlds - "Follow hard-links / portals to worlds hosted on different instances and web domains, without having to create new accounts."
- Portable interoperable user preferences, names, avatars -"Follow portals to different deployments and domains, your preferences and avatar comes with you."
- Portable interoperable inventory - user collections of all sorts, NFTs, uniques, costumes and accessories, etc etc.
- Contact lists that travel with you - solving the "cold start"/"empty village" problem, and overcoming network effect lock-in.
- Frictionless Social - Messages, parties, invitations, friends-lists, block-lists, and notifications work seamlessly across all deployments and domains.
Sooo...
What is Ethereal Engine?
What are DIDs?
What are credential wallets?
What is Solid?
Decentralized Web Nodes?
This is the current stack that we're building this vision on:
- Ethereal Engine - An open source multiplayer web-based metaverse hosting engine built on a performant subset of Three.js. Uses open standards wherever possible.
- Ethereal Engine Studio - An open source multi-user (!) collaborative web-based 3D world editor.
- Portable interoperable inventory - user collections of all sorts, NFTs, uniques, costumes and accessories, etc etc.
- DIDs - W3C Decentralized Identifiers v1.0 enable portable cross-platform cross-domain cryptographically bound user identity. (And, unlike much of the current generation of "Log in with <blockchain>" offerings, enables key rotation while the identifier remains stable).
- Verifiable Credentials (VCs) - Plainly speaking, a standard JSON-based envelope for cryptographically signed digital objects that interops well with DIDs. You can model all sorts of useful things as VCs – receipts, pass keys, inventory and digital assets, age verification credentials, preferences, game logic and in-world events, and much more.
- VC Wallets - Once you have ubiquitous cryptography-based identifiers and signed objects, you need a) some place to store those objects, and b) apps and services to help you manage keys. Think of them as slightly more user-friendly password managers. They can be hardware-bound (cold wallets) or cloud-based, and in the best cases (such as those powered by CHAPI, the Credential Handler API), part of the browser mechanism itself.
- User-owned Storage (Solid, EDVs, DWNs, etc) - If you let users bring their own avatars and digital assets to various metaverse worlds, they need a place to store those things securely. And we're not talking like an S3 bucket; the storage service needs to be standardized, and have a sophisticated authorization system so that users can grant and manage access to their stuff without too much friction or cognitive load. And preferably be end-to-end client-side encrypted. (Which requires good key management. Which requires wallets. You see how this all ties together.)
THE METAVERSE USER STORY
If all of that sounds abstract, here is a concrete example. Picture that most classic of video game objects, a locked door to a restricted area. At its simplest, it's fairly easy to implement – just have it check some in-game flag, or a per-user row in the database, yeah?
Except what if you want to get more interesting. What if you want the key to that metaverse door to be a real-world qualification? For example, only students who have completed the prerequisite class in a number of qualifying institutions can enter this room. Or only licensed firefighters and emergency responders. How about a proof that they are over the required age? Or just in possession of a VIP Pass? And users need not have picked up that key in your world, it just needs to come from an institution or a network that you trust.
And what if you wanted it to work in AR?
HOW IT WORKS
The remarkable thing about this demo, is that once the infrastructure exists (once you have a metaverse engine that works with standard VC wallets), all that an implementer or designer needs to do, in-world, is just to configure the door with a couple of parameters – what are the types of credentials it should it accept to unlock, from which trusted issuers or networks.
And after that, the machinery of decentralized identity and credentials takes over. The engine asks the user's web browser for a credential. The browser takes over, and lets the user select which one of their wallets the credential is stored in. The wallet takes care of all of the cryptography and signature management, interfacing with the user's cloud storage.
If the user decides to share that credential, the engine receives a Verifiable Credential (optionally with a proof that the user handing it over is the actual intended subject of the credential). And the engine can call a standard VC library to verify it.
WHAT’S NEXT
We have many things planned for this wallet and verifiable credential technology:
Building a home for your data for daily life, the metaverse, personal AI and beyond. Learn More:
- Life-Server Github - A decentralized personal data framework inspired by MIT's Solid Project
- Presentation from DWeb 2022
We plan to add better permissions in the form of fine grained scope based permissions making sharing access and data with family, friends, and colleagues easy.
We are planning more spatial assets with permission scope checks using verifiable credentials including:
- Portal link access
- Permissions on objects. EG interact, pick up, use, destroy
- Inclusion volumes that will only let you in if you have a particular VC
- Exclusion volumes that will only let you out if you have a particular VC
- And a general framework for VC based interactable items that use dynamic scripts
These types of systems will be the backbone of permissions as we transition to a web of Worldscale Augmented Reality.
JOIN OUR COMMUNITY
We are off to an amazing start making the web more equitable, safe, and decentralized, but we can’t do it alone. Help make this dream a reality by joining the effort!
