# Reputation Data Types | CRUD Operations

*For more Reputation Modules [see this url.](https://sacred-capital.gitbook.io/sacred-capital/documentation/technical/reputation-data-types)*

*Design is in keeping with principles of modularity that are [discussed here.](https://hackmd.io/@TJSptuQkSdWyLgQxZrAUGg/S1RSmuptU)*

Reputation Modules are designed as separate DHT's that can bridge into any existing app. This allows a community to pick which reputation module is appropriate for them and choose between specific features.

For example, a community can swap out a 'likes' module and instead decide to incorporate 'claps' or 'upvotes/downvotes' based on how they wish to articulate culture within their collective.

They do so by picking a DNA template, and adding their community's unique identifier in the 'properties' field to spin-off a new DHT.


## Reputation Likes

**Entry Creation:**
- Only 1 'like' per user per base entry allowed.

**Read:**
- No of likes given by user: Retrieve Entries that match AgentAddress of the user who generated the like.
- No of likes received by a Base Entry: Retrieve Entries that match the UID of the Base Entry
- No of likes received by a user across all base entries? (Will need bridging)

**Update:**
- Not relevant

**Delete:**
- Only user who generates a like can delete
- Can the owner of Base entry also delete? (Will need bridging)
- when base entry is deleted, like can be removed by non-author
- need to be able to verify that base entry is deleted. When reputation is a separate DNA, we can only do that reliably by directly bridging into base entry's DNA.
- looks like a nice use-case for signal/slots: we could've subscribed for base entry deletion in another DNA. But this is just a dream about functionality that doesn't yet exist :)

Notes for UI Development:
- Calling the like function when a like already exists deletes the like.

## Claps

We consider the case of 'each clap designed as separate entry'. Later sections will consider no. of claps created as fields in a struct.

**Entry Creation:**
- Upto 'n' 'claps' per user per Based Entry allowed at any given point of time.

**Read:**
- No of claps given by user: Retrive Entries that match AgentAddress of the user who generated the clap.
- No of claps received by a base entry: Retrieve Entries that match the UID of the Base Entry
- No of claps received by a user across all base entries? (Will require bridging)

**Update:**
- Not relevant

**Delete:**
- Only user who generates claps can delete
- Can the owner of Base entry also delete? (Will require bridging)

Notes for UI Development:
- Calling the clap function when a clap already exists increments the count of claps.
- Calling the clap function when max no. of claps has been reached results in no action.

## Upvotes/Downvotes (Similar structure works for a spectrum of Emojis, or a rating system)

We consider the case of Upvotes/Downvotes created as separate functions. Later sections will consider Upvotes/Downvotes created as fields in a struct.

**Entry Creation:**
- Either 1 upvote, or 1 downvote per user per base entry allowed at any given point of time.

**Read:**
- No of upvotes/downvotes given by user: Get Entries that match AgentAddress of the user who generated the upvote/downvote.
- No of upvotes/downvotes received by a base entry: Get Entries that match the UID of the Base Entry
- No of upvotes/downvotes received by a user across all base entries?

**Update:**
- Not Relevant

Notes for UI Development:
- Calling the upvote function when upvote already exists deletes the existing entry. Same for downvotes
- Calling the downvote function when upvote exists, deletes the upvote entry and passes a new downvote entry. Vice versa for calling the upvote function when downvote exists.

**Delete:**
- Only user who generates upvotes/downvotes can delete
- Can the owner of Base entry also delete?