Matthew John Toseland <[email protected]> writes: > Specifically, the process for a scarce *insert* will be: > 1) Is the key popular?? We can tell this from how many peers are > subscribed to it in the ULPR table. If not, kill the request; we only > provide protection for popular applications. > 2) Has there been another scarce SSK insert from the same peer recently? > If so, kill the request; they've used their quota. (More complex > conditions are possible; quotas, per-key etc) > 3) Commit the data to the datastore and propagate it via ULPRs. > > So indeed, there is no routing involved here.
This sounds good. > All we do is have a single global Scarce KSK queue for announcements. > Every WoT instance subscribes to it. The key is generated from the date > and changes e.g. once a day. All scarce inserts are propagated to all > nodes - but the scarcity mechanism restricts the number of inserts. … > Every WoT instance adds every identity announced via the queue. Then we > rely on the usual mechanisms to weed out spammers after the fact - some > combination of positive and negative trust, backed by the fact that it's > relatively costly to create new identities. This misses part of the point of WoT: WoT only lets you be seen by a small group at first and when you get positive trust you get seen by a wider group. However a solation which keeps the resilience of WoT active could be built on top of what you describe by not having one global queue but rather N queues with each ID trusting one of the queues chosen at random. Every day you choose another section to watch. N could be chosen by taking the size of the WoT into account. This would enable use-cases like automatic newsbots (something I’m sorely missing for babcom_cli). Kudos! Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
