Skip to toolbar

Community & Business Groups

HFVRP Community Group

This mission of this group is to help re-establish platform interoperability between descendants of the original "High Fidelity Virtual Reality Platform" (HFVRP) open source project.

The group will initially host discussions and coordinate volunteer research efforts in order to identify relevant areas of common ground across HFVRP projects.

For example, it was once possible to use the "interface" client from one platform to connect to a "domain server" hosted on a similar, but different platform. As these projects have continued to evolve, the once-shared protocol version (for example) between them has fallen out of sync, inadvertently breaking the possibility of cross-connections.

By gathering together common interest across multiple projects, this group hopes to then help collectively estimate efforts and help champion neutral sub-projects that can restore specific compatibilities.

It is suggested that neutral community sub-projects emerging from this group adopt the permissive Lesser GNU Public License (LGPL) open source license. LGPL currently seems to align best with the mission at hand and for these reasons:

  • interoperability across diverse projects is likely to be an ongoing, multi-platform, community-driven effort -- adopting LGPL for these components can help ensure the collective community effort remains transparent and improvable across the entire project space
  • as degrees of interoperability are restored LGPL dependencies can be version-managed and upgraded per each projects typical dependency update schedules
  • LGPL is already an approved dependency license across HFVRP projects (ie: all known platforms critically depend on Qt by way of the LGPL) -- by not introducing a new license for these shared efforts, existing open source project audits can remain intact

This effort will hopefully span across diverse project politics, technical minds, and social circles which can come together and approach compatibility as a shared effort.

All platforms forked from the original HFVRP code base are welcome to join forces this way and in particular contributing developers, community members, and any others interested in helping broaden platform interoperability.

Some of the low-level technology skills likely needed to restore interoperability are:

  • familiarity with HFVRP networking protocols and versioning
  • "HFM" internal model formats and corresponding C++ structures
  • overall "Oven" asset baking tool and filesystem layouts
  • Baked asset structures (materials.json, ktx, modded FBX format w/draco compression, etc.)
  • Entities "models.json.gz" world persistence format and "domain server" archive formats
  • "Avatar.fst" and internal blendshape "de facto" standards
  • "Interface" client, "domain server," and "assignment client" JSON configuration formats
  • (as common sub-projects emerge) help setting up multi-project Continuous Integration systems

We think it will be easiest for volunteers in cases where interested projects have remained open source, but all HFVRP projects (including closed source ones) are welcome to join and suggest specific layers or features they would nonetheless be interested in seeing reemerged as a common open source dependency.

This group will not publish Specifications.

Group's public email, repo and wiki activity over time

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

No Reports Yet Published

Learn more about publishing.

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

Publish Reports

Call for Participation in HFVRP Community Group

The HFVRP Community Group has been launched:


This mission of this group is to help re-establish platform interoperability between descendants of the original “High Fidelity Virtual Reality Platform” (HFVRP) open source project.

The group will initially host discussions and coordinate volunteer research efforts in order to identify relevant areas of common ground across HFVRP projects.

For example, it was once possible to use the “interface” client from one platform to connect to a “domain server” hosted on a similar, but different platform. As these projects have continued to evolve, the once-shared protocol version (for example) between them has fallen out of sync, inadvertently breaking the possibility of cross-connections.

By gathering together common interest across multiple projects, this group hopes to then help collectively estimate efforts and help champion neutral sub-projects that can restore specific compatibilities.

It is suggested that neutral community sub-projects emerging from this group adopt the permissive Lesser GNU Public License (LGPL) open source license. LGPL currently seems to align best with the mission at hand and for these reasons:

  • interoperability across diverse projects is likely to be an ongoing, multi-platform, community-driven effort — adopting LGPL for these components can help ensure the collective community effort remains transparent and improvable across the entire project space
  • as degrees of interoperability are restored LGPL dependencies can be version-managed and upgraded per each projects typical dependency update schedules
  • LGPL is already an approved dependency license across HFVRP projects (ie: all known platforms critically depend on Qt by way of the LGPL) — by not introducing a new license for these shared efforts, existing open source project audits can remain intact

This effort will hopefully span across diverse project politics, technical minds, and social circles which can come together and approach compatibility as a shared effort.

All platforms forked from the original HFVRP code base are welcome to join forces this way and in particular contributing developers, community members, and any others interested in helping broaden platform interoperability.

Some of the low-level technology skills likely needed to restore interoperability are:

  • familiarity with HFVRP networking protocols and versioning
  • “HFM” internal model formats and corresponding C++ structures
  • overall “Oven” asset baking tool and filesystem layouts
  • Baked asset structures (materials.json, ktx, modded FBX format w/draco compression, etc.)
  • Entities “models.json.gz” world persistence format and “domain server” archive formats
  • “Avatar.fst” and internal blendshape “de facto” standards
  • “Interface” client, “domain server,” and “assignment client” JSON configuration formats
  • (as common sub-projects emerge) help setting up multi-project Continuous Integration systems

We think it will be easiest for volunteers in cases where interested projects have remained open source, but all HFVRP projects (including closed source ones) are welcome to join and suggest specific layers or features they would nonetheless be interested in seeing reemerged as a common open source dependency.

This group will not publish Specifications.


In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.

This is a community initiative. This group was originally proposed on 2020-11-09 by humbletim metaverse. The following people supported its creation: humbletim metaverse, Caitlyn Meeks, Le Vert, Maki Deprez, Dave K, Martin Allerton. W3C’s hosting of this group does not imply endorsement of the activities.

The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.

We invite you to share news of this new group in social media and other channels.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at site-comments@w3.org

Thank you,
W3C Community Development Team