From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes/reputations
Date: Monday December 11, 19100 @ 13:27
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:
updating with greater detail
*****************************************************************
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.8
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.8&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.8&r2=1.7
-----------------------------------
Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.4 openprivacy/htdocs/notes/reputations/requirements.txt:1.8
--- 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:27:20 2000
@@ -1,26 +1,66 @@
-$Id: requirements.txt,v 1.4 2000/12/09 01:40:38 fen Exp $
+$Id: requirements.txt,v 1.8 2000/12/11 21:27:20 fen Exp $
-Reputation Server Requirements:
+Reputation Server Requirements: top level feature list
-=== top level feature list ===
+ "The OpenPrivacy Platform enables a distributed, secure marketplace
+ for anonymous user demographic and profile information."
+A. == general ==
+
+1. decentralized, peer-to-peer
+ e.g., Freenet, perhaps like an extendable DNS
+
+B. == Security, Authentication, Privacy, Validation ==
+
+1. Pseudonym (nym) creation and maintenance
+ a. creation of identity I (public/private key pair)
+ (may have multiple identities)
+ b. creation of child J (public/private key pair spawned from N)
+ c. ability to sign/encrypt data packet with J[s]
+ d. ability to verify/decrypt data packet with J[p]
+ e. N has ability to create new J as owner of several J data packets
+
+2. Object validation
+ a. does the object that was grafted to still exist
+ b. has the object that was grafted to changed?
+ c. are signatures valid
+ d. are signatures 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 selection criteria (query) constraints
- provide query mechanisms for standard data mining interfaces
+ provide query/matching mechanisms (XQL/XPATH?)
+ 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.
-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
@@ -40,8 +80,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)
+
+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)
-=== Optional ===
+== Optional ==
Support a reputation:// URI namespace based on pet names.
http://www.erights.org/elib/capability/pnml.html. This could provide a
@@ -55,3 +114,4 @@
with the opinion. (Note that this is unreliable, in that the returned set
of 'opinions' is defined by the local reputation server(s).
+Desireable to be censorship-resistant (e.g., Freenet, MojoNation, Publius)
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST