#70 Idea: Watchdog

Open
opened 1 year ago by sarah · 1 comments
sarah commented 1 year ago

One of the open problems we have is how peers find and choose cwtch servers and detect bad servers. Here is the barebones of an idea to solve part of that problem:

  1. Each peer runs a watchdog system which is a set of peers and group that randomly communicate over a server. The watchdog system runs in the background and periodically checks that all the watchdog peers are seeing the same group communication.
  2. If the watchdog finds a discrepancy they mark the cwtch server with a lower score - over time the peer has a list of servers that have a history of trust.
  3. The watchdog cycles through new servers, but always watches the servers that are being used by current groups.

Watchdogs could also determine stats like server latency.

How peers find new servers is still an open question. I think an open directory might be a way to go, but has obvious issues some partially mitigated by having a watchdog in place.

Also, what’s kinda cool about this approach is that we can build both parts as Cwtch applications.

One of the open problems we have is how peers find and choose cwtch servers and detect bad servers. Here is the barebones of an idea to solve part of that problem: 1. Each peer runs a watchdog system which is a set of peers and group that randomly communicate over a server. The watchdog system runs in the background and periodically checks that all the watchdog peers are seeing the same group communication. 2. If the watchdog finds a discrepancy they mark the cwtch server with a lower score - over time the peer has a list of servers that have a history of trust. 3. The watchdog cycles through new servers, but always watches the servers that are being used by current groups. Watchdogs could also determine stats like server latency. How peers *find* new servers is still an open question. I think an open directory might be a way to go, but has obvious issues some partially mitigated by having a watchdog in place. Also, what's kinda cool about this approach is that we can build both parts as Cwtch applications.
gpestana commented 1 year ago

How would you define “bad servers”? Based on the paper, I assume servers which selectively often fail to relay messages and modify relayed messages. Also servers with high latency, maybe?

The watchdog idea sounds quite reasonable and is similar to protocols which do computation verification through sampling. I think one of the biggest challenges would be how to limit the request overhead to servers, which in the worst case scenario could result in some sort of DoS. The overhead is not that large, but maybe its something that should be considered if the servers are publicly available and everyone can verify.

How would you define "bad servers"? Based on the paper, I assume servers which selectively often fail to relay messages and modify relayed messages. Also servers with high latency, maybe? The watchdog idea sounds quite reasonable and is similar to protocols which do computation verification through sampling. I think one of the biggest challenges would be how to limit the request overhead to servers, which in the worst case scenario could result in some sort of DoS. The overhead is not that large, but maybe its something that should be considered if the servers are publicly available and everyone can verify.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.