Matthew John Toseland <matt...@toselandcs.co.uk> writes: > On 12/09/17 22:34, Arne Babenhauserheide wrote: >> >> Matthew John Toseland <matt...@toselandcs.co.uk> writes: >>> But we need *something* in this approximate area. >> >> I fully agree with that. I think however that we need to be careful not >> to require user interaction for that. Users already added the friend, we >> can’t require more than maintaining the friend connections. Otherwise >> that would be the next bottleneck. > > What makes you think we'd need user interaction?
That’s how I understood it. > If there is any deconfliction it's all at the client level, not the > node. The client can enforce any appropriate rules and decide to cast a > vote by reinserting the block it most prefers. The user might get > involved if there's a dispute about e.g. eliminating spammers. I don’t understand how the client casts votes without exposing the data it uses to decide how to vote. How do you avoid coupling private data with the insert decisions? > Proposal 0: Bundles > ------------------- > > If an SSK insert has maximum HTL, we pre-route it along a fixed > pseudo-random path, which ideally doesn't change for a given source > node. It only uses friend connections, and stays at max HTL until a > pseudo-random termination point (always the same node on a static > network). After that it turns into an ordinary insert. Do I understand it correctly that this means that all inserts from a given source initially travel along the same path? If yes, then it sounds good. > There are tricks we can use to compensate for churn by using shadow > nodes so that even if we can't route it to fixed peer A, we route it to > fixed peer B instead, but the following hop is the same (possibly using > FOAF connections and proof of previous arrangements and whatever). That sounds like quite a bit of additional complexity but a nice longterm goal. It would be great to have this for requests, too, since this would clearly stop most correlation attacks which are used right now. > Proposal 1: Scarce SSKs with global (per-node) scarcity > ------------------------------------------------------- … > Proposal 2: Scarce SSKs with per-key scarcity and multiple versions > ------------------------------------------------------------------- … > Proposal 3: Scarce SSKs with voting > ----------------------------------- … I don’t really understand these three. They all sound like they could leak information from the anonymous ID layer to the networking layer. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
