Now, distributing the share of the vote over all votes you cast without a VP limit is complicated, it would mean that your past upvotes will become worth less because you are upvoting more which itself is something people wouldn't get easily I guess.
Tbf, I don't know, right now out of my head, a solution for this complexity.

Honestly, it's not really that hard. We already have, in theory, a pool of value associated with you – your SP. We already have mechanisms which act as sliding windows. All the pieces are there to build a sliding window, automatic allocation system which distributes your voting power equally across all elements you voted for in the last cycle.

Let's do a bit of gedanken.

I'm going to throw out some numbers here and they will largely be arbitrary. Specific numbers might be very different, but as a loose idea…

Imagine that you have 100 SP. Imagine, for the sake of argument, that right this moment there are 10,000 SP worth of tokens floating about. The amount of voting power that you have available to steer inflationary value is calculated to be 1%. When you vote for things, that is effectively saying you can direct 1% of the inflationary value to all of the things that you voted for in the cycle.

To keep things relatively simple, let's assume that "a cycle" is seven days long. A cycle is a seven-day sliding window which accumulates your votes and then distributes the value accordingly.

We also have a pool called the inflationary value. For the sake of the arbitrary moment, let's say that it has 1,000 tokens in it. (Things will get complicated very quickly, but that's not our problem at this moment.)

That means that this cycle all of the votes that you have left will distribute 1% of 1000 tokens, or 10 tokens. It doesn't matter what you voted for, it doesn't matter how many things you voted for, it doesn't matter how active you've been – when this update cycle is completed, you distribute 10 tokens evenly across those votes. They could be for your content, they could be for other people's content, theoretically they could even be for groups, organizations, or communities – any entity which can accept tokens.

If we still want downvotes in the system (though I am generally systemically against downvoting), we can simply consider a downvote to represent applying a negative value in your share of tokens – and it can come out of the same inflationary pool value.

So at the end of our arbitrary time for value assignment, let's say you have seven upvotes and three downvotes. You have 10 tokens worth of value to assign, so each of them gets a value of one token, and they are applied to change the amount of the inflationary pool you have control of.

If we want to be clever, at the end of the sweep where values are assigned, if there is extra money left in the pool (that is, people have used downvotes), the money stays in the pool for the next allocation. If we want to be painfully stupid, have to track a lot more extra information, and do it much the way things are currently done, we redistribute all of that extra funding to everyone who didn't receive a downvote from the original voter. This, of course, ends up distributing those overflow funds quite likely to the same people who received downvotes, just on other posts.

Now we have actively decoupled voting from trying to give a price of value to a post. Instead, we are more narrowly focused on directing a portion of the reward pool in directions that we think are appropriate. As a side effect, it becomes much closer to that original idea of "upvote as tip" without actually having to specify a tipping value.

This method is also keeping the vote window separate from the inflationary allocation window. The inflationary allocation tick can occur as often as you like. Once a day, once an hour, once a minute – whatever is appropriate to your level of computational availability (at a system level). The only thing that's important to keep in mind is that the smaller the inflationary allocation tick, the smaller the inflationary value to be allocated.

