On Fri, Jan 30, 2009 at 9:13 AM, xor <[email protected]> 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?
>
> 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?
>
>
> Please everyone help thinking about this issue, it is important to
> find a decisision what is best for the network.
>
What will be useful to me:
- A USK@ update that really works.
(ideally, it should work even if it is hundreds of editions behide)
- Clean up the subscription API (for plugins)
-- unsubscription
-- subscription using FreenetURI (I think freenet.keys.USK
is some internal implementation that shouldn't expose...)
- Subscription via FCP
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
