"We meet up with or get introduced to people in one location, then travel with them to different locations. You’d think this was easy to do in an online format. After all, the destination is just a digital address and some transferred bits coming to your computer."
Have you ever been somewhere talking with someone, then wanted to go somewhere else with them? Maybe you’re at a bar and want to hop to a new bar. Perhaps you’re with some friends in a park and have decided to all go swimming.
Unsurprisingly, this is a normal part of life. We meet up with or get introduced to people in one location, then travel with them to different locations.
You’d think this was easy to do in an online format. After all, the destination is just a digital address and some transferred bits coming to your computer.
Unfortunately, the digital real-time context for accomplishing this universally is an unsolved problem. However, with a number of metaverse applications coming online, it’s time to change that.
Look Mom I’m a Warp Wizard
The concept for implementing Warp Parties is simple. Getting widespread adoption is a different beast entirely, but we’ll cover that at the end of this article.
Your journey into become a warp wizard starts with WARP PARTY CREATION. Both humorous and a helpful metaphor, warp parties can be thought if in the context of casting a magic spell.
With WARP PARTY CREATION a user creates a WARP PARTY METADATA object and is visually able to see who is part of the warp party. They’re casting the first part of the spell, akin to opening a singularity to another destination without actually opening the warp portal.
Ideally at WARP PARTY CREATION time is when the wizard would select the destination, simply a deep link to another location in the metaverse. However, some apps may choose to implement it such that once a warp party is created, the destination link can be changed.
With the warp party created, the next step is to ADD PARTY MEMBERS. Generally I think it would make sense to default to an invite system; the warp wizard sends invites to anyone he wants to come along, and they confirm the invite to join. Alternatively (maybe as a setting), the warp party could be open to anyone nearby to join, through any number of interfaces. For example, when a warp party is created, a warp portal appears that other users can click on and confirm to join the warp party.
As users are added to the warp party, their USER DATA shows up in a UI for the warp wizard to see. When the warp wizard is satisfied that the appropriate users are in the warp party, they can click WARP or CANCEL. Cancel ends the warp party, as if it never existed, just like a wizard stopping a spell before the final incantation.
If WARP is selected, a WARP occurs, packaging the data of the WARP PARTY into a WARP PARTY METADATA object and opening the link with the WARP PARTY METADATA attached. If the destination is another app, the current app should probably close.
This is where things get spicy.
Whatever application you are warping to essentially needs to have a deep-linking schema or API endpoint that will handle launching the new application, reading the WARP PARTY METADATA, and re-hooking-up the WARP PARTY MEMBERS into the same real-time instance and location in-app.
So, if everything worked correctly, you could travel as a group from a world in VRchat exploring a jungle to a world in Rec Room playing paintball. Some of the concrete implementation of Warp Parties can vary by application, what’s important is the general concept and a universal metadata linking format.
Magic Isn’t Real (But Any Sufficiently Advanced Technology is Indistinguishable)
Call of the Warp Council
There are a number of obstacles that need to be addressed, and I’ll do my best to lay them out.
First, every application has its own user accounts. How does an app with metadata about one collection of users translate to a brand new application?
There are a number of potential solutions, but here’s the best one I could think of at this moment:
When a user WARPS to a new app, they must choose which account to sign in with to proceed. If they regularly use the app they might already be signed in so can use their existing session token, or just need to re-authenticate. If they don’t have any account they sign up, then skip past the typical first-time-user flow into the warp destination. The application knows the user launched in WARP MODE so will prioritize putting them into the warp destination with their WARP PARTY MEMBERS.
Second, every app supporting cross-app warp needs to implement the WARP deep linking launch schema. This means the app has to support deep linking in the first place (non-trivial at the moment, but in my opinion a must-have for metaverse apps), and the app has to recognize the WARP PARTY METADATA and know what to do with it to successfully link everyone into the same destination (a unique implementation per-app since everyone’s networking stack is fairly bespoke).
However, assuming a council of metaverse creators can agree on a metadata standard, or someone writes software that can quickly adjust inconsistencies from slightly different implementations, accomplishing inter-app warping seems very accomplishable.
The time is ripe to start a practical conversation on universal inter-app warping. Even though such a feature seems to be inherently opt-in for metaverse developers, if we can establish a standard and build open-source tools around it, the metaverse will have more open flow rather than being a collection of walled gardens.
If this is something you’re interested in helping bring about, please contact me at vrinsider[*]gmail.com
Note: Handling what to do if a warping user doesn’t have the needed app downloaded (in the case where it’s not a browser app) is another tricky problem that I didn’t have time to cover in an already long-than-intended article. That implementation detail is certainly solvable though.
