Discussion: Architecture of High Fidelity


I am just gonna continue this here. The Blender topic is not a topic for discussion of High Fidelitys Architecture. @Nathan​_​​Adored @subongo @Richardus​.​​Raymaker @summer4me

Continuing the discussion from Ultimate Blender Compendium - Woes of the Blender FBX Export: At the Mountains of Documentation Madness:

True, for the notion of virtual world users not needing knowledge in earlier worlds, but we are not creating a virtual world here, we are creating a Metaverse: its distribution of servers, and multitudes of interconnected virtual worlds; very much akin to the websites of the world wide web. Virtual Worlds tend to be limited to specific services or central asset servers: Forexample SL relies on an authentication server, an asset server, land server, transaction server and each sim. If any of these go down, the entire system simply doesn’t work as intended one gets down times for either the sim, or the entire system.

If the company holding the servers them go down, they will go down, with all the content uploaded to those servers would also be lost (which is a potential outcome, within a few decades (20 years tops) for SL, unless a museum takes all those assets and starts storing them all (thats ALOT of content) ). Or reverse engineered to an extensive degree. In High fidelity, because of the distributed nature, it would only be the content hosted within that server, so the damage would not be as large.

The beauty of Hifi is the fact that it is distributed. So even if Hifis authentication system goes down: you can still connect (semi-)anonymously to a server (if server has to allow everyone) and you can still view content in those systems; because they are not being hosted by High Fidelity: Assets can be hosted elsewhere from the domain, and could be called into a domain by a simple url (this does have its down sides, but I’ve discussed potential solutions here) If Hifis DNS server goes down, you can still connect to servers via direct ip address and Regular DNS addresses (forexample, theden.dyndns-home.com/54.4,609.7,172 leads to my hifi domain: laboratory, while theden.dyndns-home.com/8000.0,200.0,8000.0 leads to my hifi domain of Centre/Center). Transaction(once implemented) servers down ? You can use existing services on the internet to do commercial dealings. Voice is handled per domain, and physics are handled through p2p authentication per client connected. The reliance on Hifi Inc, is actually quite small, but them holding the main services, and marketplace (so far) implementations, and maybe even copyright related stuff, and being the central “nexus” so to speak, they will be the point of entrance to the metaverse, and a valuable place to advertise for the worlds as it would be a place to put a search engine and DNS for the metaverse, (single world address are much easier than .com addresses :slight_smile: ) .

Basically what is being created here, is an entirely new form of application of existing tech, that would nondisruptively work ontop of the existing internet. Its only a matter of getting the boulder rolling fast enough for it to stay, even if something would happen to HiFiInc.

In short:

Unfortunately this does mean, that as of the moment, things are -very- technical for a regular user that is jumping in from another existing platform: its even looks crude and all. But it is shaping up with a potential to be something special to the future.

However the tech-mentality will, eventually change, as entrepreneurs will begin to setup their own asset hosts; but it will require there to be profit to be made for everyone; and we will end up on a chiken or an egg question: which should come first: creators making money, or server hosts making money. It is reminiscent of the very early days of the web: full of bumps, with no “services” available for people to use off the getgo to get started.

So yes; We, the alphas, the trailblazers of the Metaverse; will have to have either the technical knowledge or the willpower and curiosity to learn. We must also have the tolerance to stomach the obstacles we may encounter, and draw the maps and building plans, for the less skilled, as we all travel to our destination.


Well, I definitely like the idea of everything, including the content hosting and presumably even the username registries, being decentralized across several totally independent places. The walled-garden approach to virtual worlds, of which SL is one of the biggest-known, needs to become a thing of the past.


The walled gardens exist because of content protection, though that approach has become old school. Trusted execution and trusted data stores can and are distributed. So long as there is an architecture in High Fidelity that permits establishment of trust chains, then the issues that were once walled off can live spread around.


I wouldn’t say walled gardens exist solely because of content protection. I can remember when AOL was trying to become a walled-garden version of the World Wide Web in about the late 90s or so, and I am quite glad THAT idea died a slow death. Would YOU want to have to log into an AOL account today in order to get at the “good stuff” on the Web? oO


