Sort:  

I think I liked @joshman's lottery system for curation better.

Without other incentives after removing that window, I could see content agnostic voting because you make the same either way.

Downvotes aren't used that often as it is. Only a small group of people do utilize them on regular basis.

As long as curation rewards exist there is no negative for stakeholders to autovoting. Even if the curation rewards become linear, it will still be a much faster method for similar returns.

The consideration would be n2 which would only reward the largest stakeholders when actual vote stacking takes place. But that hurts smaller stakeholders and makes curation rather unattractive to them. Also, we have over the last four years seen that people are creative when it comes to discover optimized earning methods. Reintroducing super linear would most likely lead to voting pools, where the larger stakeholders vote in a randomized order to spread the rewards fairly among them.

Ideally we need a system that offers manual creation an advantage over automation. I had an idea about penalising vote clustering by burning a percentage of the curation rewards for votes cast within a short period of time. An automated voting service could distribute the votes more evenly to avoid the penalties. However, deciding which votes to cast at what time could be a problem for an automated system.

Vote clustering penalization sounds like lots of collateral damage. When to vote isn't a big issue, if outside of the frontrunning window or in a world without frontrunning (linear curation rewards). So it would be relatively trivial for an automated service to spread out votes in batches of max. 5/minute.

So you would have to resort to a dapp whitelist system through which votes are favored (not penalized) but that doesn't really fit a decentralized world. In a layer 2 rewards world this would be easier to achieve as decentralization is less of an issue in the token management aspect.

In a world with vote stacking, autovoting services could create pools/tiers where users pay to be in one of the earlier tiers, before the next whale. Or randomize the position of whales, max. one per tier and balance the stacked earnings that way. This would obviously only be of benefit to orcas and whales in a stacked world.

The main thing is, as long as the rewards for curation exist on the base layer, autovoting will have an incentive. Even if only time won (perfectly linear world). If the solution is penalizing, you will trigger a game of cat and mouse. Where whether you overdesign thousands of use cases to prevent/penalize or are always a step behind because you counter the actually encountered cases. IMHO that's the least sensible option, also because it takes away focus from actually designing token utility.

I think we will have to live with autovotes but we can help define when the votes happen and also if we continue to live in a world tailored to those caring about their rewards from "tapping a button" (or automation). Given last year's evolution I tend to think the move away from 75/25 was bad. Linear plus 66.6/33.3 (compromising numbers, ain't I nice lol).
This still wouldn't do away with automation or curation sniping whales, but it would lower the incentive.

We could afterwards experiment whether to add a curve which rewards heavy stacking but would kick in only on very highly rewarded posts (in a months long live simulation). Gaming this would be more difficult because of available downvotes if crap content is heavily rewarded. On excellent content, and I mean truly superior creation, there would be an incentive for orcas and whales to stack and make it truly worth the effort for the creator(*). If that fails due to collusion, then we know the actors are corrupt and don't care about anything else than their returns.

In a layer 2 rewards world, all this becomes a non-issue and the responsibility of each token creator/team.

(*) It wouldn't be that hard for a decent to coder to develop a script which trawls the chain for those super high rewards, but there wouldn't be too many of those. At least not yet with the current userbase.