[rc5] Re: [rc5-announce] [ADMIN] v3 - SPOILERS OF DOOM!!!

James Mastros root at jennifer-unix.dyn.ml.org
Mon Nov 3 18:27:32 EST 1997


On Sun, 2 Nov 1997, Adam L. Beberg wrote:
> Greetings... As promised it's spoiler time...
> Some of this I've said before, some is new...
> I'll try not to reveal too much of the really good stuff :) seems as soon
> as I announce something these days someone else announces the same
> thing...
Umm...  if your talking about various v3 discussions on this list, I
interpreted those discussions (since I started a couple, I think I can do
that) as ideas to consider in the final v3.  I hope that you take the ideas
floting about on this list into consideration when you relese the draft v3
for peer review (to the list).

> - the v3 protocol supports multiple simultaneous projects to be happening
> with the client able to select from the available clients based on
> integer/floating point use, bandwidth, memory usage, etc...
Cool.  Keep the decision on the client end.

> - N-level proxy networks, for data intensive applications, more levels of
> proxy network allow the handling of high data overheads more elegantly. 
> This also allows you to put your personal proxies right in the thick of
> things, tho they have a completely different function from current
> P-Proxies... 
Cool.  I assume a pproxy is the same as a main-proxy with a higher degree of
seperation from the One True Keyserver.

> - cores will be CPU/OS specific C/C++/ASM to gain all possible speed. Java
> will never be used. Java has it's place, this isn't it. period.
For cores, I almost (but not quite) agree with you.  However, if v3 is open,
then it should be completly the user's choice what language to write the
core in, even java.  (Yes, it is slow as hell, but 1 key is better then 0
keys.  Also, it would make a DAMM GOOD ad.)

> - signed cores/commands... PGP style security model for the code, so bad
> cores don't get slipped in... Cores won't run, and commands won't be
> accepted unless they are signed by a user that's allowed to do so... If
> you don't trust the standard cores, disallow auto-updates, then compile
> and sign your own cores... Note there is no encryption involved, only
> authentication, so our ITAR friends should be OK...

I feel so special!  I also suguest that work should be encripted (yeha, I
havn't said that before - I just came up with the idea).  
That way:
1)  Nobody can steal keys (encrypt with the client id).
2)  Spam and buggy clients won't be signed by the bovine crew, so won't be
    trusted (i.e. blocks with neg returns ruled out) until sombody at hq 
    decides that they are trustworthy.  (Hint: if they start returning HUGE
    numbers of blocks (right away), don't trust them.)

> - I've found several people qualified to participate in the peer review,
> as well as the current coding team, and I have more on my list to contact
> so in a couple more weeks, we should be ready to start coding...
I would LOVE to be on this list... Though I'm not well qualified for the
technical aspect (though I'm hardly a slouch), I think I'm a fairly good
idea man.  Also, I hope that the list-at-large is a part of this peer review.

> - Adam L. Beberg

	-=- James Mastros
--- 
When the annals of distributed computing are written, and the name 'Bovine'
appears in there, I can say "Hey, I was a part of that, I checked .0012% of
the keyspace".
	-=- Brian Wilson <wilsonb at mindspring.net>
Go to www.distributed.net before I come make you!

----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list