From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes/reputations
Date: Monday December 11, 19100 @ 13:31
Author: fen
CVSWEB Options: -------------------
Main CVSWeb: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi
View this module: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations
-----------------------------------
Update of /usr/local/cvsroot/openprivacy/htdocs/notes/reputations
In directory openprivacy.org:/home/fen/projects/openprivacy/htdocs/notes/reputations
Modified Files:
requirements.txt
Log Message:
added nym creation
*****************************************************************
File: openprivacy/htdocs/notes/reputations/requirements.txt
CVSWEB Options: -------------------
CVSWeb: Annotate this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?annotate=1.5
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.5&content-type=text/x-cvsweb-markup
CVSWeb: Diff to previous version: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt.diff?r1=1.5&r2=1.4
-----------------------------------
Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.4 openprivacy/htdocs/notes/reputations/requirements.txt:1.5
--- openprivacy/htdocs/notes/reputations/requirements.txt:1.4 Fri Dec 8 17:40:38 2000
+++ openprivacy/htdocs/notes/reputations/requirements.txt Mon Dec 11 13:31:59 2000
@@ -1,16 +1,25 @@
-$Id: requirements.txt,v 1.4 2000/12/09 01:40:38 fen Exp $
+$Id: requirements.txt,v 1.5 2000/12/11 21:31:59 fen Exp $
Reputation Server Requirements:
=== top level feature list ===
+Pseudonym (nym) creation and maintenance
+ nyms are created and attached to profile segments to ensure anonymity
+ parent nyms create children nyms for which they may later claim responsibility
+ authentication mechanisms must exist to verify data ownership
+
Database features (insert, select, delete)
+ define data format specification
define selection criteria (query) constraints
provide query mechanisms for standard data mining interfaces
when and how does this calculation span peer reputation servers?
define retrieval set format
define exceptions
define admin features, such as size, number of objects, etc.
+ some exaple methods:
+ putReputation(object, reputation)
+ rep = getReputation(object) // exception thrown if no reputation found
Object validation
does the object that was grafted to still exist / has it changed?
@@ -19,8 +28,7 @@
Sorting, ranking
results may be returned ranked according to local server rules
enhance the object with high billing or additional local reputation if:
- the signature/content/object has high reputation according to the
- local agent
+ the signature/content/object has high reputation according to the local agent
Reputation calculation (may require peer communications)
given an object, return its full reputation
@@ -40,6 +48,19 @@
if it is found to be too biased, unreliable, or random
server reputation gain will occur when:
good results within some particular domain are regularly retrieved
+
+=== ontology / meaning ===
+
+Support reputation by ontology/semantics. Systems can define their own
+vocabulary which can be used to markup reputations. (reputations will try to
+become standardized)
+
+=== security ===
+
+Third parties can not forge opinions or spoof other users
+(since Reputation data is based on public key certificates)
+ http://slashdot.org/comments.pl?sid=00/12/06/0126224&cid=157
+ http://slashdot.org/search.pl?query=perens&op=users
=== Optional ===
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST