Usually that's modeled in the application layer. In scuttlebutt you'd store a higher-level state as one of the node-specific parameters. The gossip protocol doesn't need to know that you know the node knows it's about to die, though there are optimizations to be made there.

Despite what the sibling commenter claims, in a production system you absolutely need that distinction -- not in terms of the reliability of the low-level protocol, but in terms of the application features you want to expose. A node about to be removed needs a chance to drain active connections.

Then you have to differentiate between accidental and intentional death. Much more robust not to make that distinction.

Depending on the need, it can be implemented on client side as well as on chitchat. We actually thought of this feature as a way for a node to normaly exclude itself from the cluster (maybe for application update). We are still evaluating how necessary this is because a node crash or normal shutdown can just work. Future experience will surely tell us.

I forgot to reference the issue https://github.com/quickwit-oss/chitchat/issues/30