On Friday 30 January 2009 01:13, xor wrote: > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Matthew Toseland > > Sent: Thursday, January 29, 2009 12:33 AM > > To: [email protected] > > Subject: Re: [Wot] r25270 - trunk/plugins/Freetalk > > > > On Wednesday 28 January 2009 18:40, xor wrote: > > > > > > > -----Original Message----- > > > > From: [email protected] > > > > [mailto:[email protected]] On Behalf Of Matthew > > > > Toseland > > > > Sent: Wednesday, January 28, 2009 5:44 PM > > > > To: [email protected] > > > > Subject: Re: [Wot] r25270 - trunk/plugins/Freetalk > > > > > > > > On Wednesday 28 January 2009 10:30, xor wrote: > > > > > > > > > > > -----Original Message----- > > > > > > From: [email protected] > > > > > > [mailto:[email protected]] On Behalf Of Matthew > > > > > > Toseland > > > > > > Sent: Wednesday, January 28, 2009 1:43 AM > > > > > > To: [email protected] > > > > > > Subject: Re: [Wot] r25270 - trunk/plugins/Freetalk > > > > > > > > > > > > > > why keeping two uri ? > > > > > > > > I guess the getURI() always return the empty chk > > > > "CHK@", right? > > > > > > > > > > > > > > > > > > > > > > getRealURI() returns the CHK uri of a message. > > > > > > > getURI() returns the URI of the message list in which the > > > > > > message was > > > > > > > listed > > > > > > > + "#" + the UUID of the message. > > > > > > > > > > > > Aka the ID of the message? Which needs to be unique? Is > > > > it a viable > > > > > > attack to use somebody's messages, change the crypto key, > > > > and thus > > > > > > get the same ID, and clobber the original messages? > > > > > > > > > > Yes it is the ID and it has to be unique. It is constructed as: > > > > > a random UUID + "@" + routing key of the author identity SSK. > > > > > > > > > > If someone changed his routing key to match someone else > > > > then he could > > > > > not insert under that routing key because he does not know > > > > the private > > > > > key, right? > > > > > > > > > > So if the attack you are talking about was possible > > then SSKs in > > > > > general were attackable if I am right? > > > > > > > > Assuming you only include your messages in the message list. > > > > I thought we were going to support relaying other > > people's messages > > > > if there is free space? > > > > > > That will be impossible with CHK message URIs because the are not > > > signed. There are major complaints on FMS about that fact. > > > > > > I thought you had considered this when you told me that messages > > > should be inserted as CHK... > > > > > > I cannot think of any solution. > > > > > > But I have the opinion that including other people's > > messages is not > > > so important anyway because it would be a risk: If you rely > > on person > > > Y that he includes ALL messages of person X then you won't > > poll person > > > X messages anymore so Y might be a evil and leave some of them out. > > > So to fix the risk you would have to poll the messages of X anyway. > > > Then it is useless if Y relays them and we do not need relaying > > > anyway. > > > > Not necessarily. If we consider scaling, all we need is the > > notification that we should poll identity X, no? > > What would you make that notification look like? By making the message > list of Y also contain the highest known edition number of the message > list of X?
We've discussed this on IRC; the current proposal is to include in the message list as many as possible of these triples: identity : latest message list edition : recently posted to boards > > If so, doesn't the network itself already have some mechanism for > spreading the latest edition of an USK? Message lists will be USK! > If the network spreads their edition numbers already we will not need > trust lists to do it maybe? No, not an efficient one. We do need to improve USKs, however I doubt much will happen before 0.8.0, certainly not before the beta, because it's client layer stuff, which is all tied up with db4o at the moment... In the future we will implement hierarchical DBRs to help with finding the latest edition of a USK (especially if you've not polled it in a while). Obviously ULPRs and whatever other passive-request-like-thingies can help here, but there are scaling issues with WoT/freetalk even then: we cannot have every node on the network polling the output queue of every other node! > > Please everyone help thinking about this issue, it is important to > find a decisision what is best for the network.
pgp9wiZGU2mcv.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
