These are chat archives for highfidelity/hifi
Please join us at our official forum: https://forums.highfidelity.com/c/development High Fidelity is an open source virtual world platform. We are building the software with a mix of full-time developers, part time developers who are paid on worklist.net, and open source collaborators. As use of the virtual world grows, Worklist will also host paid projects run by other teams. https://worklist.net
@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.