These are chat archives for highfidelity/hifi

Jun 2016
Jun 25 2016 09:26

@jherico sorry it took a while to respond, I've been tied up with other stuff. Yeah, I know it's ambitious, but frankly I think that's why it needs to be done now, and in phases. It can't be done all at once, and it does need to be done. As someone who used to work on RealXtend, and is currently doing several side projects in Unity, I can safely say that a proper EC system is vital. As for the hard coded numeric value, I would suggest from a security perspective that instead of assigning hard coded, the component ID should be a salted md5 hash of the component name, with the salt and component name stored in plaintext in a database with the ID. Normally, security people suggest staying away from MD5, because it's easy to crack, but I don't think that HiFi needs SHA3 (which would be much slower) for component names. For passwords and the like, bcrypt/scrypt or bust, with the ability to upgrade as needed, but for this, you don't need that.

I would suggest storing on a master server, possibly as a blockchain (yes, I know, zomg blockchainz, such hype, much buzzwords, very wow) or a nosql database a list of various entity component types with their appropriate salts and hashes and names. Sync that between clients/servers as needed, and as new component types are created, check against the master to see if a hash collision exists, and if it does, recalc the salt and hash.

Allow component designers to upload their new IDs to the master as needed, having each component possibly prefixed by the username/group of the author in a separate field as a pepper that is brought in addition to the salt. Essentially you are creating an option to upload custom Identifiers, which are allowed to be edited by that user/group which owns it, but if you want to keep it private, or in dev because it's not ready, you don't have to upload to master, you can keep it local or on a private chain/db tied to your instance/server.
Not exactly a perfect 1-1 example, but this gives an idea of what a pepper is:
Another example, from ArmA, which I occasionally mod, is we use script/class names that prefix author/group_blablabla
The prefix is it's own database value, based on author group or username, depending on who owns it according to the settings
if a user is in that group, and has permissions, they can edit it if it is the group that owns it.
Jun 25 2016 09:32
admittedly it sounds like hell for performance, and improperly implemented, it would be, but the hash is really only used to ID the type of component, and that's all it's used for.
Think of it as a more complex ID system based instead of on an enum and incrementing, but rather a hash.
A bit more complex, and a little more over the wire, but not much.
I've been doing a lot of thinking on the entity component implementation, Artemis probably isn't the best choice.
still reading up on the bitsquid approach though, so my idea is subject to change
Also, read up on the thing involving porting qtwebkit to qtwebengine, that would be a really good call from a security perspective if the underlying chromium is kept up to date
Jun 25 2016 09:42
also, if I am right in interpreting steamworks being added to hifi as a move to get hifi on steam, this is a REALLY DAMN GOOD CALL.
To be blunt, I only stumbled upon hifi by chance. Had I not done that, I would have thought altspace was the only one in this space. HiFi really needs better publicity and promotion.
To be blunt, I am infosec by trade, but VR has always been a passion of mine. Right now I'm working on finding work in the infosec space to pay bills, but ultimately I want to be securing VR/AR/MR. I see that as the next generation interface/comms method, and if we don't get it right from the start, we will just repeat the mistakes made over previous cycles.
Mohammed Nafees
Jun 25 2016 16:02
Re: How exactly do I enlist all the entities?