From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes/reputations
Date: Monday December 11, 19100 @ 14:23
Author: burton
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:/tmp/cvs-serv16292
Modified Files:
requirements.txt
Log Message:
...
*****************************************************************
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.10
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.10&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.10&r2=1.9
-----------------------------------
Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.9 openprivacy/htdocs/notes/reputations/requirements.txt:1.10
--- openprivacy/htdocs/notes/reputations/requirements.txt:1.9 Mon Dec 11 13:49:30 2000
+++ openprivacy/htdocs/notes/reputations/requirements.txt Mon Dec 11 14:23:07 2000
@@ -1,16 +1,16 @@
-$Id: requirements.txt,v 1.9 2000/12/11 21:49:30 fen Exp $
+$Id: requirements.txt,v 1.10 2000/12/11 22:23:07 burton Exp $
Reputation Server Requirements: top level feature list
"The OpenPrivacy Platform enables a distributed, secure marketplace
for anonymous user demographic and profile information."
-A. == general ==
+A. === general ===
1. decentralized, peer-to-peer
e.g., Freenet, perhaps like an extendable DNS
-B. == Security, Authentication, Privacy, Validation ==
+B. === Security, Authentication, Privacy, Validation ===
1. Pseudonym (nym) creation and maintenance
a. creation of identity I (public/private key pair)
@@ -35,7 +35,7 @@
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 ==
+=== Data storage ===
Database features (insert, select, delete)
define selection criteria (query) constraints
@@ -53,20 +53,21 @@
putReputation(object, reputation)
rep = getReputation(object) // exception thrown if no reputation found
-== sorting, ranking, calculating ==
+=== 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
- the price(mojo)/KB, availability, speed, similar content types,
- feature set (e.g. does it support query), etc. meets set levels
+ 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 known reputation components
as a set of object grafts
- as a merged value
- facility for 'blending' reputation results from multiple sources
+ as a merged value (computed via a bias)
+ facility for 'blending' reputation results from multiple sources. (kab)
+ This is used in the data calculation to merge Opinions into a Reputation.
Local garbage collection, editing, enhancement and censorship
A reputation server can sweep its objects and, based on local criteria:
@@ -74,14 +75,15 @@
the signature/hash is no longer valid
the signature cannot be validated (purely anonymous)
the signature belongs to a low-reputation source
-
+ (kab)this would normally be a system optimization on the server
+
Note the many possibilities for a local reputation server to affect results
server reputation loss will occur when:
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 ==
+=== Communications ===
communication encapsulation specification
contains:
@@ -94,13 +96,13 @@
(e.g., UDP, SMTP, ICQ, Carrier Pigeon, etc.)
-== ontology / meaning ==
+=== 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
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST