coderofsalvation/xrhf
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

📃 master: update documentation

Browse source
This commit is contained in:
Leon van Kammen 2026-02-22 11:35:46 +01:00
parent fd793b4abc
commit a4b852224e
1 changed files with 64 additions and 35 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

99
index.html
View file

@ -264,6 +264,23 @@
</div> </div>
<br> <br>
<div class="spectrum">
<div></div>
<div></div>
</div>
<h3>XR Hypermedia criteria</h3>
<ul>
<li><a href="https://lofi.so/learn" target="_blank">Local-first</a></li>
<li><a href="#security">Secure (read-only) content</a></li>
<li><a href="#deeplinking">Spatial deeplinking</a></li>
<li><a href="#xratrest">XR at rest</a></li>
<li><a href="#iwashing">No interop-washing</a></li>
<li><a href="#cexit">Credible XR exit</a></li>
</ul>
<br>
<div class="spectrum"> <div class="spectrum">
<div></div> <div></div>
<div></div> <div></div>
@ -388,6 +405,7 @@
<div></div> <div></div>
</div> </div>
<center> <center>
<h3>Supporter of Open XR Hypermedia stacks</h3> <h3>Supporter of Open XR Hypermedia stacks</h3>
<div style="max-width:945px;"> <div style="max-width:945px;">
@ -424,7 +442,7 @@
<b>A:</b> Indirectly funding/promoting proprietary engines with public money is tough (public money public code).<br> <b>A:</b> Indirectly funding/promoting proprietary engines with public money is tough (public money public code).<br>
<hr/> <hr/>
<b>Q: Which Open XR engines are preferred?</b><br> <b>Q: Which Open XR engines are preferred?</b><br>
<b>A:</b> Preferred are Fully Opensource XR <b>Browser</b>engines like: <b>A:</b> Preferred are Fully Opensource XR <b>Browser</b>engines like:
@ -451,26 +469,30 @@
<hr/> <hr/>
<b>Q: Regarding hyperlinking, is linking to a webpage enough?</b><br> <div id="deeplinking">
<b>A:</b> Most games or WebXR-sites are shallow-linked disjointed XR experiences via appstores (not hypermedia), basically: <b>Q: Regarding hyperlinking, is linking to a webpage enough?</b><br>
<b>A:</b> Most games or WebXR-sites are shallow-linked disjointed XR experiences via appstores (not hypermedia), basically:
<blockquote> <blockquote>
<cite> <cite>
"We don't want customers to leave our premise" "We don't want customers to leave our premise"
</cite> </cite>
</blockquote> </blockquote>
A much more interesting is <b>seamless XR hypermedia</b> surfing: by interlinking 3D files <b>immersively</b> via <a href="https://xrfragment.org" target="_blank">(XR Fragment) URLs</a> or <a href="https://coderofsalvation.github.io/janus-guide/" target="_blank">JanusWeb</a>.<br>See the difference below:<br><br> A much more interesting is <b>seamless XR hypermedia</b> surfing: by interlinking 3D files <b>immersively</b> via <a href="https://xrfragment.org" target="_blank">(XR Fragment) URLs</a> or <a href="https://coderofsalvation.github.io/janus-guide/" target="_blank">JanusWeb</a>.<br>See the difference below:<br><br>
<img src="asset/img/xrhypermedia.jpg" style="width:100%;border-radius:7px;max-width:900px;filter: invert(1) hue-rotate(155deg)"/> <img src="asset/img/xrhypermedia.jpg" style="width:100%;border-radius:7px;max-width:900px;filter: invert(1) hue-rotate(155deg)"/>
<blockquote> <blockquote>
<b>Rule of thumb</b>: if the XR content can be selfhosted <b>by users</b> separately from <b>the XR viewer</b>, you're on the right track. <b>Rule of thumb</b>: if the XR content can be selfhosted <b>by users</b> separately from <b>the XR viewer</b>, you're on the right track.
</blockquote> </blockquote>
</div>
<hr/> <hr/>
<b>Q: How important is security?</b><br> <div id="security">
<b>A:</b> It depends, The value of a digital common lies in its liquidity. If you wrap public-domain content in restrictive security layers (like heavy DRM or complex access controls), you destroy the "common" aspect. Since the content is meant to be seen and shared, there is no "secret" to protect. Attempts to ensure it isn't maliciously altered are saluted. <b>Q: How important is security?</b><br>
<b>A:</b> It depends, The value of a digital common lies in its liquidity. If you wrap public-domain content in restrictive security layers (like heavy DRM or complex access controls), you destroy the "common" aspect. Since the content is meant to be seen and shared, there is no "secret" to protect. Attempts to ensure it isn't maliciously altered are saluted.
</div>
<hr/> <hr/>
@ -489,31 +511,38 @@
<hr/> <hr/>
<b>Q: How do you identify "XR interoperability-washing"?</b><br/> <div id="iwashing">
<b>A:</b> <i>"XR interoperability-washing"</i> is akin to greenwashing; it occurs when companies aggressively <b>market a commitment to open standards</b> while their top-down corporate structures make true interoperability technically impossible. It also partially explains why <b>XR interop</b> historically creates <b>top-down</b> talkshops, instead of actual <b>bottom-up</b> interop (like JanusXR).<br> <b>Q: How do you identify "XR interoperability-washing"?</b><br/>
Characteristics: <b>A:</b> <i>"XR interoperability-washing"</i> is akin to greenwashing; it occurs when companies aggressively <b>market a commitment to open standards</b> while their top-down corporate structures make true interoperability technically impossible. It also partially explains why <b>XR interop</b> historically creates <b>top-down</b> talkshops, instead of actual <b>bottom-up</b> interop (like JanusXR).<br>
<ul> Characteristics:
<li>Top-down B2B-interop (instead of bottom-up)</li> <ul>
<li>complex SDKs and proprietary integrations</li> <li>Top-down B2B-interop (instead of bottom-up)</li>
<li>proprietary servers as essential component</li> <li>complex SDKs and proprietary integrations</li>
<li>designed to "lock in" their user base</li> <li>proprietary servers as essential component</li>
<li>no credible exit (run content elsewhere e.g.)</li> <li>designed to "lock in" their user base</li>
</ul> <li>no credible exit (run content elsewhere e.g.)</li>
</ul>
While these methods may offer limited connectivity, they fall short of providing a sustainable, seamless "world-to-world" browsing experience (XR hypermedia).<br> While these methods may offer limited connectivity, they fall short of providing a sustainable, seamless "world-to-world" browsing experience (XR hypermedia).<br>
In contrast, <b>(bottom-up) XR hypermedia</b> offers a more cost-efficient path.<br> In contrast, <b>(bottom-up) XR hypermedia</b> offers a more cost-efficient path.<br>
By removing the need to protect stakeholders, centralized user bases, or specific crypto-wallets, it flips the traditional power structure. <br>In this model, the user—not the corporate stakeholder—is the starting point and operator of the network. By removing the need to protect stakeholders, centralized user bases, or specific crypto-wallets, it flips the traditional power structure. <br>In this model, the user—not the corporate stakeholder—is the starting point and operator of the network.
<b>NOTE:</b> XRHF is not anti-business, it's just that many online businesses don't have the 90s internet-mindset like DNS-companies (the network is the market, not the users). <b>NOTE:</b> XRHF is not anti-business, it's just that many online businesses don't have the 90s internet-mindset like DNS-companies (the network is the market, not the users).
<br><Br> </div>
<b>Q: What is the 'XR at rest' criteria?</b><br> <hr/>
<b>A:</b> Basically that XR experiences should be cheap to archive and reproduce: the 'XR at rest' criteria dictates that immersive experiences should ideally exist as persistent, static files rather than being dependent on active, power-hungry server processes.<br>By decoupling the XR space from continuous compute requirements, these experiences remain accessible even when the original hosting infrastructure or company servers are powered down. <br>This approach leverages a 'cacheable' hypermedia architecture, allowing virtual environments to be served and cached much like standard web pages.<br> Ultimately, this ensures the long-term preservation and interoperability of the spatial web, preventing "digital decay" common in traditional live-service gaming models.
<br>
<b>Q: What is the 'credible exit' criteria?</b><br> <div id="xratrest">
<B>A:</b> A credible exit ensures that users are never trapped within a single ecosystem, allowing their digital identity, assets, and progress to remain functional even if they switch platforms.<br> By prioritizing data portability and interoperable file standards, developers protect the user's long-term investment and prevent the loss of personal data if a service is discontinued.<br> Ultimately, providing a clear path to move data elsewhere fosters trust and is a fundamental requirement for building a truly open and decentralized XR landscape.<br> <b>Q: What is the 'XR at rest' criteria?</b><br>
<b>A:</b> Basically that XR experiences should be cheap to archive and reproduce: the 'XR at rest' criteria dictates that immersive experiences should ideally exist as persistent, static files rather than being dependent on active, power-hungry server processes.<br>By decoupling the XR space from continuous compute requirements, these experiences remain accessible even when the original hosting infrastructure or company servers are powered down. <br>This approach leverages a 'cacheable' hypermedia architecture, allowing virtual environments to be served and cached much like standard web pages.<br> Ultimately, this ensures the long-term preservation and interoperability of the spatial web, preventing "digital decay" common in traditional live-service gaming models.
</div>
<hr/>
<div id="cexit">
<b>Q: What is the 'credible exit' criteria?</b><br>
<B>A:</b> A credible exit ensures that users are never trapped within a single ecosystem, allowing their digital identity, assets, and progress to remain functional even if they switch platforms.<br> By prioritizing data portability and interoperable file standards, developers protect the user's long-term investment and prevent the loss of personal data if a service is discontinued.<br> Ultimately, providing a clear path to move data elsewhere fosters trust and is a fundamental requirement for building a truly open and decentralized XR landscape.
</div>
<div class="footer"> <div class="footer">
<small>Jump to:</small> <small>Jump to:</small>