The Metaverse Interoperability Community Group is a community of artists, creators, developers, and other innovators exploring concepts surrounding the design and development of the metaverse. Metaverse interoperability allows for participants and creators to maintain ownership of their data and creative works.
- We collaborate, driven by research, privacy and accessibility, to make the metaverse more human.
- We work incrementally, iteratively, and with intent.
- We are creating a cooperative, sustainable culture of innovation.
- We empower the people making the metaverse.
- We must cultivate resiliency by championing diversity, and freedom of choice.
The Metaverse Interoperability Community Group bridges people and platforms for connected experiences, exploring research and development of avatars, worlds, creative assets and the connections between metaverse communities. We seek ways to connect metaverse systems and the people creating them with resilient data and processes for the long term interlinking of metaverse communities.
The scope of work for this group includes topics related to interoperable worlds, data formats and protocols as well as discussion around the design of interoperable virtual spaces. Some of these topics may include:
- Virtual world URIs
- Virtual world metadata discovery
- Nested experiences within worlds
- Portals and windows into platforms, worlds and experiences
- Identity
- Portable avatars
- Asset portability
The Metaverse Interoperability Community Group creates collaborative working space for focused public interoperability efforts that invite global corporate, public sector and independent creators to align across diverse interests and values. This community supports self organizing groups within the community to solve for themes and publish shared deliverables.
This group will not produce private software products. Research and development may include possible reference implementations or test suites.
Community events, working collaborations and resources for implementation, and testing of interoperable metaverse standards.
The Metaverse Interoperability Group will produce specifications for:
- 3D Formats within the glTF Extensions sub-group
- WebAssembly scene graph APIs within the WASM sub-group
Substantive changes to specifications in these groups will require members to sign the W3C Contributor License Agreement.
The group may produce other Community Group Reports within the scope of this charter but that are not specifications, for instance use cases, requirements, media case studies or white papers.
The group may produce technical documentation and community resources for the creation of interoperable metaverse media.
The group will make good faith efforts to include the following communities in the progress of our work, with a list of community partners and allies availiable on our GitHub.
- Open Metaverse Interoperability Group
- Social Web Working Group
- Immersive Web Working Group
- Accessible Platform Architectures (APA) Working Group
- XRSI
The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.
As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual's first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.
The W3C Code of Ethics and Professional Conduct applies to participation in this group.
The group will not publish specifications on topics other than those listed under specifications above. See below for how to modify the charter.
Substantive contributions to specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).
Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible.
Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.
The group will conduct all of its technical work in public. All technical work will occur in the group's GitHub repositories (and not in the mailing list or instant messages). This is to ensure contributions can be tracked through a software tool.
Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public mailing list, or to GitHub discussions. Video, audio, or other artifacts of these meetings may also be included.
The group's decision making process is outlined in the separate process document.
The group will appoint 1-3 chairs at each election. There are no limits on how many times a chair can run for re-election. The initial chair term length for this group is set at 3 months and will double after each election with a cap at 1 year. Chair selection will be decided by consensus voting. Abstentions will not count against the consensus vote.
After ratification, the group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.