Improving the Steem platform for long-term content
I've been working steadily over the past couple days on one of the routine housekeeping tasks that's been neglected of late, namely, getting our Github issue tracker under control -- sorting, opening, closing, and replying to various tickets. As the ecosystem's grown and matured, I've discovered a need to change my personal workflow away from the development-oriented workflow I used in early Steem days, back to the more issue-tracker-centric, maintenance-oriented workflow I used in the later BitShares days. Which, among other things, means classifying every single ticket in my personal Zenhub according to how urgently it needs my attention. So I've been looking at a lot of tickets lately.
This ticket started out straightforwardly enough, as a request to revert the change which limits posts to two payout cycles. As I stated in my reply to the ticket, the reason we decided not to do this is to reduce our memory usage and limit the working set which needs to be kept in memory by consensus nodes. I would ordinarily have closed the ticket right then, but it was generating a lot of high-quality discussion, so I decided to let it run for a bit. I'm closing it now, though, and asking the discussion to continue in the comments here.
At first, I was a bit puzzled by the degree of controversy this straightforward change created. After all, Reddit archives old posts and discussions, disabling any updates or upvotes, probably with similar technical justifications, and nobody's up in arms about it.
But I eventually figured out what's going on here.
It's been my working assumption -- and likely the working assumption of others on the development team -- that Steem is all about fresh, new content; the value of content rapidly diminishes as its age increases. Many aspects of the system -- for example, how the sorting works -- are also designed with this assumption in mind. Let's call this Type I content.
But there is another type of content. A wiki, a blog, a Stackoverflow question, or (ironically enough) a Github ticket may continue to be relevant long after it is published. Let's call this Type II content. For another ticket I asked @dantheman for his opinion on where the canonical location for build instructions should be; his answer was to place them in the source tree. This was a simple, straightforward practical question with a simple, straightforward practical answer, and neither of us thought much about it at the time. But the question we should have asked ourselves was this one: Why don't we store the build instructions in Steem? And the answer is that build instructions are Type II content, and Steem simply isn't designed for it, which meant we'd have too many annoyances if we tried it.
In short, our focus on Type I content means that Type II content is something of a second-class citizen. And the assumption that we don't care about Type II content has become deeply ingrained in our thinking, to the point where we'd stopped noticing the missed opportunities.
So here are the questions I'm going to ponder:
- If we were designing Steem from the ground up, but we decided to design it with a focus on Type II content instead of Type I content, what choices would we have made differently?
- What is the right path to making Type II content a first-class citizen in Steem?
I haven't even begun to properly consider these questions, but I think they're important. What do you think?
Theoretical's statements regarding memory usage being the primary consideration are not fully on point. The primary consideration is the "attention of the masses". The overall security of the voting platform depends upon all things that can get voted upon being rewarded.
There are two fundamental use cases for Steem... content and currency.
Exchanges, merchants, etc need the ability to run nodes that are fully up to date on the economic state of the platform without respect to the social media side of the platform.
The sooner content can be separated from having financial consequences the more efficient the platform becomes for financial applications. It is financial applications that ultimately give the platform value many times that of other social media networks.
Posts that are eligible to receive payout need to keep track of "votes" and all other information relevant to the post. Removing the financial rewards associated with a post is sufficient for freeing things from memory. Those that wish to have a meta consensus above the economic consensus can.
Yeah, if that's what you thought any of us were saying, you weren't paying attention. It's about long term, small scale monetization, which would have been possible if payouts had stayed residual on a 30 day cycle, with us being responsible to bring new eyeballs to the content to even earn ANY upvotes, let alone enough to make a payout, but what I hear you saying is that long term, the payouts for content creation are not a part of the strategy, at all, is that correct? If so, tell us now, because that changes everything.
Sorry, I misread your comment. I think you mean, the earlier payout can end on content the better for financial activity and stability. Thanks, the second comment here helps me understand your issue, but it changes the entire platform for me and anyone who thinks like me. Not enough to leave, but I certainly won't be adding long form content here.
@dantheman, I'm not sure every one quite understands the quandry posed when trying to enable a "forever payout" model when using Graphene as a framework for Steemit. I'll do my best to explain, but I'm sure I'll have missed some major key points as to why such a model is a much bigger problem than most people realize. Anyone who can point out things I missed please feel free to do so.
Why the forever payout model may not be as easy to implement as some might think :
The issue at hand is a very complex one because Graphene is a very different style of framework on which to build a social media platform. It's a very resilient framework that utilizes a Peer-to-Peer system to help distribute all content and transactions via a blockchain in a highly ordered and very expeditious manner, rather than constantly querying a centralized database over and over to access content.
With that upside comes the downside of it not being meant for long term random reads and writes like most other social media frameworks. Because Steemit uses a linear blockchain to get everything accomplished (unlike wikipedia) its blocks are unchangeable once they're validated and merged with the existing blockchain.
That's pretty much the root cause of the whole long term payout issue and where the long term payout problem stems from. You can always add to the existing blockchain but you can not go backwards and simply rewrite it. Once blocks have become part of the blockchain they remain immutable and may only be referenced, but must remain unchanged to preserve the integrity of the blockchain. Adding to or taking away from an existing post's payout has to end at sometime (based on how Steemit is currently written) or it would cause a whole mess of other issues that come with running a massive decentralized database. Such an overhaul would completely negate the merits of a Graphene based Peer-to-Peer network with an immutable blockchain. (Unless someone pulls a crazy thing like Ethereum, in which case all bets are off and we all saw how well that's working out.)
The choice to use Graphene poses a bit of a quandary when utilized as a social media framework because its biggest trade off is the speed and resilience that comes from using a decentralized Peer-to-Peer network with an immutable blockchain, in favor of a much slower centralized database that can be rewritten indefinitely. Graphene was never meant to be an indexing style of framework like the ones used for platforms like Facebook, Reddit, and Wikipedia. Graphene favors lots of small transactions happening in an incredibly short period of time and by its very nature was likely (originally) best suited for a Twitter style platform and not a Reddit or Facebook style one. Steemit took a massive quantum leap in trying to bridge that gap by utilizing the methodology of a Graphene style blockchain to accomplish the best of both worlds on a decentralized Peer-to-Peer network.
That sort of thing is something that simply could not be accomplished by Facebook, Reddit, or Wikipedia because they all rely on very centralized servers to get the same job done. They do so however by sacrificing the benefits you gain from decentralization in terms of speed, resilience, and the Peer-to-Peer viability that Graphene has to offer.
Is there a perfect solution to the forever payouts model that's been proposed? I honestly don't know at this time. I'm still very much at a loss as to how this sort of thing would be accomplished given the very nature and limitations that come with using Graphene as the framework with which the Steemit platform was built.
Actually the bigger issue with the long term payout model seems to be less the technical side (which could be fixed with some changes to the platform so that no comment or vote objects need to be kept in RAM) and more the issue of limited voter attention to fight potential "payout farming" abuse.
ok, so lets focus on the non technical aspect:
the main problem @arhag mentions is the ¨payout farming:¨ abuse.
Often a discussion is based on some kind of not really tangible fear, so lets first look at the worst case scenario, that everybody is self-voting, so that we know what exactly we have to fear..
All the steem that is newly created for post rewards in the end is payed through inflation by steem / steem power holders. The more you hold the more you pay. If all would only self vote in away in the end you only get what was already yours. But that is not truly the worst case. Even worser would be if only some part of the steem holders take part in the voting process. In this case you could get some part of their cake if you selfvote. That said this worst case scenario does no sound that worse. At worst it would be some kind of micro payment platform where you can distribute your money to posts, even if they are your own posts. In the end its mainly your money you distribute. In this scenario only passive accounts would loose money, but that sounds also ok, as long as the time period they have to distribute ¨their¨ money is long enough, lets say 30 days.
Now after seeing that this worst case scenario isn't that bad, lets further look how we could even improve that:
Simple self voting itself is easy detectable through the transparency of the block-chain, so we only have to look at sybil-voting where you use more then one account. Simply creating some accounts that vote circular is also easily detectable, so they would have go through some kind of hiding strategy like using an exchange. All the time they would risk, that their self-voting strategy becomes known. In this case they could get flagged. Currently without having the ability to flag users, we could simple flag the posts of the sybil accounts and or shadow vote the sybil account. In this case they would need 2 years before they could transfer their steem power to a new unknown sybil account.
Summary:
If nearly all would just selfvote, In worst case we have a micro payment platform where you can simply distribute your ¨own¨ money. Creating Sybil accounts and hiding them is not that easy. Every-time one Sybil account becomes known you risk to loose the ability to vote for two years through being flagged / or shadow voted. In this case you would loose more then 10% for your steem holings through inflation. Under the promise that most of the main steem holders would take part in the voting at best self voters would get what was already theirs , at worse their money get trapped for two years and on top of that they would loose 10 plus percent of their steem value through inflation. That does not sound that promising for Self Voters...
That raises a great point. Permanent payouts are a huge potential pitfall in that respect. They could become a very real issue that would present their own problems when abused. I think sometimes it's completely forgotten that the money has to come from somewhere because many users are are only posting, voting and flagging in the hopes of getting paid.
There's no actual exchanging of currency between two parties (voters and posters) so no one really cares what happens as long as the platform pays them out. The money is being paid out directly by the platform itself for user participation and even the short term model has already seen it's fare share of abuse. Extending the payout period would absolutely serve to further widen the potential window for such abuse.
After all Steemit isn't bringing in any money from ad revenues (like Facebook), or donations (like Reddit) right now, so all money that goes out has to be replenished in some fashion or the platform would die a slow and very expensive death. With a market cap of $180 million USD give or take, that's a whole lot of incentive to game the system to death by abuse, bots, or any means necessary to grab as much money as possible before the whole system collapsed.
Is there a way to renew that block at specific intervals, so that the old block goes into archive, while a clone is put up for another 30 days?
That's not really how a blockchain works. A blockchain is more of a historical record, sort of like a banking ledger. It purely records the activities that took place in the past while acting as a shared ledger that everyone has a copy of and can validate the accuracy of through the use of a cryptographic algorithm. This in turn creates security through consensus of the math proofs involved. It's sort of like a recording tape without the ability to rewind and overwrite things because it would ruin the integrity of the original recording.
Cloning parts of old blocks and replaying them doesn't really work because you can't just cherry pick what's in them when you replay them. You wouldn't want to just replay the whole block because most of the data would be useless, stale data that was just being replayed and reproofed for nothing while wasting valuable computational resources. You either have to create a whole new block that consists of purely good data , or start a whole separate fork off the original chain which historically has been disastrous for some currencies. (And very thoughtfully was covered in the open source licence agreement of STEEM.)
I'm not sure if you're familiar with the Ethereum Project and the whole Ethereum, vs. Ethereum Classic ordeal but I'd give it a quick read through to see what I mean as to why "replay attacks" are a very real threat in those kind of situations. In summary the Ethereum Foundation decided to roll back their blockchain to reclaim a multi million dollar loss because of an exploited bug in their code. While some supported the rollback as a form of bailout, others did not and that's when the situation grew even more dicey.
Total chaos ensued because some people continued along the new Ethereum fork and some marched on producing work on the old Classic fork. Blocks with duplicate ID numbers were being generated and both proven to be correct which further helped rain down the chaos when you're talking about a blockchain that stores people's accounting records and wallet addresses.
It's actually a really great story and will be remembered forever in history as one of the greatest crypto blunders of all time. I was going to try and summarize everything but it's simply too complicated of a topic to cover in a one page reply.
the blockchain itself does not necessarily need to store all the content. The static content / even the updates could be stored in the Interplanetary File System. What is needed to be stored in the blockchain in the end is just a hash of the content, that doesnt sound that expensive to me.
So yes, we could create a p2p wiki, and yes we could store the hash of it in the blockchain, and yes we could allow to make micro transactions (upvotes) for all content. The main problem we could run into is, that the upvotes becomes too much to handle. But this problem we have also now...
I think it should be heavily considered. There are platforms such as wattpad, where writers slave for free, cranking out fiction that draws a lot of traffic. They are getting $0 from their efforts there, unless they sell books through their links to other places. A site like what Steemit appeared to be when I looked into it would provide, exactly what Steemvixen described three fold revenue that could feed a writer from one site. That potential is huge. I am a member of a single Facebook Group of writers where the population of that one group is larger than the user base of Steemit. If done correctly that could be migrated here, and they produce content, that is pretty much their only function. If you could figure out how to do it, my friend, you guys could compete with publishers such as Amazon, and the readers themselves could even earn from comments and reviews. The potential is huge, there are literally over ten thousand groups labeled "writer" on the Facebook platform with more than 1000 members. That's just one social network, one that many writers don't even belong to for purist reasons. I think you should carefully consider making this work as the potential upside among writers, video content producers, musicians, and photographers could explode this thing, and many artists are already agoristic in their views and prone to trying and accepting new things.
@markrmorrisjr, @anyx & @theoretical
Reedited this post after I went back and read what a hot mess it was because I tried to merge content from notepad, github and content related to the OP's post regarding this thread.
Sorry if things got a bit ampped up on Github. Going back though the ticket thread I realized that a lot of us had almost turned it into a free forum for debate rather than on topic discussion regarding the issue of payouts. In actuality I don't think I've ever seen a Github issue thread get that derailed in a very long time and I'm sorry if I was also contributing to that as well.
To stay a bit more on topic I'd like to first turn things down a notch first by apologizing to everyone who had to dig through that thread and all of the posts that turned into long rants. I think a lot of the heat in the debate was because the issue of voter nullification took on a big life of its own on in the past day or so. While the 2 issues at hand were unrelated they somehow got jumbled together in regards to the posts about them and they became almost one and the same, regarding upcoming changes to be made in HF 14.
Since that all started, the voter nullification issue has been tabled for the time being and I've had a chance to sleep on it to calm down a bit. Hopefully everything will stay a bit more on topic from here on out. Sorry if my anger over one issue overflowed into the ticket about the payout times. The last thing in the world I want to see is Steemit have the same kind of split in the user base that did irreparable damage to the Ethereum Foundation.
With keeping on topic about payouts and resource use, I'm also running a Witness & Mining node as well but it's not taking up anywhere near 7 GB of RAM for some reason and I'm running windows 10 which is known for it's terrible method of allocating resources. My total RAM usage is around the 3 GB mark which is still a bit high for a simple P2P client but I find it pretty manageable having 16 GB in total right now. Even with 7 GB being in use 16 GB would be more than enough for right now.
I'm upgrading to a total of 32 GB in the next week or so but it does sound like a bit of code optimization may be in order a full a node is eating up 7 GB now and was only eating 5 GB a few months ago. I'm not sure if the major difference is stemming from the fact that I'm only running 5 threads right now without hyper threading on an AMD processor, if it's an OS issue or what's going on there, but 7GB for a P2P client seems high to me. If it was using about 2/3rds of that a month back then this model will obviously be unsustainable in the long term when the user base grows to a much larger size. Regardless of payout times, more users means higher post volumes.
If the assertion about the RAM allocation problems in relation to posts pending payout is the indeed case, then that would definitely have to be addressed before the post volumes get to be unmanageable on a standard PC. In terms of Reddit's archival policies, the time until archive is 6 months which is well beyond the current 30 day proposal for Steemit.
I've done quite a bit of homework on how the Graphene protocol works and it seems it was optimized to handle a massive amount of small transactions per second and that metric was deemed to be the most important part about Graphene. TPS speeds rather than overall resource utilization could become a very serious issue if this platform starts to grow outside of that framework, and begins to be comprised of much larger data transactions meant to be sustained for a much longer period of time. It may not be what Graphene was designed for, but it is how many other social media platforms in existence seem to operate today. In regards to the life of an active thread, (paid out or not) 30 days is a very small window of time until a post is locked and archived.
Long term data accessibility will be paramount to Steemit's success if it's going to be a game changer and truly in it for the long haul. Having a "stop grave digging up posts" mentality would put Steemit in the same class with platforms like twitter (an almost purely Type I platform), and less so into the arenas of Facebook and Reddit (much more in the realm of a Type II bias). I would almost classify wiki as more of a Type III because not only is its past referenced regularly, but it's also updated and changed frequently which is what gives it value over both Type I and Type II style platforms. A Type III situation would make little sense for a platform like Steemit. Steemit is not a virtual encyclopedia but there's no reason it could not be a hybridized Type I/Type II kind of platform in which it would act as more of a library with a reference section. There is always value in having new and fresh content in a library, but no one would debate the merits of also having a section for classic materials written long before many of us were born. Such a library wouldn't last very long in the real world, (in keeping with the metaphor) it would instead become more of a trendy bookstore.
I'm not sure what specs have been recommended or required for the top tier of witnesses running full nodes but it sounds like multiple SSD's in Raid 0 may almost become a necessity if people start topping out on RAM and have to rely on virtual memory to pick up the slack. While that solution isn't nearly as cost effective or ideal as popping in a bit of extra RAM, when speed counts it's about the only way to go without the need for a full on conversion to rack mounted server blades or off site hosting in a data center.
It's hopefully possible that a combination of the 2 solutions (both code optimization and SSDs in a RAID 0 config) will become more plausible in the near future. Hardware prices are continuing to drop rapidly as SSDs become more of the norm rather than the exception, and during that time more data can be extrapolated in terms of the future rate of growth for this platform. I'm hoping that more data on what is necessary in terms of long term scalability can mitigate the need to archive old blocks for the sole purpose of saving on system resources. This kind of platform has the potential to be a total game changer and I hope time will afford both Steemit and Graphene the means to become the best go to platforms for long term, high speed, P2P social media.
For my part, I saw a thread and joined it, not aware that github was primarily being used to discuss the technical aspects. My apologies. I'm a writer and publisher, not a tech.
@markrmorrisjr , No worries. We really don't have much of a better way to directly address technical concerns and their likely ramifications to the Dev's without hopping on to Github. The original posts that drew attention to this very issue even had links pointing people to Github because the flow of information around here is a little... Uhm... Disorganized at times?
We don't have sub's like Reddit we only have #tags so the next best thing was to point people at Github I guess? (Doh... I doubt that mistake will be made again in the future.)
It was kind of like watching a scene from Family Guy where Peter just keeps on fighting with the chicken regardless of the venue or the collateral damage. The debate just kept moving from place to place only to end up right back where it started. We even managed to carve a path of collateral damage in our wake as well that shall forever be attached to the Steemit Git Repo.
Yup, we're an awesome bunch sometimes. You may not have known any better but plenty of us did and I'm sure we all realized this morning that it was too late to take it back. I honestly doubt anyone was proud to have taken place in the cross platform brawl, but as @anyx said on his thread from yesterday this place is very much the Wild West of social media.
In light of that revelation here's my peace offering of a parody for taking part in such an incident considering many of us did this very thing right here :
Steemit, gave me a bad coupon...
The value of content should not drop to zero simply because it has passed the payout window. There will likely be hundreds of thousands if not millions of new members reading 'old' content in the coming months and years. To me it would make sense to have the 24hr initial payout and then monthly payouts... forever. Why not? If I read an 'old' post and get some value from it, I upvote it and know the author will get a small reward. This could become a defining feature of the Steemit platform - permanent income streams! It would be huge, absolutely huge for content creators.
I fully agree. On top of that if the payout algorithm would be linear the payout could be done instantly with every vote. In this case we could not need to have different payout intervals at all. And on top of that rewards would spread more widely.
Self / Sybil voting is easily detected through the blockchain. Therefore self voters could get flagged for selfvoting / and or the payout algorithm itself could detect cycles and discourage it / encourage voting to more ¨distant¨ participants.
instant payouts wouldn't possible, without changing the "compete for this pot of steem daily" process that is already in place. As it stands, it is my understanding, that every upvote your content gets today, potentially decreases my payout, since it is all based on how many votes there are and how they are weighted, with each vote cast in a day, paying a percentage of the daily "prize" as it were, created by the increasing volume of steem, but perhaps I am confused and this is not at all how it works.
@markrmorrisjr, Actually that's not quite how it works. There's no set daily pot that people all share in because of the upvoted weight of their posts. In fact it's nothing like a race for votes to see who gets all the cash by percentage. Most of the STEEM that currently exsists was already mined, set and in place long before the platform itself even went live.
STEEM as a currency already has a market cap of around $180 million USD. It's money that's already been mined, and accounted for. Some of it is held in vests in the form of Steem Power, the rest remains a liquid asset.
When people post, the reward system gives determins the amount awarded based on the currently help vesting Steem Power of the voter who made the vote. If someone with a lot of SP upvotes you get more more of a reward than you would if someone with less SP upvotes your post. The inverse is also true of downvoting/flagging when removing a post's rewards.
There's no big daily "pot of steem" as it were. Think of it more as a huge "pot of steem" that was an already filled bowl of punch long before this party began. The amount of SP someone has determine how much or little of that huge pot they are allowed to dish out on a daily basis. If people with large vests simply just abstain from voting that portion of Steem simply does not move but instead remains in the bowl for tomorrow or whenever they vote later on down the road.
In reality (how ever unusual and highly unlikely the case may be) if every single person with vesting SP all upvoted the same post during the payout period it would be literally worth 6 figures easily. This however is very unlikely to happen, but is in theory is possible.
There's no set daily pot over which to fight because the pot per se, is really a much larger ocean. How much gets dished out each day varies greatly based on which voters are voting, how much voting weight they have, and how many times they vote.
Here's a Link To The : Steem White Paper which does a much better job of explaining the process than I ever could, but be forwarned it's about 45+ pages and at some points gets incredibly technical.
Note: some of the recent changes have had some impact on the finer points of how Steemit works, but the underlying principles outlined in the White Paper are still very much the same.
Yeah, I read it , but I need someone to explain the bits that made my eyes glaze over, I was under the impression of a daily amount based on an assumption, confirmed, I thought through a couple of posts. Part of the problem is that so much of this is not even covered in the whitepaper, understandably, since the details need to be flexible at this level and committing to a specific payout time structure, etc, could present issues. Anyway, thanks for taking the time to explain.
thx for your post, can you please link to a post or name the page / or code where we can find more details how the post payout exactly functions?
As far as I can remember the whitepaper says, that in the long run round about 5% of the inflated steem is used for post rewards (not counting the different initial distribution in the first months / years). This sounds like the amount of steem for block rewards per given time period is fixed. Therefore logically voting for something would decrease what all others get.
But so or so, even the current exponential payout algorithm could be done in a way, that instantly pays out. The only problem would be flags that reduce the payout. But this could be implemented that way, that flags simply reduce future payouts, or there is a time period of lets say 24 hours that flags could reduce / negate the payout transactions.
@arcurus Sorry It took me a bit to get back to you, I called it an early night. Here's a link to a tool that will show you how much a person's vote is worth.
Link To Vote Weight Tool : How much is my vote worth?
thx for the link! Yes it says my vote is worth 15.8 cents, but i guess thats only true in average... Normally my vote is worth 2 cents. It would be interesting how steem payout is really functioning. I guess I have to look into the code.
I've been thinking for a while now that Steem could have more than one blockchain. Each blockchain would have different reward system to encourage different types of content. The blockchains would be sidechains so that SD could be transferred from one chain to another.
I know that Steem operates with the assumption that it's bad to collect transaction fees from users. But an idea just popped into my mind: if somebody wants to have more than two reward payments for the post, he could have more by paying for them. If additional reward rounds increase the memory requirements, it's not feasible to allow them... but if somebody wants to pay for it, why not? Probably not that many posts would have more than two reward payments so the memory requirement would stay moderate.
Is it in any way feasible and reasonable to have several different content types with different reward mechanisms in one blockchain? It would help a lot if it was possible to help one kind of content without harming other types.
I think that you're making the mistake of conflating the SteemIt platform with the underlying Steem infrastructure. I wouldn't change Steemit to make Type II content a first-class citizen -- I'd develop another platform (re-using the appropriate code from SteemIt liberally) with an easy method to "archive" appropriate long-term content from Steemit after 30 days.
This isn't a clear cut issue because it expands to other aspects of the block chain. If Steem allows for an action that the Steemit.com UI does not handle well or at all, is that fair? And who decides what is and isn't fair?
For example, I manage my keys using the CLI wallet. There is no singular brain key than can recreate my keys. I lose out on the ability to easily manage my keys using Steemit.com but gain increased security (no single point of failure). You would be hard pressed to find someone that would not call my actions those of a power user, but most users would not mind because I am choosing to take the difficulty on myself.
Let's consider another example. Have you heard of vesting withdraw routes? When an account powers down, it can specify a number of destination accounts, a percentage of Steem Power to send, and whether or not to automatically power it up. I have some accounts that are powering down and auto vesting it into this account in the same block. The underlying implementation will directly convert Steem Power if I auto power up so that I do not lose satoshis of Steem on the transfer. I actually have this account set up to route 75% of my weekly power down back to itself and auto vest. That way I can have a variable power down rate week to week. Again, I do not think anyone would say this isn't the action of a power user. However, it is simple enough to understand and useful enough that "regular" users would want to use this. To the best of my knowledge, Steemit.com does not yet support the use of this operation. Is this ok? I have a distinct financial advantage in using my accounts this way that Steemit.com users do not.
Ok, so how does this relate to Type II content? If Steemit.com behaves in one way and Steem behaves in another, it could grant an advantage to those that are in "the know". Steemit.com hides poorly voted yet that content is still available on the block chain. In essence, we are promoting content that is voted above a certain amount by choosing to show it to you. The earning potential of content not shown by Steemit drops drastically. So, if there is content that is handled one way on Steemit.com and another on steemarchive.com (don't know if this is a real site or not) it could drastically advantage one community over another. Is this a good or a bad thing? How would this effect your use of the site?
I don't have answers to these questions, but I did want to point out that these issues go extend beyond content to all operations that can be done on Steem.
¨the reason we decided not to do this is to reduce our memory usage and limit the working set which needs to be kept in memory by consensus nodes.¨
@theoretical can you please give more details / an example / some numbers for this statement.
The text itself is static and could be stored in the Interplanetary File System.
So the question is what is about the consensus? Is it that expansive, if so what part?
Just as suggestion:
Couldn't rewarding content be the same way implemented like a simple transaction? Like every day you can distribute 0,1% of your ¨inflated¨ steem power to articles payed out in steem dollars. Steem Power that is not be distributed after 30 days is evenly distributed to all active participants.
Self / sybil voting is visible through the transparency of the blockchain. Participants that do self / sybil voting could therefore be flagged.
For example you have 100 Steem Power. If you dont vote for 10 days you have 100 * 0,1% * 10 = 1 Steem converted to steem dollars worth to distribute.
If 50% of the Steem power holder do not take part in voting, you have 2 Steem to distribute.
With the vote itself, a part of that could be instantly transfered to the owner of the article. No need for any further consensus.
If one self votes, the account itself could get flagged. With every flag the steem power to distribute could be the same way reduced like an upvote would have given. Both the flagger and the flagged person loosens therefore equally steem to distribute, that could be distributed from others.
By the way, I made this post about wanting to be able to comment on a year old Reddit post two days ago https://steemit.com/bitcoin/@nonlinearone/not-to-say-i-told-you-so-but-or-why-i-wish-i-could-reply-to-posts-a-year-later
"the value of content rapidly diminishes as its age increases" Citation Needed. :)
Depends on the content.
I would say a lot of the content that is encouraged and highly rewarded on SteemIt could qualify as "Evergreen." For example fiction, true life stories, introduceyourself, videos and photography just to name a few. http://www.wordstream.com/blog/ws/2012/10/16/guide-to-evergreen-content-marketing
I agree, but "highly rewarded" is relative. You might find a few hundred dollars a great reward for a short story for a single publication, but if that publication lasted forever and never paid you anymore, making your premium version of the same content compete with a previous, free version that already had search traction, you might reconsider.
Also, if you study Pinterest pins, you will find that many continue to be popular LONG after they were originally pinned. Evergreen content is the best kind.
I know I contributed to the thread you are referring to. As a professional writer, having residual income is gold. Even if it's only a few cents a month, over time, the steady stream of income makes the ups and downs of the writing life livable.
The problem I have with content not getting paid more than twice is two fold. First, it's not what was going on when I got here and I saw that residual as a huge draw. I understand why it might not have been in the forefront of your thinking. That's neither here nor there, just a preference.
The second is more troubling for me. That is the fact that the system keeps my content in perpetuity, where it can be used in the future, long after I may have left the platform for greener pastures. It adds to the organic gravity of Steemit as a URL, and thus is contributing to the bottom line, since over 14% of the sites traffic is coming through content searches.
That means that as a writer, I am contributing to every new signup, every share, and every time the site comes up in search, because my work adds authority to the pool.
I understand that my SP grows with the site and in some sense, if things go well, I do get a continuing source of revenue, but that content may essentially be dead to me now.
With writers, our content is what we build to sell. Much of it gets sold for one money, one time, and that kind of work we have to continually seek and do. The other, more valuable kind provides streams of residual income, like I said, albeit small, they add up quickly.
A writer like myself contributing 4 pieces per day would have over 200 pieces of "property" on the site. Not all of them would produce continued upvotes, but many could. If 1/4 of them produced $1 in revenue per month, that is $50 per month, compounded over 5 years, that's $250 per month and if I develop my audience correctly, I can do much better. If I hit at 75% continuous revenue generation, that would mean $150 a month after the first year. Coupled with the immediate payouts and investment potential, this makes your platform a very attractive home for writers, who might never need go anywhere else if they can develop enough of a following.
The primary reason to freeze discussions was both technical (reduce the memory footprint) and economic (prevent bots from "mining" their old content for rewards). Some potential changes we are discussing internally might address the economic reasoning behind this decision. I will be sure to bring that up during one of our brainstorming sessions.
Well, then prevent bots from mining. but don't penalize creators to stop something bad.
If we had a magic "stop bots" button, we would use it on a lot of things. Every change we make impacts human and bot users, usually in different ways. As conditions change we have to continually re-evaluate how our decisions, both past and present, effect both groups of users. If a past decision we made to reduce bot actions is now adversely effecting human users we will re-evaluate the past decision and change it if need be.
I'm not about telling anyone what to do, merely pointing out that the writers who are moving in and setting up camp are calculating their move based on long term, even micro, monetization of content. That won't be possible,according to Dan's reply above. That's unfortunate, since the content doesn't disappear, leaving a free version of my work, easily accessible making it difficult to monetize in other platforms as well.