FIP 3: Upvote support

[denisnazarov]

Abstract

Upvotes allow users to express their support for specific posts. It is a common feature on social networks to showing popularity counters and rank content. Upvotes are a foundational signal to power future recommendation algorithms on FEEDweave.

Specification

Upvotes can be implemented as a generic Arweave data app with App-Name: upvote, so other Arweave apps can reuse the functionality.

Here is a sample transaction that would upvote the FEEDweave tutorial post with transaction ID 47zeUWFxruVhf9l-IZpxw-I7No7up2wSGekw7gQFwhE.

{
  "tags": {
    "App-Name": "upvote",
    "Target-Transaction": "47zeUWFxruVhf9l-IZpxw-I7No7up2wSGekw7gQFwhE",
    "Action": true
  }
}

Submitting a transaction with "Action": true will represent the act of upvoting. Users can undo their upvote with a new transaction with "Action": false.

To tally up upvotes, clients would query transaction by App-Name: upvote and a specific Target-Transaction hash.

Clients or gateways should filter out duplicate upvotes.

Further discussion

Because Arweave apps use cryptographic identity, it would be easy for attackers to create many accounts with small AR balances to try to game upvotes. Strategies should be considered to prevent sybil attacks.

One idea is to consider the reputation and post history of an upvoter before considering their upvote as legitimate.

Clients and gateways can implement their own strategies to ward off attackers.

[LeGaryGary]

I would say we could use a similar system to AskWeave where you upvote by tipping a quantity of AR, however, this comes with the problem that those with the most money get their posts seen which promotes inequality in the system as it would no longer show popularity but who has the most money. A fix could be to de-duplicate upvotes AND have a set cost to upvote which is checked when tallying. This cost could be something like 0.1AR or something defined in the target transaction