@emski, @xeroc: about the backbone delegates, I think that ideally they should not all be managed by a single entity (me, or whoever else) for obvious decentralization reasons, similarly to why they shouldn't be run on the same VPS or in the same geographical locations. The more diverse, the better. (@emski: I did see your post yesterday, but considering the time I invested in making the webpage--not my biggest skill--I decided to keep it anyway
)
However, it is a good idea to have a public place to list all of those seed nodes/backbone nodes, so that they can either be included by default in the client, or that people can easily add them manually. I can offer to host such a list on my server, or maybe we could code it and then have svk host it on bitsharesblocks (excellent job on that btw, svk, bitsharesblocks seriously rocks!). The list would be updated in realtime and show the status (online/offline) of each node.
In the concept of backbone nodes they also need to be connected in a fully-connected graph, so having a central place listing those nodes helps the backbone nodes to know who their peer nodes are and maintain live connections to most of them.
or maybe you just connect your 'hiding' nodes to each other and your delegate only interacts with hiding nodes YOU control
I thought about this, but it somehow feels fragile to me, as if your relay nodes are down for whatever reasons then your delegate becomes isolated. Unless you have a
lot of them for a single delegate, in which case it seems a bit wasteful. I believe that it should be possible to create a network which has a topology that allows both efficiency and security for the delegates, in a public way. My backbone node is a proposal towards that goal, but we can probably do better.
@emski: I remember your post about ddos prevention, I had a similar wish to hide the delegates at the time and it inspired me to keep thinking in that direction, as I see this as something that should be (relatively) easily achievable, and would provide perfect protection.