Domain Server Operation 101 - Words of Wisdom

re whitelists
I believe until HIFI can provide us with the securities we all crave the users who have been asked to shoulder the burden of hosting the community needs to think about creating a shared whitelist system.

Everyone and their dog who wants to can wreak havoc in seemingly endless ways.

Trust is one thing, but the whitelist is the only lock that prevents this proxy shit.

But Judas that would stop new users enjoying the platform.

I think a comprehensive user list can be taken from the forum. Invite only didn’t stop gmail taking off.

The griefing fraternity are likely responsible for HIFIs change of direction, endless bullshit.

Who would go on this list?

Well by and large even the people I don’t like aren’t hell bent on destroying the community and platform.

In 5 years, I’ve only seen a couple.

Is it possible to cut paste a whitelist of names into the sandbox thing?

Is it possible to link a whitelist to a server holding the names?


Flame, this is indispensable! This kind of helpful community provided information is exactly why I love coming here to read every day. I will soon embark on my first domain and you bet I will follow your words of wisdom very closely.

Hap ?;O)


Yes, the ATP is more secure, but it’s also a lot slower. For resources you aren’t too concerned about, it’s best to use HTTP. Also, there is a way to secure content on HTTP that I think can be done with some clever htaccess trickery (using nginx atm so… guess same principal?), but I’m still on the fence about releasing that trick yet (can’t reveal all the cards in your hand).

Well, in regards to whitelists, I meant Script whitelists. Access whitelists are a whole other matter, but I do agree that it’d be interesting to have some better tools like account age (assuming not anonymous).

I should have more typed up a bit later.

1 Like

I would also add, never run a domain server on a computer where you have sensitive/personal information, i.e. your normal day to day use computer.

Why? Simple.

As with any server, you could be running code that could be exploited giving a remote user access to things you would not want accessed.

Consider the number of exploits leveraged for software that’s both widely used and actively hardened (apache, openSSL etc etc etc), yet, still exploited versus lesser well audited software, which this certainly is, and you may see that your exposure might be greater than minimal.


And remeber, if your not using it turn it off
like the devs do
saves the enviroment and prevents the accidental creation of a community


Someone I know was specifically complaining about how bad the Linux build issue was. Apparently the Windoze edition of hifi relies on things that come as standard parts of Windoze, or that just install readily straight out of the box into Windoze without you needing to do anything beyond that to then compile and install HiFi interface and stuff from the current sources. To have the HiFi system on a Linux box, or at least on the fairly common version of Linux that person was using, you have to install a lot of bleeding-edge stuff onto it that break or change stuff under the hood of the current version of Linux. Basically, so s/he was saying, you had to convert your Linux into some experimental version of it and THEN try to compile HiFi on it, and s/he wasn’t interested in converting their regular desktop machine over to that bleeding-edge-experimental Linux MERELY to pop in at a HiFi meeting… since that Linux machine is the regular, primary desktop machine s/he does most, mundane things on, and installing all the needed stuff for it would break too many things on that machine.


I completely agree. It’s been a hard push to get that all going, but in the case of Interface on Linux… yeah, have fun with that. Part of it is due to VR incompatibilities, but as per the last meeting, it seems finally High Fidelity got their act together and realized that having a better desktop experience is pretty important just as having a good and better VR experience is.

I would say canny it but… dear god, I’m starting to get tired of hearing that.

Anyhow, this topic will mostly focus on server operation. Interface stuff would be best suited to someone who actually builds Interface, which isn’t myself. Also, building the Windows version requires similar sorcery because of their love of environment variables. Seriously, it’s annoying.

Anyhow, will have a few more updates for the guide shortly.

Yeah, but the point s/he was making is you had to change a bunch of stuff in the kernel of Linux before you could compile and run the Interface, while in WIndoze you just had to install a bunch of stuff to compile Interface. And s/he doesn’t want to run Windoze.

What distro are they using? I didn’t have to do any of that when compiling back then, and that was in Fedora!

The LTS version of Ubuntu, apparently.

edited to add:
I went back to my chat logs with them, and pretty much what they said (I have corrected a few typos here and there) was:

“I am not wanting to back port to Ubuntu 16, it doesn’t compile on Ubuntu 18, vcpdu cant even see its own config files, they are using bleeding edge libs and built tools that no packages are available for, everything has to be custom compiled, even qt and python. I am not breaking my system for it to work. I have no idea why they insist on using bleeding edge, when windows forces them to use stable for those versions, its obviously not required else it would’nt run on 16.”

Disclaimer: I know nothing about Linux, other than I’ve occasionally poked LiveCDs with a stick, and I have an ancient turn-a-machine-into-a-netpliance distro running as my email machine, so really personally have no real knowledge of the voracity of the above comments, I’m merely passing it on to you guys to examine, FWIW, YMMV, not valid where prohibited by law, and if it leaves a buildup, on ANYthing, I’m coming back for a refund.

It honestly isn’t that bad. I use Ubuntu 18.04, and it does not take that much work to compile hifi. To be honest, it doesn’t sound like she’s followed the build instructions, which point you to a hifi package for Qt, and tells you which dependencies to install from Ubuntu’s repos. To be fair, the docs are not well maintained, but those docs get you most of the way there. vcpkg pulls and builds anything more exotic for you during the CMake step and some extra environment variables will get you a release version.

Under no circumstances should setting up a build environment for High Fidelity break anyone’s system.

Q if the linux people all love linux so much why dont they agree on and compile a version and share it?
A cos theres 1.2 billion versions of linux and they cant agree which one they should use

i use windows cos "££%% U

I use windows because linux is a bug pain and torture with hard and software. Something simple like a secondlife viewer where already a drama. I bet hify is 70 times worse.

And not sure uf steamVR works on linux. And then all the windows programs i payed for nit work on linux. and…

Well you get it,

Please note this discussion should be referring to the server builds and operation of them. Interface is an entirely different beast itself and I won’t dismiss the issues it presents for Linux, but I would like to keep the focus on servers and how to operate them.

This is super helpful, thank you for writing this up. I run a few domains but am not very tech savvy - I use the whitelisting feature to control people’s access to my domain but am unfamiliar with how to put a script whitelist in my domain. You’ve made it clear this is important so I want to do it immediately, I could use some guidance here, thanks!


First, open your domain-server’s page and click on Settings -> Entities.

Then click on Advanced Settings.

Scroll down and you will find “Entitiy Scripts Allowed from:” which is the script whitelist.

There you go!


Thanks so much. I guess I should have also asked a follow-up question: currently, in my settings it’s blank, meaning, I think, that anyone can paste scripts into entities on my domain, which I now understand is not a good idea. So what should I paste in that area to prevent that?

Effectively, anything. It can be ClownPenis.fart. Just note that if you have ANY scripts in the domain, not including the website the script is from will remove the script. In the above screenshot, scripts from will work fine but scripts from say will not. If you don’t have ANY scripts in your domain, then using a website that doesn’t exist will prevent any from being used.

1 Like

Aha! Now I get it. Thank you!

T: 212-991-8344

I’ve updated the guide with the latest oven for download. Shameless plug, but please vote to just have the oven itself be available for download or just include it in the client for content creators.

Make The Oven Its Own Download