From: cvs@openprivacy.orgCVS update: openprivacy/htdocs/notes/reputations
Date: Wednesday December 13, 19100 @ 12:37
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-serv23204
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.30
CVSWeb: View this file: http://openprivacy.org/cgi-bin/cvsweb/cvsweb.cgi/openprivacy/htdocs/notes/reputations/requirements.txt?rev=1.30&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.30&r2=1.29
-----------------------------------
Index: openprivacy/htdocs/notes/reputations/requirements.txt
diff -u openprivacy/htdocs/notes/reputations/requirements.txt:1.29 openprivacy/htdocs/notes/reputations/requirements.txt:1.30
--- openprivacy/htdocs/notes/reputations/requirements.txt:1.29 Wed Dec 13 00:18:33 2000
+++ openprivacy/htdocs/notes/reputations/requirements.txt Wed Dec 13 12:37:09 2000
@@ -1,11 +1,14 @@
-*- indented-text -*-
-$Id: requirements.txt,v 1.29 2000/12/13 08:18:33 fen Exp $
+$Id: requirements.txt,v 1.30 2000/12/13 20:37:09 burton Exp $
Reputation Server Requirements: top level feature list
-(kab) FEN: do we really need this here? seems like shameless self promotion.. :)
-(fen) KAB: yes, I think this helps for the time being to keep the page focused
+(KAB) We need to put in a requirement that all J/Ps have Public Keys.
+(KAB) We should start breaking this down into a specification document.
+Requirements should be something like a database, that we dont' worry about this
+problem. The spec should be that we need to implement X feature and document how
+we will do it.
"The OpenPrivacy Platform enables a distributed, secure marketplace
for anonymous user demographic and profile information."
@@ -13,31 +16,40 @@
A. === Definitions ===
An agent
- 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
+ - can receive requests and return responses (KAB: 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
+ - (KAB) communications with an agent will eventually become a new facility.
+ Certain agents might in the future have their own language of communication.
A reputation server is an agent that can
respond to reputation requests
- such as 'setReputation(URI, rep)' and 'rep = getReputation(URI)'
+ such as 'setReputation(URI, rep)' and 'rep = getReputation(URI)'
+ (see UML)
A broker is a reputation server that has added intelligence for some domain
Note that a broker may not serve reputation information to others,
- but it needs to be capable of reputation operations to do its work
+ but it needs to be capable of reputation operations to do its work
(brokers are generally outside the scope of these requirements)
B. === General ===
1. decentralized, peer-to-peer
a. agent => reputation server [ => broker ]
-
+ b. agents aren't programmed to one reputation server, the server to connect
+ with is dynamically determined (based on load, price, reputation, etc)
2. a reputation can be attached (grafted) to any URI
a. note URIs can reference non-networked resources (books, cars, etc.)
b. 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.
[(kab) 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
@@ -86,16 +98,21 @@
i. http://slashdot.org/comments.pl?sid=00/12/06/0126224&cid=157
ii. http://slashdot.org/search.pl?query=perens&op=users
b. each server maintains at least one I[s] used for intra-server communications
- i. requires trust of key management facility of server's administrators
+ i. requires trust of key management facility of server's
+ administrators (it is possible that users could compromise the
+ machine at which point its private key could be exposed, this is
+ another reason why reputation servers need their own reputation.)
c. intra-server communications can be signed and encrypted
Note: Getting data in and out of the system securely is not part of this spec
+(KAB) Fen... this is a requirement document. Gettind data in and out IS a
+requirement.
D. === Data store facility ===
1. Data store features to support:
a. setReputation(URI=object, XML=reputation) // insert
- b. reputationCollection = getReputation(querySet=???) // select
+ b. reputationSet = getReputation(querySet=???) // select
i. define selection criteria (query) constraints (XML...)
ii. provide query/matching mechanisms (XQL/XPATH?)
that support standard data mining interfaces
@@ -131,7 +148,11 @@
desirable for providing meta-info for additional payloads.
c. technically any XML data could be stored in an 'reputations' based XML
repository. XML Signature will probably be used more often.
+<<<<<<< requirements.txt
+
+=======
+>>>>>>> 1.29
3. Standardized data store API
a. (XML...)
@@ -155,7 +176,7 @@
i. as a set of object grafts
ii. as a merged value (computed via a bias)
b. facility for 'blending' reputation results from multiple sources
- i. may be used to merge 'Opinions' [into a 'Reputation' (kab)]
+ i. may be used to merge 'Opinions' [into a 'Reputation]
Note the many possibilities for a local reputation server to affect results
server reputation loss will occur when:
@@ -180,12 +201,18 @@
c. session key (e.g., a pseudo-random number, or perhaps the J)
d. some sort of TTL-like value (e.g., Freenet's hops-to-live)
- (kab) I think a lot of this is in 'primary-agent-protocol.txt'... should
+ (KAB) I think a lot of this is in 'primary-agent-protocol.txt'... should
we just migrate this document into requirements...? I think so.
3. works with any message-based asynchronous data transport mechanism
a. e.g. UDP, SMTP, ICQ, Carrier Pigeon, etc.
+4. Remote proxy support. A facility is needed to buffer a users
+ profile/reputation store (anything that can be communicated) for sites that
+ don't support peer-to-peer network communication. This is basically any host
+ behind a firewall, NAT, etc.
+
+FIXME: need to define Phase I first.. :)
G. === Phase II ===
1. Support reputation by ontology/semantics
@@ -212,6 +239,10 @@
determine a reputation for an object which is not currently part of the
Sierra reputation system.
+3. Add support for a higher reputation lookup... possibly based on price.
+ Facilities like Mojonation will supply this but it isn't necessary for first
+ cut.
+
H. === Wish list ===
1. Ability to verify calculated results by requesting the 'opinions' which were
@@ -219,4 +250,4 @@
with the opinion. (Note that this is unreliable, in that the returned set
of 'opinions' is defined by the local reputation server(s).
-2. Desirable to be censorship-resistant (e.g., Freenet, MojoNation, Publius)
+2. Desirable to be censorship-resistant (e.g., Freenet, MojoNation, Publius).
This archive was generated by hypermail 2b30 : Mon Jan 22 2001 - 15:52:14 PST