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? >> 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 -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
