On Sun, May 28, 2006 at 06:40:28PM -0500, Andrew McMillan wrote:
>On Sun, 2006-05-28 at 04:54 -0700, Steve Langasek wrote:
>>On Sat, May 27, 2006 at 04:47:20PM -0500, martin f krafft wrote:
>>
>>>I imagine an improved protocol for the keysigning, which is based on
>>>an idea I overheard after the party (and someone mentioned it in the
>>>thread): instead of the everyone-signs-everyone approach, it might
>>>be interesting to investigate forming groups (based on connectivity
>>>statistics) such that everyone's mean distance in the web of trust
>>>can be increased by a fair amount in a short amount of time. At the
>>>same time, such circles could be used for education by those with
>>>high connectivity (and thus much experience). The problem here is of
>>>course the somewhat unreliable attendance of people. Comments
>>>welcome.
>>
>>I agree that this is the way to go. Who has time to work on implementing
>>the necessary code?
[Sending to -devel only]
I just talked to a friend who is an expert in mathematics (Senior
Lecturer of Deakin University, Melbourne). He said the problem is
a discrete programming problem and could be represented as a
classical problem with a known solution algorithm. He will futher
look into this problem.
I'll do the coding of the optimization program (with his help).
>It is something that has been discussed before, and it was certainly
>something that I was discussing with Anibal after the keysigning.
>
>The concept that Anibal and I were discussing post-keysigning was as
>follows:
>
>(a) Order the list of keysigning participants by centrality.
>
>(b) Decide on a group size for the keysigning. Something around 10-15
>seems likely to be a worthwhile choice.
>
>(c) Allocate partcipants to the groups in a round robin following
>centrality order and starting with the most central.
To allocate participants in each group we'll use the optimization
program to improve the mds of all ksp participants.
>Produce the keysigning list, with group numbers in addition to the key
>numbers (or perhaps instead of).
>
>All of the other pre-keysigning activities are the same.
>
>At the keysigning, the initial reading out of MD5 / SHA1 of the
>keysigning list would still happen, as it normally does.
>
>After this, the keysigning would follow two parts:
>
>Part One
>========
>
>People split into their assigned groups and cross-sign only within those
>groups. The intention is that these groups are small enough that
>everyone can see everything that is going on. Experienced people can be
>observed performing comprehensive checks, and inexperienced people can
>be educated.
>
>Part Two
>========
>
>Optionally, after part one is complete, some people may choose to
>personally and individually participate in keysignings outside of their
>assigned groups. Note that this can still be facilitated by the fact
>that both individuals have their fingerprints within the keysigning
>list.
The group of "Part Two" could consist of people with the lowest mds
and people who want to participate in keysignings outside of their
"Part One" groups.
>======
>Finito.
>And gradually it fades out.
>
>
>Rationale
>=========
>
>Keysignings stop being fun ways to meet people after about 15 minutes.
>For me, the worst experience was in Helsinki, with around 300 people,
>getting sunburned in a carpark.
>
>Keysignings are about improving the web of trust. The most efficient
>enhancement of the web of trust will be if the edges exchange keys with
>the middle. Signing keys with _everyone_ is inefficient, unnecessary
>and promotes competitive behaviour rather than trust relationships.
>
>Keysignings should promote education of WoT best practices, and not
>_worst_ practices.
>
>Keysignings should not take more than one hour.
>
>
>So that's my 2c.
>
>
>If people agree that this would be a useful approach, I am willing to
>undertake to provide some additional tools within the signing-party
>package to make such a keysigning more easily doable.
>
>Of course the above does not address how to handle the people who didn't
>manage to get their act together soon enough to be in the initial list.
>There are several ways to deal with this also:
>
>1) The "additional list" is produced, SHA1'd, read, but these people can
>only participate in "Part Two" above.
>
>2) The "additional list" is produced.... and these people are also
>allocated to groups in round robin, but randomly, rather than in
>centrality order.
Or we could use the optimization program to allocate people in the
"additional list" to the small groups.
>and no doubt there are other ways to deal with it...
>
>
>Regards,
> Andrew.
>
>PS. Please feel free to CC me on replies, since I am not subscribed to
>Debian Devel and I _do_ have sane procmail dupe filters :-)
>
>-------------------------------------------------------------------------
>Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
>WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
>DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
> Be different: conform.
>-------------------------------------------------------------------------
Best Regards,
Aníbal Monsalve Salazar
--
http://v7w.com/anibal