Support

No, it is not possible.

I have presented the technical issues behind such a feature many times in the past. I have also presented many times why IP blocks are only meant as a temporary per-site measure and not as a permanent, across all sites solution. Executive summary:
- IPs can be spoofed, ridiculously easy. Google it. It's trivial stuff for a serious hacker.
- Serious hackers issuing a DDoS or brute force will use distributed client (botnet) rendering IP blocks ineffective
- The performance penalty of synchronsing IP blacklists across sites would have MORE of a negative effect than the attack itself. For each IP in the network you'd need to encrypt the data in the source node and then on each target node decrypt it and parse all IPs / IP ranges in the node to see if it's already blocked. This would have to be performed N-1 times, where N is the number of the nodes. With 5 nodes (sites) and 100 IP blocks each this results in 400 requests which require a hell of a lot of CPU and RAM. Your server would get on its knees and beg for merciful death by means of a reboot. You'd have DoS'ed yourself.
- If you really have multiple sites being attacked on the same server at the same time what you need is mitigation, e.g. CloudFlare (to get the heat of the attack) and an OS level firewall to fend off attacks directly to your server's IP address.

So, if "grow" means expending resources to implement a feature that will have the exact opposite effects that what is intended by the component you can be darn sure I'd rather be in "save" (sic) mode :)

In so many words. If you try to solve the wrong problem with the wrong tools you end creating a bigger problem than the one you began with. I have the experience to recognise it and prevent it. Some other developers either lack the experience or will knowingly provide you with snakeoil security to get your money. It's simple. I chose a side, one that helps me sleep well at night.

Sorry, your level of technical experience prevents you from seeing fundamental issues. For example:

Btw: I dont care about CPU and RAM as in a cloud environment all resources are shared and bandwidth throttling is common behaviour amongst J! hosts.

Don't say this to any system administrator. Seriously. There is no such thing as an infinite CPU. The CPU power you get on a cloud server is capped by the physical server's capacity. When you reach CPU load 10 on a 4-core system (in other words an attempt to use more than twice the processing power of the system) the server (physical or cloud) dies. Just like that. I can easily prove that to you with two run of the mill Amazon instances and ab (Apache Benchmark) trying to open 100 concurrent connections. If you don't understand it that's all right, but don't ask me to do something that ignores this fundamental fact about how servers work based on your false perception, enhanced by cloud service providers' marketing blurb. There's marketing and there's practice. I write solutions which work in practice, not in marketing theory only.

I also don't see the issue of synchronising ip blacklists.

I know you don't. I tried giving you the executive summary. You still didn't get it. Let me explain it.

Each slave node MUST communicate with the master. The master has to check if this IP is in its master list. If not, it MUST communicate with all slave nodes. The slave nodes MUST check that this IP has not already been added to the blacklist. If you skip that last step you will end up adding each IP multiple times, making it impossible to reverse that change. Performance impact:
- Slave to master needs to be strongly encrypted, otherwise an attacker can exploit the sync feature to whitelist himself and blacklist you. The data needs to be then decrypted in the master node. And, no, validation by IP only, sending data in plaintext and other similarly insecure non-solutions are not acceptable. Because, you know, we're trying to make a security product, not an insecurity product.
- Master to slave, likewise.
- IP groking, as explained before

Moreover, there is another fundamental issue you fail to understand. Let's say you have a master node MASTER and 10 slave nodes SLAVE1 to SLAVE10. Let's say that for some reason SLAVE5 becomes compromised (hacked). The hacker can add your IP to the blacklist and his IP to the whitelist. All nodes now synchronise and, what do you know, you are now blocked from all ELEVEN nodes. Check and mate.

If someone likes my idea, perhaps we can develop a php/MySQL sync tool that works on MySQL/ftp basis to sync setups from a J! node to other (external) J! nodes?

It's trivial, yet misguided, to do so.

I will say this again. Writing the code to do that is half a day's work. I could do it. But it will DECREASE the security of your site both actively (opening a new attack vector) and passively (giving you a false impression of enhanced security for all the wrong reasons). This is why I will not write that code.