You are viewing a single comment's thread from:
RE: The DIV Kernel, A weed that has found fertile ground
I really have no idea what you are talking about and it sounds like I will be left out of the main part (developing code) but might be able to participate in the user experience area. It sounds like you have big plans for this and I wish you success. Unfortunately, it is all over my head.
What does self-hosting mean? As far as I know, there must be some servers somewhere to store the data used to host a site.
Yesterday I started making a policy of voting only 4x per day at 100%, with both of my accounts, you are number 2 today for asking good questions.
Yes, initially it will be focused on platform development. I realised a couple of days ago that this is not an after-thought, but completely primary. It is basically a way to combine governance and development into a single unit, leveraging the gameification process as a meritocratic method of compensating the most important part of any social network system - the code, and embodied in the code, the rules of the society it creates.
Once this part is operational, obviously next is to monetise operating servers, both validators and providers of data retrieval services (the back end that finds the data to show you a web page). Then, the interface, and that is when average people join the game.
I want to build a platform that has all the dynamic, DIY energy of Open Source software, but includes everyone, and pays everyone for the value they contribute.
Self hosting means that all servers that run the DIV network also host the code that it is built from, and even, ideally not long afterwards, even build and upgrade themselves automatically when a hard fork vote passes and new code is switched on across the network.
Please do ask for further clarification if you need it. I am currently away from my workstation, shopping for some health supplies.
Thanks elfspice!
Your plan makes perfect sense to me, despite not understanding what it takes to make such a system work. Of course you need to have a serious amount of code and working software running on hardware to begin with. Contributors should be compensated for doing this work and providing the hardware. I will be looking forward to the day that I can become involved as a user and perhaps offer suggestions for making the user interface better.
May I ask why just 4 votes per day? That would leave 6 votes wasted, would it not?
It's funny that you have decided to implement this just after I had decided to use my 10 votes for upvoting those that actually contribute to my own posts. I want to encourage participation and have thus decided that to heck with looking for stuff to curate and make a few cents off of. Instead I will be voting on comments to encourage them. Seems there are a few of us that are all thinking the same way. The only difference is that my votes only generate 2 cents at this time. They did give 4 cents just after HF19, but that was only for a short while. Eventually mine will generate a bit more.
I do it this way because after 4 votes, there is 80% remaining and it takes 24 hours to regenerate 20%, so, this way I give maximum possible rewards to who I vote on. So you may also find the same occurs if you limit it to 4x 100% votes.
Also, I will be looking out for good new stories from my followers, as I follow them back to open the opportunity to reciprocate their interest in my work. But once I give out 4 votes in a day, that's it, sorry if you are in the wrong time zone, I wake up early, usually at or around dawn. So that's afternoon in asia and late night in the americas.
Yes, there is a fair bit of work to do, but Tendermint and its Basecoin plugin allow me to focus on the actual database structures and consensus rules for the rewards pool and voting, and integrating Git into a controlling database, and, of course, there does have to be a forum, just like this one!
The difference there also is I will also for this be using largely off the shelf components to build this. For simplicity it will be a bog standard default simple Markdown editor - there is a very nice interface side editor for this that I can adapt, which is WYSIWYG (!), and the base system will be together. From that point on, the idea will be that the system itself does the hosting for itself, and all the rest that is extraneous to the primary functionality can be built, using that primary functionality.
I was under the belief that 10 votes per day would drain only 20% (hence the account is back to 100% after 24 hours). I don't actually count my votes, but I'm generally not lower than around 80% even after giving out my daily votes (around 10 of them).
Since you know so much about Steem, I was wondering if you knew off hand how the reward pool is generated? Specifically, what I wish to know is: If there is just 1 person posting 1 article per day, is the reward pool the same size as if 100 people posted 100 articles in a day. And, if there is a larger pool for more content, is that reward pool growth linear? Essentially, what I'm after is; Is it harder to earn rewards with more Steemians participating than it was a year ago when there were far less Steemians.
I agree that re-inventing the wheel is a waste of time. Why create totally new software when perfectly good software already exists! The idea is to integrate the various software into a seamless experience for the end user. Ultimately, the end user expects to be able to intuitively begin using a product without the need to read a manual or learn new tricks. This is where Steemit falls down in its clunkyness.
The rewards pool is essentially the daily allocation (or weekly, in this case) refilled on a moment to moment basis that is the supply rate of new steem (or, in this case, to be precise, VESTS, which are allocated into steem, SBD and SP).
So basically, at every block, a witness calculates the rewards to be given out to the pending and due rewards, makes the payouts in the chain, calculates the correct refill (it has to vary up and down in a short time window because of the constant variance of how much rewards are given out in a block). The rewards are based on the sum of the VESTS tied up in SP, divided over the amount of rewards pool in time, which is tracked and kept towards an average.
I think the off the shelf components are servicable, but would not work in the long run, because the design I have in mind goes beyond simple blockchain, and uses new models that you can find examples of in 'Byzantine Fault Tolerant' database systems. In fact, I may end up using one of those, there is about 6 major projects I can dig up that I have read about. The thing is though, the latest stuff from Eric Freeman, which involves using gossip protocols to prevent forking of the chain, is much much much faster than the standart blockchain chatter protocols and confirmations system like you see with bitcoin and also to some extent with Steem and others. This methodology sees zero forks and sub 1 second clearance, and a 1 minute max total time to 100% confirmation.
So, while I will use the more old-strategy replication protocol built into Tendermint, and its basecoin for the ledger, I intend that as quickly as possible we get to implementing these more advanced techniques.
I think that, to build an incentivised self-hosting development platform at the centre, first, enables us to more rapidly find and make use of developmennt talent, and ideally, even, so much so that we are taking from the pool of blockchain type development people because our rewards are better and more motivating than any deal a corporation could offer.
Between what you wrote and what the Whitepaper says, it seems that Steem is growing at 100% per year (based on the original vests held). 90% of that is re-distributed to content creators. So if I am correctly interpreting what I have read, the answer to my question is that if 1 person contributes posts the 1st year and 2 people contribute post in the 2nd year, then the reward pool has grown proportional to the number of contributors and the rewards will be about the same in each year. However, if the number of contributors outstrips the growth rate of Steem, then as the number of contributors grows, the rewards will be proportionately less for each contributor.
Without fully understanding your new ideas, it does sound like you are looking at building a superior system that will take advantage of all the best things available. Have you seen any interest from prospective developers yet?
The whitepaper has not been updated. The interest rate is now about 9.3% (issuance rate).
Yes, this problem of crowding of the pool has been an issue all the way along. This is partly why I have designed into DIV a contrary rate issuance that lowers issuance rate as user activity accelerates beyond a certain point, or in other words, reduces the pay rate when there is too many users to share out evenly, and vice versa, when there is not enough, the rate increases
This is designed to front-run the network utilisation so that where as it does here, in a lagging fashion at first everyone gets less and less when there is too many, and then with the excess tokens dumped on the market, the effective value of the earnings are reduced, after a period of congestion, and then causing a sharp drop-off in users, and this again causing a lagging reaction in the price.
By lowering the rewards as activity accelerates, it naturally will brake the activity before the excess supply hits the market, allowing the price to remain more stable, and vice versa, as activity slows, the rewards are suddenly a lot higher per capita, and this will naturally draw more users to compete for it (which will then slow the rate down). This, combined with zero liquid rewards, and a daily 1% drawdown, should see the outflows of capital dramatically much more stable than with Steem, which will make it much more attractive as an investment.
Without using a stupid hedged instrument, complicating the monetary system like is necessary with Steem, where VESTS have a rate against Steem and a rate against SBD, this will just have 1 token, and a deposit contract with a random interest payout with a transaction volume driven issuance rate for interest on the contract built from necessary change operations (this sounds like a mouthful, but it is based on the property-registry token model called Refractory Token Ledger). Initially, using basecoin it will not operate quite like this, but eventually this token will be phased out once the RTL is implemented, and converted (I haven't cooked up the scheme for this.
I hope that the combination of a monetisation system for peer reviewed code and documentation writing, and the clear advantages of the architecture, all derived from observing the operation of Steem, that indeed, there will be a flood of developers and what took a year for people to build for steem will be done in 3 months.
:)
Gee, it seems you have already put quite a lot of thought into this project. I was going to ask what the timeline was but you already answered that.