Hangout is available here: https://bitsharestalk.org/index.php?topic=12106.msg163527#msg163527

Delegates should have monitoring tools to self-diagnose network and node issues. I agree getting pinged by a fellow delegate is a nice thing if the monitoring tools fail, but it doesn't seem to be adequate for production-level financial systems IMHO.

I have started to develop such tools, you can find them here: https://github.com/wackou/bts_tools
and my delegate proposal to help me fund my time to further develop the tools: https://bitsharestalk.org/index.php?topic=11857.0

hree are on a mysteriously named 0.4.26 (with missing v)

that's probably because those delegates publish version manually instead of using the wallet_publish_version command (I used to do it this way too before realizing it's much easier to call wallet_publish_version)

If all delegates were on the same fork, it would be 100% participation - obviously some delegates are on a different fork(s).

I don't think it's a fork, it looks like it's much worse than that, my (wild, uninformed) guess is that the network is completely stalled because someone published a transaction which is now invalid according to the new rules, and no delegate is able to include it in a block and sign it (as all of them are on 0.4.26).

I was talking with Fuzz recently and he mentioned his desire to publish a slate of delegates, however he doesn't have a delegate himself to do that and asked me whether I could help him figure it out. Preferably, this should be possible to integrate into the mumble chatroom so people could just click on a link there. After giving it a little bit of thought, I came up with those potential solutions:

• the dev team enhances the current bts:// url scheme to allow multiple delegates at once
  
  At the moment, one can create a link bts://<delegate-name>/approve, which will open the GUI wallet and approve the delegate whose name is in the link. That only works for one delegate at a time, though, but probably it would be very easy to extend this to something like bts://approve-slate/delegate1&delegate2&delegate3&delegate4
  
  PROS:
   - easy, barely no setup required
   - no delegate required either
  
  CONS:
   - approves all the delegate at the time of clicking, but doesn't change approval if Fuzz updates his slate later
  
  
• Fuzz gets a delegate, only to publish a slate (ie: doesn't try to get elected)
  
  This would be the more "standard" way of doing it
  
  PROS:
   - uses standard delegate slate publishing methods
   - he can update his slate, and people that have him approved will vote for the updated slate
  
  CONS:
   - people need to use "vote as recommended" (not the default option)
   - people need to have him approved in their wallets, which means there's a risk that he ends up becoming an active delegate
  
  
• This message from Toast:
  
  https://bitsharestalk.org/index.php?topic=12020.msg158784#msg158784
  
  But I'm not sure I really understand what this entails (this probably sounds like the best solution in the long-term, though)
  

Any other ideas/thoughts about what would be the best way to do this?

I believe that this would go a long way towards solving voter apathy, and surely there are some low-hanging fruits that can be picked to ensure that it is as easy as possible for people wanting to publish a slate to do so, and for shareholders that trust a community figure to just "follow" their votes.

This will also be integrated in the latest version of the tools which I intend to publish in a couple of days

Note that it is already available on github master, for those who prefer to get it from there

if somebody DDoS attacked all seed-nodes simultaneously (the IP address of them are public)
in a situation like yesterday with the fork problems (it could be an attack-scenario from a group of bad/evil delegates also in future...)
what would happen then? How would delegates manage to resync the chain after the update?

Someone that is still connected to the network would just have to post their IP:port and then people could add this node manually (using network_add_node). A bit more cumbersome, but not really worrying. Also, the more seed nodes become available, the harder it is to DDoS all of them at once, given that they are usually contributed by various people all over the world

And what would happen if yesterday somebody DDoS attacked our bitsharestalk forum?
How would we get to consensus about the minority chain fork, without delaying to much cause luck of communication?

That would be much more annoying... I think the key word here, both in the case of seed nodes and communication channels is: redundancy. That's where this thread comes into play: https://bitsharestalk.org/index.php?topic=11749.0

Try DDoS-ing Skype (Microsoft) or Gmail (Google)