From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes/reputations
Date: Tuesday December 12, 19100 @ 23:55
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-serv21518
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.28
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.28&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.28&r2=1.27
-----------------------------------
Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.27 openprivacy/htdocs/notes/reputations/requirements.txt:1.28
--- openprivacy/htdocs/notes/reputations/requirements.txt:1.27 Tue Dec 12 23:40:22 2000
+++ openprivacy/htdocs/notes/reputations/requirements.txt Tue Dec 12 23:55:38 2000
@@ -1,21 +1,24 @@
-$Id: requirements.txt,v 1.27 2000/12/13 07:40:22 burton Exp $
+$Id: requirements.txt,v 1.28 2000/12/13 07:55:38 burton Exp $
Reputation Server Requirements: top level feature list
+(kab) FEN: do we really need this here? seems like shameless self promotion.. :)
+
"The OpenPrivacy Platform enables a distributed, secure marketplace
for anonymous user demographic and profile information."
A. === Definitions ===
An agent
- can receive requests and return responses
+ can receive requests and return responses (defined in
+ primary-agent-protocol.txt) should be merge it??
has an internal state and possibly access to an internal datastore
can examine its state
can initiate communications with peers when programmed conditions are met
A reputation server is an agent that can
respond to reputation requests
- such as 'putReputation(URI, rep)' and 'rep = getReputation(URI)'
+ such as 'setReputation(URI, rep)' and 'rep = getReputation(URI)'
A broker is a reputation server that has added intelligence for some domain
Note that a broker may not serve reputation information to others,
@@ -26,11 +29,17 @@
1. decentralized, peer-to-peer
a. agent => reputation server [ => broker ]
-
+
+
2. a reputation can be attached (grafted) to any URI
a. all reputations are URL-addressable
i. all reputations can have reputations grafted to them
-
+ ii. since a reputation can be grafted to a URI... it can also work for
+ conventional non-networked resources (books, cars, etc)
+ iii. it is only 'possible' that a reputation may be addressable, an
+ agent/computer resources can not be certain that a given reputation
+ server holds the value it needs... Reputation server reputation can
+ grow based on this.
C. === Security, Authentication, Privacy, Validation ===
Key:
@@ -77,7 +86,7 @@
D. === Data store facility ===
1. Data store features to support:
- a. putReputation(URI=object, XML=reputation) // insert
+ a. setReputation(URI=object, XML=reputation) // insert
b. reputationCollection = getReputation(querySet=???) // select
i. define selection criteria (query) constraints (XML...)
ii. provide query/matching mechanisms (XQL/XPATH?)
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST