On 16/09/17 08:31, Arne Babenhauserheide wrote: > > Matthew John Toseland <matt...@toselandcs.co.uk> writes: >> The above is slightly inaccurate. For a genuine user, the third step >> starts off as a bundle, then later becomes a broadcast. We enforce the >> scarcity and popularity requirements in both stages. > > Doesn’t enforcing scarcity at the bundle level create information > leakage about the length of the bundle-tunnel?
I don't know? > >>> 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. >> >> For Scarce KSKs to work, as currently designed, the queue needs to be >> *very* popular. So maybe have everyone subscribe to the global queue, >> but new identities only accepted automatically by some randomised subset >> of the graph. Then you need to get some likes or whatever before you can >> be seen more widely. > > That should work, too, yes. > > There could also be multiple different applications listening for the > same queue. It only says "there’s a new key". > >>> This would enable use-cases like automatic newsbots (something I’m >>> sorely missing for babcom_cli). >> >> I don't understand this use-case. > > I’d like to provide users with some amount of autonomous systems who for > example aggregate posts about a given topic. Something like mailing > lists. But for these, they must work without user interaction, but > without opening an avenue for spamming. > > Best wishes, > Arne >
signature.asc
Description: OpenPGP digital signature
