Idea: Watchdog #70
ラベル
ラベルなし
applications
BLOCKED
bug
design
duplicate
enhancement
fixed?
funding-needed
help wanted
infrastructure
invalid
payments
qubes
question
ready-for-implementation
refactor
spam
tapir-server
testing
tor
wontfix
マイルストーンなし
担当者なし
2 人の参加者
通知
期日
期日は未設定です。
依存関係
依存関係が設定されていません。
リファレンス: cwtch.im/cwtch#70
読み込み中…
新しいイシューから参照
説明はありません。
ブランチ "%!s(<nil>)" の削除
ブランチの削除は恒久的です。 実際に削除されるまでの短い期間、ブランチが存在したままになることもありますが、たいていは元に戻すことはできません。 続行しますか?
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:
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.
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.
With the tokenboard server approach, key signing and ideas around trust-providers I'm going to close this issue in favour of exploring these ideas in technical reports/research papers on this topic in the future.