Hi @Wolvenmoon Z :), yes please to those helm files. Always keen to learn something new, so looking forward to seeing what you have been working on and learning how they work to boot.

Ok, with respect to your suggestions, all very welcome and great feedback. Makes our lives somewhat easier to have real feedback from users as it stops us from wandering far from the path of good design.

1. Sounds like a good idea on the face of it. We're planning on replacing the current connection system though, which would hopefully either eliminate the manual connection step, or put it into an advanced mode where/if circumstances required a manual setup approach.

2. Another part of this redesign process would mean that clients would be listening, meaning you'd only need to configure a routable path to the client machine. Also since in your case the nodes would effectively be requesting from behind a NAT, then you would likely not have to configure anything since NAT's are designed to map outgoing requests to incoming replies without any need for intervention from the user.

3. We tested this and it worked, I was lucky enough to have someone in Switzerland setup a public IP that forwarded to their render server, they setup DNS and I was able to enter a URL into crowdrender as the name of the render node and it connected and rendered just fine. Of course the tricky part was setting up the correct port forwarding, we use 9000 - 9025 so those ports needed forwarding.

In the future these issues should mostly be taken care of and we'll be carefully considering whether we need to even have an advanced mode where you can control how things work with regards to the network.

If you have ideas, comments or even criticism, would love to hear them :)

James