From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes/reputations
Date: Monday December 11, 19100 @ 13:56
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:
reorganized and added info from ../research.txt
*****************************************************************
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.6
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.6&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.6&r2=1.5
-----------------------------------
Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.5 openprivacy/htdocs/notes/reputations/requirements.txt:1.6
--- openprivacy/htdocs/notes/reputations/requirements.txt:1.5 Mon Dec 11 13:31:59 2000
+++ openprivacy/htdocs/notes/reputations/requirements.txt Mon Dec 11 13:56:33 2000
@@ -1,34 +1,53 @@
-$Id: requirements.txt,v 1.5 2000/12/11 21:31:59 fen Exp $
+$Id: requirements.txt,v 1.6 2000/12/11 21:56:33 fen Exp $
-Reputation Server Requirements:
+Reputation Server Requirements: top level feature list
-=== top level feature list ===
+== Security, Authentication, Privacy, Validation ==
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
+Object validation
+ does the object that was grafted to still exist / has it changed?
+ are signatures valid/reputable?
+
+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
+
+Note: the reputation server intranet will be secure in and of itself.
+ Getting data in and out of the system securely is not part of this spec
+
+== Data storage ==
+
Database features (insert, select, delete)
- define data format specification
define selection criteria (query) constraints
- provide query mechanisms for standard data mining interfaces
+ provide query/matching mechanisms
+ that support 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?
- are signatures valid/reputable?
+Standardized data format specification
+ and standardized data store API
+
+some example methods:
+ putReputation(object, reputation)
+ rep = getReputation(object) // exception thrown if no reputation found
+
+== sorting, ranking, calculating ==
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
+ the price(mojo)/KB, availability, speed, similar content types,
+ feature set (e.g. does it support query), etc. meets set levels
Reputation calculation (may require peer communications)
given an object, return its full reputation
@@ -48,21 +67,27 @@
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
+
+== Communications ==
+
+communication encapsulation specification
+ contains:
+ capability you want to use (e.g., via a URI to a schema or DTD)
+ payload (data conformant to the data format spec)
+ session key (e.g., a pseudo-random number)
+ some sort of TTL-like value (e.g., Freenet's hops-to-live)
-=== ontology / meaning ===
+works with any message-based asynchronous data transport mechanism
+ (e.g., UDP, SMTP, ICQ, Carrier Pigeon, etc.)
+
+== 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 ===
+== Optional ==
Support a reputation:// URI namespace based on pet names.
http://www.erights.org/elib/capability/pnml.html. This could provide a
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST