Frequently Asked Questions

The Connected Spaces Platform

  • An interoperable communication library for the spatial internet.

  • The Connected Spaces Platform is a library that provides developers across a range of languages and platforms with a means to build interoperable, cross-reality, multi-user applications.

    It comes in the form of an open-source client-side library, effectively encoding in binary form the standards by which applications can interoperably communicate with one another. Standards that we can all contribute to.

  • Today, when you visit a web page on your laptop, mobile, or desktop computer, it looks and behaves the same no matter how or where you’re accessing it. There is a consistent user experience. This is made possible by adhering to web standards and ensuring interoperability across various platforms allowing us to build websites and applications that function smoothly, regardless of the device or browser being used. Interoperability is vital for the next internet too.

  • Yes, it is free to use under the Apache License 2.0. This is a permissive license whose main conditions require the preservation of copyright and license notices. Contributors provide an express grant of patent rights. Licensed works, modifications, and larger works may be distributed under different terms and without source code.

  • Spatial experiences should work across multiple technologies in harmony, bridging applications and devices so that we can move beyond a series of disconnected islands. But currently, users have to switch identities, devices, and interfaces to navigate between different platforms. And organizations that want to build these next-gen experiences often need to develop and compile custom experiences for each platform, and then try to string them together with a hodgepodge of cloud services. That sucks.

    The Connected Spaces Platform provides a solution for this. It gives developers across a range of languages and platforms a means to build managed, live, persistent, interoperable, cross-reality, multi-user applications, which talk fluently with other CSP-backed applications.

  • It allows your application to communicate interoperably with other spatial web applications via an API that you can use to both understand and describe changes occurring in the spatial web. That’s much bigger than just describing a scene.

    The API has been designed to allow applications to work at a high level of abstraction, one that can be easily integrated into modern game engines and real-time renderers. It reasons about users, permissions, spaces, entities in your space, and the changes that happen over time to them.

    Internally, it handles the heavy lifting of ensuring that what your application says is happening is heard and understood by any other CSP-enabled application.

    It handles all of the actual incoming and outgoing traffic for you, all of the schemas, the DTOs, the RESTful endpoints that should be hit, and efficient transaction mechanisms for highly performant multi-user experiences. It maintains connections, handles user authentication, and token management. It takes care of ensuring scripted interactive experiences just work, in a Turing-complete execution environment and affords integrations with external services such as third-party authentication via Google, Apple or Discord, VOIP via Agora, commerce via Shopify, event ticketing via Eventbrite.

    The Connected Spaces Platform both defines and implements the protocols for all of this, in a freely available and functional library that can be used today.

  • CSP is a client-side library that allows your application to interoperably talk to cloud services. It’s not the services, but a Rosetta Stone for communicating with any other CSP-enabled application via services. The specific set of services that CSP is pointed at is immaterial.

    Naturally, we have developed our own set of services to facilitate the development of CSP. While they rock, they aren’t (and shouldn’t be) the only ones that CSP can be pointed towards. CSP is agnostic to the actual root URIs it is pointed at. It just requires that those services follow a consistent interface, one that is well documented in the repos.

    Given such a set of services, CSP accelerates the development of spatial web applications that natively and automatically will just work with any other application that uses CSP. Not just at the scene description level, but at the transaction level, the scripting level, the user identity level, the permissions level, the access control level, and the ecommerce level.

    All of it, working interoperably with other apps, across a range of languages, with no effort from the developer.

  • The Connected Spaces Platform can be used by web developers, Unreal Engine Developers, mobile app developers, and cloud services developers.

  • We’ve always been careful to keep it agnostic of asset formats because that’s the key to interoperability. We acknowledge that we cannot know what formats future client applications will prefer. The Connected Spaces Platform reasons about the notion of assets, and is aware of their Mime types. It ensures that the asset is correctly uploaded and downloaded, and that it can be referentially linked with other content, but that’s as far as the platform goes when it comes to formats.

  • All information is on our repo on GitHub.

  • In order to provide robust, persistent, real-time connectivity, the Connected Spaces Platform must be connected to a set of Cloud Services that offer common things like identity management, storage, multiplayer services, and the like.

    A developer could create their own services, or integrate their own unique combination of third-party commercially-available services…as we did in our early days. Or we can provide access to Magnopus Cloud Services, which are ready-made to support CSP.

    We have gone to great lengths to optimize our services to minimize complexity and costs to host and use, but whether built and hosted by the developer or accessed through Magnopus, there are naturally costs associated with the consumption of services, as with any utility like electricity or water.

    For development purposes, we will be offering access to our cloud services free of charge so that people can try out the system. We will apply some reasonable limits to traffic and storage in order to be conscious of costs. Included with this is access to documentation and support.

