You are viewing a single comment's thread from:
RE: 3 Month Retrospective
{'type':'view', 'timestamp':'<<timestamp>>,' block':<<blocknum>>, 'json':{'ip' :'8.383.849.11', 'account':''}}
Is what a view would look like on the chain. Literally bytes of data, not even kilobytes. And every transaction we have makes our blocktivity ranking go up. Steem witnesses used to process ten times as many transactions as they do now, and that was before mira made node costs a fraction of what they were before.
Can't argue with that, but wouldn't it take computing power (not just storage) to add those transactions up, what would that look like?
Posted using Partiko Android
Very little. Whenever you refresh steemit.com you'd be using more bandwidth and processing on comments and votes (which are tallied the same way) than on tallying views. Counting is bread and butter for a computer. And counting the votes could even be done clientside (on the users phone or Web browser).
That's bitching! Hey @steemitblog take notes.
Posted using Partiko Android
I was thinking about this last night and I realized that there's something that became obvious as an avenue to abuse as well as a limitation in implementing it. The transactions need to be broadcast by an account. One solution is to have steemit delegate enough sp/rc to keep the account working that registers all traffic without an account, but then it could be abused by anyone who wants to spam f5 without an account, you know what I mean?
Posted using Partiko Android
That's why the chain would keep an ip address, so refreshing wouldnt count as a different page view. But you are right, an account would need to sign the transaction, so maybe it could come from the @null account or the interface owners account on behalf of users who aren't logged in.
Yet it is limiting return views, but I guess a time limit could be in place so that for example refreshing the page won't count as returning user if they had visited within the x ammount of time and then they cannot spam. I hope you write a proposal concerning this, now that I've thought more about it I can't see why this wouldn't be exactly what we need.