I am planning at least making one NXT "1" clone. I also do not have and cannot obtain source code for Android full node , which is pretty amazing btw, if I remember correctly, but I don't want my clients involved on that level anyway. But, so my android wallet would only be a WebView leading to one node. I would want some nodes hidden to make part of the blockchain invisible from some other parts (selection of nodes), and visible to only some "core nodes" to reduce the "attack surface". These 'core' nodes would liaise between public and private node selections.
For example if I run a node in Docker on a server at an ISP, and no one from the "public peers" receive signals their address broadcast is hidden, if that's possible, only some nodes who have public and say hidden/private node connections, no one would know that there are blockchain nodes on that server Docker container not the ISP, not the public, not even many peers in the "public peers" or "private-peer = no" category.
And how can you attack something you don't know exists? It's impossible.
Like, if there's a tree in a forest and there is no one around to hear it, does it make a sound?
Only on some nodes (that say, connect "public" and "private/hidden", i.e 'core nodes') those hidden peers are in the nxt.properties files with its specification, user permissions preventing access from all except the user running that Docker container, and those nodes serve as a relay between "private" and "public" nodes, theoretically. I am not sure I am making sense.
But I was thinking about another problem, of having in android, as the WebView URL, several webaddresses, with if (no HTTPS response); then (go to next ip address); for wallet. Because this webapp WebView is not a full node (because it's only a WebView on a phone pointing to one ip to access the wallet GUI/API), and then if your one WebView URL is attacked or too much traffic and no HTTPS response, then at least the WebView can query another option in the WebView URL list of options. But this would be another subset, of "WebView" wallet nodes, from the "public nodes" set, for example. However I am not technically capable of that, but thought I might save $15 and not need CloudFlare protection for all my nodes, by hiding their responses in the API etc. If it is possible, so no one can see them, only the person who runs them and the "core relay" nodes between "private" and "public" nodes. Why do I want this also is because I am literally broke and can't afford $15 for CloudFlare because I lost all my money from cryptoland, and am too sick to work or be useful really, I was trying to think of a cheaper way to reduce or avoid attacks if some spiteful people wanna destroy my blockchain, and improve uptime, but I don't know if my ideas are valid.
I'm aware that WebView "node selection"(multiple nodes in an if statement as the WebView URL) with HTTPS response checks to relay the user to an ip with an API that is responding to the URL HTTPS response check request statement, can be made visible by reverse engineering the apk, but maybe a further mix-up can be made, so that there is not just such a (static) list/set of "wallet-public nodes" testing HTTPS responses to guarantee uptime - without outsourcing to Cloudflare for Round Robin -, but a mix up too so that the timing of a node's uptime for login via the WebView app is limited - once you login, your WebView to that specific (URL address) won't close for the one device, but the URLs in the background process on the android changes to another list of IP addresses excluding the one IP you are currently on which is only being used temporarily in cache or volatile memory, which can be cleared from your phone also in the android app/ apk, so that, if you logout and log back in you would most certainly or if you are very lucky you may not, unless the previous is excluded, go to another wallet API login server, while the WebView URL has already been overwritten with another, even bunk(fake/unusable) address while you were still logged in, until you request a new one when you open the app again, later .. more ideas for trying to get more protection because those ip address options in the WebView URL could for even more obfuscation and anonymity of the blockchain, be called from a file or script on one of "those" (or other) servers, each which again could even be firstly, just servers with their own file/process receiving updated IP addresses from servers with dynamic addresses, of unique "wallet-now 'public' " servers for the webapp to choose from after testing them for HTTPS response, and login to, and after login, logging in triggers again that process of randomly selecting a server with a process receiving a list of possible dynamic IP addresses for GUI/API login , which are tested HTTPS responsive positive, mixing the possible GUI IP addresses, and so they are changed while your login instance still runs on the selection you made in temporary ram, as I've already said. So there are a bunch of information relay servers who are sending push notifications also, to your webapp refreshing their IP status when they change. So this new webview URL address being pushed to your phone is not a lot if data/bandwidth. Or in other words, it firstly mixes some sites that each run a script that provides a list / different lists, of wallet GUI/API ip addresses from servers thatbemit to these info relay servers, their new and current IP address, and returns the result, randomly selected from all HTTPS response positive IP addresses as the encrypted finalised WebView URL for that instance only on that device which you are then directed to in the WebView so that you can login to the node wallet there, and it goes to offer another finalized URL, a bunk or real one maybe not sure, after you login because you're running in volatile ram on that connection while logged in while the file is overwritten with a different IP address as the "official WebView URL" while you're not even using it anymore as you're in RAM/cache in the previous IP address, overwritten with a new address, which you are not on and won't use in this logged in instance. I mean if you could run servers that have dynamic IP addresses sending out signals to these WebView "relay processing servers," who themselves send with push processes their own new dynamic IP address,... to give them their new ip, so that you connect only during that window period and then the WebView URL is "officially" changed. It would still send info to your android, because you have a connection to that server open through certain ports even though its i.p has changed, but it can inform itself of the new address and relay that to your WebView URL and update it (so you can send to it also,) in the volatile ram or cache or wherever this process is running, while at the same time another new (not necessarily valid at all valid alternative displays/ is written into /as the WebView URL, but is not connected to, while you are on the previously selected and changing dynamic IP server. Because then you are running on that process of that server even if it has renewed its address while you are on it. Such a situation could create havoc for anyone trying to hack or invade privacy. I don't know if I'm wrong, or if it's possible, or if I'm making sense, it's too late at night and I did not mean to type so much.
And it could be encrypted to only go to that one device (the selected, HTTPS response positive tested IP, for the GUI/API) - it selects an ip, and connects you to it while the possible HTTPS responding ip list changes/shuffles, excluding the one you're logged into, and the IP address of the server you are on changes randomly and you don't lose connection even if it changes its ip, because it is sending signals to your device and can inform your device of the change /new address so that you don't lose the connection and can keep sending signals to it/ the "new address", etc? And all of this wiped from cache on the phone when logging out as part of the webapp?
Sorry I'm not a real programmer but it's interesting and I wish I could actually program or try to implement such ideas, but even if I could I would still need feedback to say if it works or why it won't work, etc... also it's very late I hope I made some sense, thank you.