OpenUSD

  • At first glance, USD and CSP may appear to be doing similar things. They’re related but are two very different things.

    USD is an interchange file format built to structure scenes of spatial data. CSP is a middleware engine that enables the managed transmission of spatial data. That spatial data can be stored in a USD file or many other formats.

    As a simple analogy, if USD is the “HTML of the spatial web”, then CSP is the HTTP.

    CSP is an application-side library, built for the spatial web, that does the job of handling fluent communication with other applications for you, the developer. The specific spatial data that is communicated between applications is still for you to decide. It can be stored in, or derived from, a USD file.

    CSP is agnostic of any underlying asset formats. Any applications written that natively support USD can take advantage of all CSP functionality. This includes user management, group management, avatar integration, real-time interactions, continuous, persistent spatial transactions, and integration with external services.

    CSP can enable developers wishing to use USD to rapidly stand up fully interactive solutions, with users, objects, external integrations, real-world anchoring, interactivity, and persistence across platforms.

  • We can’t say either CSP or USD is ‘better’, because they solve different problems, and they can both make each other more useful. The functionality that CSP provides complements the USD format on its journey to mainstream adoption.

Tenant IDs

  • You are a tenant– a tenant of Magnopus Cloud Services (MCS), which underpins CSP. Your tenant ID is how your application is identified by our system, like a calling card. If anything tries to get into or out of our services without a tenant ID, it’s Stranger Danger!

    A Tenant is also a section of the database that’s reserved for you and your work.

    Consider an apartment building. The building is MCS. A tenant is like the address of your apartment in the building. All of your accounts are there, your spaces, your assets, etc. Anything you want to store in your apartment must be addressed so the mailman knows where it goes.

    While not an authentication or security token, you should still exercise caution when sharing your tenant ID. It is unique to you and your application(s). You don’t want anyone impersonating you or squatting in your apartment.

  • If you want to develop a custom application using the Connected Spaces Platform in conjunction with Magnopus Cloud Services, you'll need a Tenant ID.

  • Not at this time.

  • Sort of. A Tenant ID cannot be changed once it’s generated. If you want to replace an old Tenant ID, you can submit a Github request to delete it and get a new one. However data from one Tenant cannot be moved into another, so getting a new Tenant ID would require you to start over from scratch.

    As for the data associated with your ID, it depends on the environment you’re using. When you are given an ID, it can be used in both the staging environment for your testing and the production environment, which is what’s available to the world. For all intents and purposes, whatever is in production is there to stay.

  • Your tenant is used to initialize CSP. It is defined in the CSPFoundation class. Please see the example projects in the GitHub repo for more information.

  • Send off this request form, and a member of the CSP team will get back to you.

  • Tenants are created in line with our development release cadence, which is roughly every two weeks. Production tenants are available one month from when the staging tenant is created. If it has been longer than two weeks and you still haven’t heard from us, please file a GitHub issue.

  • Yes.

  • Yes, but Tenants cannot share data or accounts. They are islands unto themselves. However, there is no limit to the number of Tenants you can request.

  • No. At present there is no way to migrate data/accounts/etc from one Tenant to another automatically.

  • Not at this time.

  • No. Tenants are an infrastructure/permission construct. They are not the same as groups or organizations, which have the concept of membership. You can be a Tenant Administrator, but that just means you can access any data or user without it being shared with you specifically. This is useful for any troubleshooting or administrative tooling.

    Returning to the metaphor of the apartment building, a Tenant Admin is like the person on the lease. Ultimately they can police what happens in the apartment, but they’re still not the building landlord and they can’t make structural layout changes.

    Tenant Administrator accounts can only be created by MSP engineers.

  • As of Aug 2023, the staging environment is email domain-restricted. That means only the domain of the email address you used to request a tenant is allowed to create an account. For example, if you requested a tenant and your email address is @happypuppytown.co, only people with @happypuppytown.co email addresses can log in.

    Tenant requests submitted without a company or from an email with a default domain like @gmail.com, @hotmail.com, or @outlook.com will not have this restriction.

    You can request additional email domains, be added to the allowlist, or remove the restrictions by submitting a Github issue.

  • Not at this time. While your tenant ID is the same regardless of environment, there is currently no way to promote your data through environments. A space created in the staging environment has to be manually remade in the production environment.

  • Not for the Tenant ID. Your Tenant ID will be the same in all environments. Accounts however are not. If you have registered an email address to create a profile with the staging URL, you will not be able to use it to log into the production URL without making a new account on that environment.

  • For development/staging: https://ogs-ostage.magnoboard.com

    For production: https://ogs-oprod.magnoboard.com

  • When you request to become a Tenant, you are automatically assigned as the Tenant Administrator, and an account is set up for you. If you’re having trouble signing up, please try using the ‘forgot password’ method to reset your password and access your account.

Connected Spaces

  • Right now we live in two disconnected worlds: a spatial physical world (concerts, museums, offices) and a generally-flat digital one, (websites, apps, videos). Living between two different worlds like this is unnatural for humans. We’re spatial creatures – scientific studies have validated that we understand information and enjoy experiences much better when they interact with us and our environment, rather than being flat.

    As spatial display and computing technologies progress, and we grow the standards and adoption of the spatial internet, we need a better way of uniting physical and digital spaces. We see these bridging blocks as ‘Connected Spaces’.

    Terms like ‘Metaverse’ and ‘Web 3.0’ have become confusing. While many people consider the Metaverse to be an interoperable network of virtual worlds, we believe the spaces of the next web will exist anywhere between physical AND digital worlds.

    Read more about Connected Spaces in this blog post.

Something else?

If you have a question we haven’t answered on this page,
please pop us a message!