While I disagree with the notion of walled gardens being solely for content protection (it was money and exclusitivity mostly…), but I digress.

About the auth keys, I was actually thinking that the trust chain should be between the domain server, and the asset server (as in, who ever hosts the content). The entities spawned should have information on who of placed the entity, and what server address it is at, and with a hashed version of the key and time sent.

The asset server then calls back to the domain to re validate hashes provided, and then decides to allow access to the content or not using all of the information to display the content or not.

Ive discussed this more at https://alphas.highfidelity.io/t/proposal-add-http-request-headers-to-be-used-for-content-protection/6241


The trust chain cannot just be between an asset server and domain server, though that is an important primary relationship. An asset server needs to know whether the domain is trusted in general, similar to the paths leading to intermediate and root certificates. An asset server may want to know that High Fidelity Inc trusts the domain. Or, it may want to know that some common agency that governs a set of domains trusts them. The reason for this is that data requests can easily come from domain servers not owned by the same person who hosts the assets. Also, revoking trust always comes from up the chain. This is how one stops rogue domains.


I didn’t say walled garden exist solely because of content protection, just that having a walled garden is an easier and oft used way to enforce content protection.


The TOS for the Domain naming could handle the rule sets for rogue domains. You cannot map your domain through the Hifi-DNS if you break the terms.

I only suggested the main method, because its the basis how the authentication works (checks in asset servers against X or Y or both):

A Secondary check can be added to the chain, for-example by also providing the domain name to the asset server in the request. which can be validated through High Fidelitys DNS to resolve the actual address of the server or its interface which the asset server will communicate with.

It will trust that if the domain is in the Hifi’s DNS, then it is not rogue. If Hifis DNS denies having any info on teh domain, then it will return a Not found error.

The primary method would then behave as a back up, incase High Fidelitys DNS is unreachable by the asset server: but all of these rules are enforceable by the backend, but are not necessarily needed, unless you want to utilize the “authentication”.
Or it could also be a shared secret between the Domain and the DNS server.

This way there is also a safeguard, just incase HighFidelitys DNS service is down, so that content can still be displayed.


You said “The walled gardens exist because of content protection, …”

When someone says “X exists because of Y,” that strongly implies “Y is the cause of X.” :smiley:

In any event, people put too much trust in the concept that copy-protection is a necessary and effective way to stop people from pirating their stuff. It brings to mind an anecdote I heard many years ago, talking about the floppy-disk-based gaming market in home computers of the 1990s or so, on machines such as the Commodore Amiga and the Atari ST. There was a small but steady amount of software piracy out there, and so games companies invested in various sorts of disk copy-protection schemes, but software piracy remained the same amount relative to games sales. They kept making more and more elaborate copy-protection schemes, but the pirating of their games still remained exactly the same small but steady amount. They got more and more elaborate and involving with their copy protection schemes, until eventually it dawned on them they were spending more time and effort on making the copy protection schemes than they were on making the games themselves. One day, a games company decided to just place their game out there without any copy protection on it. And the piracy of their game remained the same small but steady amount, relative the number of copies sold. Think about that, even without the copy protection, piracy remained the same amount. It did not suddenly skyrocket because they’d dropped out the copy protection, it remained the same as before!

Copy protection and DRM are overrated. A far better, far wiser approach is to just make sure legitimate copies of the product are easy to obtain (i.e. widely and easily available worldwide) and are of a price the customer won’t complain about, and even some of those who’d otherwise pirate it (since those ones were ones who felt they couldn’t get hold of it any other way) will come buy it. The key here is it has to be EASY and CONVENIENT to obtain, for ANYone who wants to come and get it from you.


[quote=“Menithal, post:8, topic:6656”]
The primary method would then behave as a back up, incase High Fidelitys DNS is unreachable by the asset server: [/quote]

And a time limited cache of that trust could cover temporary outages.