Domains and Credits


I am trying to get a better understanding of how parts of the system work, I
am confused about some areas, and I do understand that this is in development so I will accept “we dont know yet” as an answer if this is the case.

Can some one please clarify "The High Fidelity virtual world"
Does this describe, -all the domains running and connected to the central authentication server-
or is it -the servers owned and run by High Fidelity, and other domains are separate worlds-?

According to my understanding…
“High Fidelity will offer credits to users to run an assignment client,
this assignment client will lend power to the domain.”

What happens when that client (user) moves to a different domain, say a
private one?
Does the assignment client also shift to help power the domain in which
the avatar persists?
Does the owner of the domain pay the credits? Where do they get the
credits, they cannot generate credits like HiFi.

Will domain owners be forced to pay users from their own wallets?

Can a user decide which domain his assignment client will contribute to?

I have more questions and possibly suggestions but I hope you can help
with these few questions for now.


@adrian I think these are great points. I would assume that the private domain owners would opt-in or simply get additional server capabilities if they wanted to increase their capacity however I would think if they called upon assignment clients perhaps they can set a budget to be distributed in real-time and once that allowance is reached it would rely back on its own capacity. Just thinking out loud.

The assignment client capability is revolutionary and makes Hi-Fi the leading edge VR as it is the only system that will adapt on-demand based on capacity need. As it grows, users grow, assignment clients increase, everyone wins. There is an economy for every user which is also brilliant as everyone has an ability to contribute and reap the rewards.


I think that the most important issue that needs to be addressed in this question is de-linking the user and assignment clients. It is my understanding that an assignment client could not be dedicated to an individual avatar that travels from domain to domain, rather that domain operators will have the option to request additional processing from the “stable” of assignment clients that others are running based on the current processing needs of the domain.

Recent discussions about adding costs to creating / modifying / destroying voxels ( which would be paid to the domain operator based on rates that could be set by that operator ) would imply that domain operators would NOT have to run assignment clients to generate credits. They could use the credits they collect through these charges ( or selling content ) to pay for the additional processing capacities that assignment clients provide.

In one of our Friday meetup discussions @Philip described some additional details…

Assignment clients would be assigned jobs on a random basis… The design thinking is that if a “rogue” client was modified to collect information about the domain it was serving, It would never be assigned enough jobs in a single domain so that it could collect the information required to replicate the entire contents of that domain.

Assignment clients would be interacting in a “marketplace”… That is… Domain owners who wished to pay for the additional processing power would be able to identify and select a client that provided the best local performance. This would prevent the use of an assignment client that might include unacceptable network delays to complete the assigned processing. This seems an obvious advantage to the domain operator, who would want to get support from the “best” assignment client available, however it weakens the [security through randomness] that is intended to prevent a single client from collecting enough details to replicate content…

Assignment clients could be run in a “comparative group” mode… It would be possible to distribute the same task to multiple assignment clients and compare the results of the processing returned. This would support the ability to prevent a single “rouge” client from returning “corrupting/inaccurate” results to a domain.

I apologize if I have mis-stated any of this… Please feel free to expose my mistakes and explain them correctly