> I think building a whole web of trust
> is not necessary for this model.
Not necessary, no. But nice. I wasn't suggesting a full-blown trust
model be built in from the outset. But having (optionally) signed
entries seems easy enough and potentially useful for building such a
web in the future, if needed.
> I'm quite sure people won't generate
> public keys to use their CD player app.
You only need a key if you want to submit signed entries, so most people
would benefit from the cleaner data without having to do anything but
run a trust-enabled client. And people who aren't bothered about getting
dud info occasionally can use a client that doesn't do the trust stuff.
Whether people would generate a key depends how easy it is. If it
just means they have to waggle the mouse for 10 seconds to generate
a nice random number, I think many people will. The more important
question then is will the CD-application writers implement it? Again,
that depends how easy it is. If the reference code does it, it's easy.
> I continue to suggest a simple
> majority on an ASCII match with precedence to the initial entry lacking a
> clear majority.
That would still be a possible mechanism for implementors who don't want
to worry about the trust thing.
What are the dynamics of a cddb entry anyway? Are there typically
many submissions? Or is it only when glaring errors get in that anyone
else submits a correction to the first and only entry?
How does IMDB do it? They must have a similar problem. I suspect they
depend on centralised moderation too.
Robin.
-- R.M.O'Leary <robin nospam at acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK