I meant non-binding proposals reduces need for delegate processing/database and I thought this would be the more important issue. I'm not suggesting increasing max transaction size. Voting for a ton of things would require paying for multiple transactions. I'm also not saying you can't enforce reasonable limits.
Sure, for non-binding proposals, delegates' clients don't need to do any additional work other than validating a somewhat normal spending transaction but with some opaque attached blob of data, and as long as the fee is large enough to justify the size of the blob of data. Then only clients interested in voting functionality can spend the extra processing resources scanning these data blobs to see if they are relevant to the voting functionality and perhaps even further filtering transactions based on whether the blob is about the particular issues the user of the client cares about.
I don't like limiting proposals to only delegates.
That proposal of mine only applies to binding proposals anyway. It is a consequence of the limitation of only allowing a handful of active proposals at any give time, which is itself a consequence of trying to minimize transaction bloat. Delegates wouldn't need to do anything extra for non-binding proposals, which is what you seem to be mostly interested in anyway.
The on-chain solution still seems easier for the user to me. Is it really much "cheaper" for someone to go to the trouble to manage this off chain? What do you think of identifiable balances in transactions can be used to poll? I'm proposing to implement polls in an analogous way.
I really don't like the kludge of using a random number balance to identity a (poll, vote) tuple in a transaction. If the blockchain just has the ability to attach a public blob of data to a transaction (that the spender needs to pay the appropriate fee for) like I mentioned above, you get a lot more flexibility to implement what you are talking about and many other things as well.
Also, a good user interface makes the implementation details irrelevant to the user. So both can be made easy for the user. The only remaining questions are cost, scalability, and decentralization. Putting everything on the blockchain and validating it all with the full clients as they scan the blockchain does mean we get the best of decentralization and it means there are no other third-parties one needs to worry about censoring or manipulating results, however I think that would be costly and unscalable.
I think the better solution is to do most of this off-chain and only utilize the chain for purposes that absolutely require a blockchain, such as publicly timestamping a commitment under one's identity and moving the funds necessary to pay for the expenses of providing the service (ideally through micropayment channels). I mostly would like to do it this way because I want a protocol that can scale to handle services as trivial as upvoting/downvoting a post. Users shouldn't have to validate the votes on every meaningless post (they can trust the reported results by the service providers for the most part), but the protocol should allow anyone interested to collect the necessary data backing the proof of voting results from any sources on the internet and, assuming they can get all this data, they should be able to prove the validity of the voting results regardless of how small or insignificant the poll/election is (again assuming the data backing the proof has not been erased from the internet forever).