>Actually, a slight modification is needed. Reputation tokens should all go
>under {provider's public key}/{Reputation}/{rater's public key}
>
>I was intending this to be distributed moderation. *Anyone* would be allowed
>to insert a reputation token under the
>{provider's public key}/{Reputation}/ subspace. So, if I had just downloaded
>{Michael ROGERS}/{Metallica}/{Bunny Torture.mp3} and was pissed that I had
>just been tricked into downloading a nursery rhyme, I'd insert a black token
>under {Michael ROGERS}/{Reputation}/{Andy Tepper} to publicly state that
>"Andy Tepper thinks Michael ROGERS's reputation should be punished."
>
>It would be up to the client to interpret the collection of tokens.
Perhaps I chose the wrong phrase in "distributed moderation". The
distinction I meant to draw was between searching only by artist+title, and
searching by artist+title+provider. Ideally you wouldn't have to know the
names of any providers to find a song. So "distributed provision" might be a
better name. But if necessary, named providers can be used. The trust model
should foster a strong sense of community and keep the 31337 happy. ;)
g0 +o fr33net://+h3-dr4g0nz-l41R f0r m3t4l & h4rdc0r3 d0wnlo4dz d00dz!!!
>Of course, the subspace permission language is needed for all of this.
True - at the minimum, simple key-verifying subspaces are needed. But I don't
think we're going to be able to implement a Napster replacement without some
modification to the nodes... which calls into question whether we should be
working on this at all, or just helping to get Freenet 0.3 finished. I dunno.
Michael
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
