While on my morning commute, I was discussing with @Medhue about the
implications on content protection through a marketplace and monopolization
in the earlier thread
I had a sudden conceptual idea for content protection that would placed on
the file hosts them selves and would maintain the open source nature and
web based interaction.
I’ll flesh this idea over time, but generally watch this space:
Changed domain ID to to public address of the server.
The concept works with the following idea:
- Each cached request for assets must provide in the header the following:
- the UUID of whoever placed the object / or whomever the entity is attached to. (“HiFiEntityOwner”). Should not distinguish if attached / entity in world.
- Name of domain where the entity is at (“HiFiDomain”)
- Public Server Address where the entity is at (“HiFiDomainAddress”)
- Hash of Domain’s secret time based value (randomly generated salt and pepper scheme), “HiFiDomainAddress” and “HifiEntityOwner” (“HiFiHash”)
- If said agent is guest (not logged in, and has been able to somehow
add entities) or has changed avatars, the agent uuid is provided
as empty or null uuid (0).
- The asset provider’s backend may use this information to
check if it wants to provide the file to the user or not. (The Rules can be set by backend),
- Each Requests respects cache-control settings.
Privacy concerns; this information must NOT tell what account was used to load up the model.
Granted, ** every modern day web request already have ip addressed in each request,** but we should not be provided with info on what account was used to load up the model (as far as we know, it could have just been a proxy address).
If the backend doesn’t do anything with this information, it will work like it currently does.
As header information is used, and is standard to http(s), the header check logic these can be written using any backend language
As an example, the authentication could, for example work in the following manner: (the asset host should be able to decide)
- Receive Request. Check if from Hifi interface client.
- Check if owner uuid is valid (which ever method, through database ownership, or just simple validity check)
- Do a request to HiFiDomainAddress. Send Owner and Domain UUID, Should get the same hash result back.
- Do a validity check with the request hash and the retrieved hash from the domain.
If everything goes through, allow access to the asset data. Else return 401.
This entire shake should happen within 250ms, which considering the potential file sizes should be small enough.
This would mean people can also create their own storefronts / Third party marketplaces, and overall be them selves responsible for the rights on the content they provide.
The Concept of “Your own” and “inventory” would have to be revised though: Inventory would be more of a list of bookmarks of objects.
- Allows for multiple marketplaces and for direct vendor - consumer relations
- Continuing the Decentralization: Does not rely on a single marketplace, avoiding of monopolisation / will encourage competition. If one asset service fails, only content from that service will not show.
- Allows for gameplay building and rewards from domain owners / host cooperation possibilities with domain/cross-domain specific entities that only work within those domains (preview?) and maybe open up as rewards to be used elsewhere. Wearable Achievements
- Basic Item Rights can be managed from where the assets are hosted.
- You cannot rez the object without the rights from the asset host - Licensing through host.
- Revenue possibilities for Hifi: If not using secret key from domain, use API requests to domain check, or DRM validation could be charged via tiers after an # amount of requests per domain uuid request per length time.
- Content creators do NOT have to apply this unless they want it
- Protection will proves intent of piracy if content is copied elsewhere. instead of “Oh I didnt know”.
- Could be basis on how the marketplace works - Maybe even extend on this that the marketplace is the metaverse marketplace from which you can go to vendors and other marketplaces that fit ones interest? Maybe even blur the line between the metaverse and the web?
- Analytics : How many times has an asset been loaded, and in what domain? instead of just how many times loaded. Vendors could then maybe market more to / for those domains.
- Throttling: Throttle free stuff hogging up server bandwidth, one could throttle their views per domain to save bandwidth on server end. or limit use to a domain. This could make sure no one can DDoS an asset provider.
- Requires backend or service if vendors want this protection. While due to technical limitations for some, most will still be sticking to Hifi market (Hifi should provide also a hosting service for that).
- Currency is harder to force due to fragmentation
- Even if decentralized requires an API from hifi for validation checks. This api would be the achilles heel. If this api fails and the asset server relies on it, then content is not visible, although asset server could skip validation if api gives a specific error related to unable to serve the hash.
- Starting out could be costier for business for setting up the lookup API;
risk of getting too many requests from some asset providers, especially if providers dont cache.
- Relies on the performance of where the content is hosted at to do the communication quickly
- Throttling - Could be used against end-users and domain holders. (I wont let user X or Domain Y use my products because waah) this is especially dangerous if a provider gets too big. Maybe an EULA for the API could avoid this sort of thing?
- It requires end users to trust that the service/vendor:
- That vendor has the rights to sell content and keep providing content as is.
- Does not turn against the end users or domains where the end users are in.
- It doesn’t stop piracy, it only makes it a way more difficult (you need a specialised client, and know the owners and uuid of domain), proving intent if stuff is copied (but easier to chase, web hosts dislike illegal stuff on their servers, hosting direct assets is not as grey as hosting links to assets.) .
- Privacy issues: Vendors have logs of where the asset is present in and who placed it there.
- Permanence - like with current issue with a single non hosting marketplace, if server hostong content goes down, content on that server will be gone until links are established again. But this issue same as with the web. We will run into issue of content permanence as time goes on as content can expire.
- Time Sync Issue not all time on machines is synced, might be off a second, time hashes would be done every minute or so.
- ** Cache Ghost** if user has seen a valid model, using the url allows them to see it locally, but cached. This could be fixed by the cache still doing a header request. The instance for the file should be reset if an 406 (“Not Acceptable”), or 401 (“Unauthorized”) response is gotten, then the model should be forcefully discarded from cache.
Additionally The Hifi Marketplace should also be configurable to send specific requests to a configured url, if a purchase has occured with the purchaser’s uuid. (No name info. only uuids for some anonymity)
Asset server - web host where the assets are hosted at. Does the decision of whether or not to serve content
API - Application Programmable Interface. Used by other application and services to do exchange data. In this case for check
DNS - specifically HIFIs version of DNS. Otherwise known as Domain Name Service. Handles linking of names to server uuids. Could also provide an API for security checks.
Domain server - the domain in HiFi where the content is shown.
This would only needs a transaction and currency engine from HiFiInc and the requirement of headers in requests.
Whats everyones opinion on this?