add transactions
# Reputation System Design
+## Transactions
+
+Needs can have an interaction with each other and at some point engage in a transaction. For instance this could be initiated by an agreement between the Needs. Ratings could be applied to these transactions if the Need owners agree on that.
+
+## Certify Transactions
+
+To avoid fake transactions in order to avoid fake ratings there should be ways of validating a transaction. This could be done by trusted third party services that could have a look into (some data of) the connection between the Needs and check if the transaction is a valid one. For instance it could verify that there was a real transfer of money between the two partners. The trusted service could then create a certificate about the validity of the transaction, e.g. stating the amount, the date, domain of the transaction. The trusted party could be paid for its service.
+
## Rating Format
Since we want to support interactions between Needs from arbitrary domains we do not want to restrict the rating format upfront.
@@ -18,6 +26,8 @@ One of the major design choices of the reputation systems architecture is who sh
### Public Rating Data
+One idea is to make rating data public to everyone in the network.
+
### Private Rating Data
## Counter-Measures for Attacks and Manipulation
