Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Managing the external resources (uri paths) from gltf extensions #66

Open
fire opened this issue Feb 18, 2022 · 3 comments
Open

Managing the external resources (uri paths) from gltf extensions #66

fire opened this issue Feb 18, 2022 · 3 comments
Labels
new spec old is this still relevant ?

Comments

@fire
Copy link
Contributor

fire commented Feb 18, 2022

Propose an OMI extension for external resources.

  • gltf have external resources that may cause security risks.
  • Resources may become significantly more fragile due the passage of time with the links breaking.
  • Privacy may leak from access.

Process for addressing:

  1. gltf transform workflow
  2. Consent for playback and tracking
  3. Static bundles
  4. Self-contained bundles
  5. Link checking tool
  6. List exposed providers

Levels

  1. Whitelist all external resources
  2. Block all external resource
  3. All access external resources

Prior work

@oveddan
Copy link

oveddan commented Jun 12, 2022

yes this would be great! Also I would add it would be great if this supported IPFS addresses, as that is what's often used for storing files linked to the blockchain - and with IPFS supported here you could have assets with globally unique permanent addresses that you could host yourself by pinning the content.

@oveddan
Copy link

oveddan commented Jun 12, 2022

Also it would be nice if it supported relative paths, that way files on the same host/domain can reference each other relatively, and you don't have to worry about a changing domain breaking things.

@npolys
Copy link

npolys commented Aug 1, 2024

See ISO X3D for a Web-ready semantic (fallbacks etc):
https://web3d.org/documents/specifications/19775-1/V4.0/Part01/components/networking.html

@yankscally yankscally added the old is this still relevant ? label Jan 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new spec old is this still relevant ?
Projects
None yet
Development

No branches or pull requests

5 participants