(That the inflationary allocation actively decreases the effective amount of funds that you can allocate from it as tokens are created through it is left as an exercise for the reader, but it is most certainly true. In our arbitrary example, consider that after the first cycle, the pool as a whole has 11,000 tokens in it – our rate of inflation is ridiculously high. If you didn't vote for yourself and no one else voted for your content, you still only have 100 SP, which will let you direct 0.91% of the pool. This is inherent to all inflationary Proof of Stake voting systems, however.)

So – really not all that complicated. From the user side, they just vote. They interact with content they like or don't like, signal to the system how they feel about it, and the resources that they are able to distribute get distributed automatically. And fairly.

The addition of the ability to "tip" alongside a vote would be nice, and would effectively just make it trivial to send a little something extra to those you thought were deserving of it, and would effectively function just like any other fund transfer on the blockchain.

But everybody understands tipping.

Note that this entirely removes the current mechanisms regarding betting on whether or not you think this thing will get more votes from other people and that alone gets rid of a vast number of follow-on problems. It doesn't matter when you vote, as long as you do – so there's no rushing to be the first, but not too quick. As long as you vote, that vote will matter and that vote will matter equally scaled to your SP. It gets rid of the evergreen problem, because we don't care how long ago the content was created, we just care about whether it received a vote in the last voting window. We don't actually care about what the eventual value that gets assigned to that post really is, because there's no way for us to know ahead of time. All we care about, because it's all we can affect, is how we steer the reward pool.

This specifically doesn't try to deal with issues of whether or not self-loading is a good idea, a social good, or an inevitability. I find those questions boring and ridiculous, so I design systems that just don't care. If you make one vote a day and it's for yourself, fine. That is your power to do, your power to direct, and I don't own your SP so it is ridiculous for me to think that I can tell you what to do with it. It's unwise, because it doesn't actually support more content being created on the blockchain, so you're not helping increase the value of the whole by creating more attractive content and thus bringing in more users who might themselves be interested in voting for your content, but that's your choice.

You'll notice that I have arbitrarily suggested that the voting window be seven days and have simultaneously pointed out that the reward cycle can run as arbitrarily short as you like. Yes, that means that any votes you place will have multiple impacts under this kind of system. That is to say, they will continue to direct part of the reward pool every reward cycle. For the sake of argument, let's say the reward cycle runs once a day. That means any upvotes that you have placed today will influence the next seven reward cycles and direct the reward pool accordingly. That's kind of a big deal because it creates a certain momentum.

You'll also notice that I have completely removed the "curation" system of rewards for voting – and that is by design. You could stick one back in here, with a flat portion of the reward pool set aside to be distributed equally across all voters for the last reward cycle, scaled by SP if you must, but I don't think that under the new description of how voting would actually work that you need to incentivize people to vote. If you feel like you must, take a flat slice out of the reward pool and distribute it to voters in that cycle. Stay away from any system that requires you to worry about sequentiality because that is wasted complication and drives behaviors which are both unhealthy and fiscally unwise.

Something like this actually gives you a voting system which is something more than just a betting system on what everyone else is going to do. Instead, it focuses on "what do you think should be rewarded that you've seen" and has another great, positive side effect that it will inevitably spread the value of votes across a broader selection of content. Removing the betting pool drive of "is this content going to be bad on by other people?" has great, maybe incredible, knock on effect.

I do agree it would be a bit more difficult cognitively, but I also do believe that it is the only way to fix the "game theory" of "upvote/downvote" which actually almost no one seems to get on this platform.

I have spent a lot of time tinkering with the game theory of voting systems, of content discovery systems, of a lot of social media architecture. This is what happens when you are really old (in Internet time) and predate the web so you had the opportunity to see pretty much everything that's happened in terms of social media evolution. Also, I love game theory. I consider it a curse.

Targeting an end value is mechanically difficult and ultimately is going to be an emotionally unrewarding interface, because in almost no situation are you going to get what you want. The vast teeming masses of users on this platform have very, very little influence over the allocation of the reward pool. So saying "I believe this post has a value of $10" or $100, or $1000, or $1 million all has effectively the same emotional payoff, and that is not a feature. When you make it not really matter what user says when they interact and signal the system, you decrease their desire to want to continue to engage with the system.

Instead, when you treat the user like an individual and make their implicit resource allocations specifically tied to their personal resources, you get a lot more emotional connection. Even if the real financial value of those resources are extremely low, they are still owned by the user/player, and as such they will want to use them well.

To that end, it would probably be a good idea to add "you get to allocate X tokens from the reward pool in the next cycle" somehow, somewhere on the interface if someone were to implement the voting system I just described. Along with "you have made X votes in the last voting cycle." With those two pieces of information, you know everything you need to know to decide whether or not you want to drop another vote. No matter how many you drop, you still will allocate that much of the reward pool, it just may be spread thinner. For many of us, that's not a problem. Some people are more interested in playing the game, which is fine, and in this case "the game" will be the trade-off between a few large votes and spreading that resource pool over a wider number of posts. That would be up to individuals to decide.

This would seem to solve most of the problems that both of us see with the system.

(It does actively and intentionally leave aside the issue of whether or not Proof of Stake systems are inherently bad for resource allocation. Personally, I believe they do a terrible job of achieving a "wisdom of the crowd" mechanism for determining what "the best" content is, because nothing suggests that whales have the same taste in content as I do. It's an absolutely useless system for determining good content. However, it may be a reasonable mechanism for determining where mechanical rewards get assigned. It's not my favorite, but I'm willing to give it the benefit of the doubt because it provides an automatic kind of scaling. Fine. As long as we never confuse it with determining "what the best thing is," I can deal with it to some degree.)

And now I've spent enough time on this that I think I'm going to turn it into a post on my own steam feed. This happens more often than I should probably admit.