5 posts displayed of 11 total (page 1 of 3).
Account jesta , using activity types [post]
#steem
Posts loaded with the tag [steem]
Some UX/thinking around Links as content types
2016-11-20 | Tags: [steem] [steemit] [content-types] [links] [brainstorming]
links
Blog URL /steem/@jesta/some-ux-thinking-around-links-as-content-types
Steemit URL https://steemit.com/steem/@jesta/some-ux-thinking-around-links-as-content-types
SteemDB URL https://steemdb.com/steem/@jesta/some-ux-thinking-around-links-as-content-types
comment model

      Twig Examples:

      {{ post.title }}
      {{ post.author }}
      {{ post.body }}
    
post[id] 1394806
post[author] jesta
post[permlink] some-ux-thinking-around-links-as-content-types
post[category] steem
post[parent_author]
post[parent_permlink] steem
post[title] Some UX/thinking around Links as content types
post[body] There's one specific quote I really want to dive into from [steemitblog's latest post, "Proposed Upgrade for Blockchain Incentives"](https://steemit.com/steem/@steemitblog/proposed-upgrade-for-blockchain-incentives). Specifically this line, towards the bottom under "Different Curation Rewards for Different Content Types": > **Links should not have extremely high author rewards because they are almost entirely requests for curation**. Links as a content type (like posts) - it's something I've been thinking about for a while now, but don't see much chatter about. So I figured I'd write a little bit and potentially stir up some excitement for what this could be. ## Preface Throughout this post I am going to be using a mockup I did for a steemit blog (using reprint), which can be found here: http://steem.reprint.io I will be referring to this site as "blog.steemit.com" in screenshots and code samples, as that's what this site could potentially be someday. I also may be biased towards the awesomeness of this idea simply because I am building reprint, and am willing to admit it :) ## What would a content type of "Link" be? Think about how reddit uses in links to external content on other websites, as content on reddit itself. That's the one line pitch for this new type of content. Reddit has two forms of user generated content: links and selfposts (what a terrible name). They are pretty similar in terms of data, with the one major difference. As you browse reddit, clicking the title of a piece of content does one of two things: - You're taken to a reddit page, with a post someone wrote in a subreddit, it's comments, and other related information. - You're taken off reddit to an external website. Posts here on steemit are what we have now and are just like the first type above. The "link" content type that could be added to steem/steemit would be like the second type above, and act as a way to share content that is off steemit.com. The content could be on any website, even a website powered by steem, or a website powered by a different blockchain. ## How would a user submit a link? Instead of "Submit a Story", you would "Submit a Link". When submitting a Link, it would be similar to submitting a story, except the post of the body would be replaced by a field for you to enter the link. The remaining fields (tags, title, maybe payout options) would remain the same. Any link could be submitted by this method, but one of the cool things about how this could be implemented is that any content created on steem (as a post) could automatically act a link as well. Before diving into that concept, we need to understand what makes a "link" on the blockchain. ## How would it work (technically)? Right now, links could be implemented as a content type simply by creating a comment and specifying a link within the json_metadata. ``` json_metadata: { origin: 'https://blog.steemit.com/steem/@steemitblog/proposed-upgrade-for-blockchain-incentives' } ``` Links could be a `comment` in the blockchain, just one where a `body` field isn't required. They are tagged and indexed, mixed in and ranked right alongside all other content. They just act a bit differently, and may even have different reward structures (as the steemitblog article discussed). ## What would the experience on steemit.com be like? How would this change steemit? This is where the steemitblog/reprint example site comes into play. Imagine if that steemitblog post was submitted with the `json_metadata` shown above (perhaps automatically through a custom CMS). Here's a series of screenshots showing how the UX would work for that post. ### Stumbling upon the post in a feed... ![img](http://i.imgur.com/dLWJ74G.png) --- ![img](http://i.imgur.com/1PxVDw5.png) ### Found on blog.steemit.com ([demo](http://steem.reprint.io/steem/@steemitblog/proposed-upgrade-for-blockchain-incentives)) ![img](http://i.imgur.com/3RwZcMT.png) ### Back on steemit.com... ![img](http://i.imgur.com/fhC4vB5.png) ### Direct links to comments, might make for better community building... ![img](http://i.imgur.com/3FAaQyJ.png) ### Example of a "stub" page... ![img](http://i.imgur.com/OksHsSr.png) --- These aren't incredibly confusing or difficult changes (I don't think), and would offer users a new way to share content outside of the blockchain, while still creating a reference to them on-chain. There are some technical considerations yet to make about rewards, posting limits, uniqueness requirements, and UX - but I think the idea has an incredible amount of potential. ## Automatically linking Steem content Earlier I mentioned that the `body` field of a post wasn't required, but that also doesn't mean it has to be empty. I also mentioned that content submitted to steem (the blockchain) could automatically become a link. To end this entire train of thought off, here's how that could all work. Let's say I create this post (the one you're reading), and on this post, I add the `json_metadata` that a `link` type comment would have (the `origin` parameter). The link I use is to my blog, jesta.us, and is specifically to this article (like [this example](http://jesta.us/steem/@jesta/some-ux-thinking-around-links-as-content-types). The attaching of this json data would happen automatically through a CMS on my Reprint blog running on jesta.us, or any other authoring tool, as to not make it difficult. What I've created now on the blockchain is the hybrid of a comment and a link. On my website, I now have a post displaying like any other post. But on steemit.com, it now is automatically displayed as a link, which people can upvote, comment on or click on to visit my website. This one blockchain entry, as read by two different website engines, acting completely different based on the site it's presented on. ## Closing up Just to wrap this up, I believe content types could offer huge opportunities for development around steem. Not steemit.com, but steem, the blockchain. Steem itself has an incredible potential to become a shared foundation, for an unlimited number of websites, all interconnected by people in a way we've never seen before in history. I see a lot of talk about the economics of the platform, and regardless of how heated that side of this experiment gets, just remember how revolutionary it is over here on the web side of things :)
post[json_metadata]
[tags]
[0] steem
[1] steemit
[2] content-types
[3] links
[4] brainstorming
[image]
[0] http://i.imgur.com/dLWJ74G.png
[1] http://i.imgur.com/1PxVDw5.png
[2] http://i.imgur.com/3RwZcMT.png
[3] http://i.imgur.com/fhC4vB5.png
[4] http://i.imgur.com/3FAaQyJ.png
[5] http://i.imgur.com/OksHsSr.png
[links]
[0] https://steemit.com/steem/@steemitblog/proposed-upgrade-for-blockchain-incentives
[1] http://steem.reprint.io
[2] http://steem.reprint.io/steem/@steemitblog/proposed-upgrade-for-blockchain-incentives
[3] http://jesta.us/steem/@jesta/some-ux-thinking-around-links-as-content-types
[app] steemit/0.1
[format] markdown
post[last_update] 2016-11-20T03:45:33
post[created] 2016-11-20T03:43:06
post[active] 2016-11-30T22:38:36
post[last_payout] 2016-12-21T07:57:09
post[depth] 0
post[children] 17
post[children_rshares2] 0
post[net_rshares] 0
post[abs_rshares] 0
post[vote_rshares] 0
post[children_abs_rshares] 0
post[cashout_time] 1969-12-31T23:59:59
post[max_cashout_time] 1969-12-31T23:59:59
post[total_vote_weight] 0
post[reward_weight] 10000
post[total_payout_value] 61.071 SBD
post[curator_payout_value] 2.252 SBD
post[author_rewards] 571404
post[net_votes] 576
post[root_comment] 1394806
post[max_accepted_payout] 1000000.000 SBD
post[percent_steem_dollars] 10000
post[allow_replies] 1
post[allow_votes] 1
post[allow_curation_rewards] 1
post[beneficiaries]
post[url] /steem/@jesta/some-ux-thinking-around-links-as-content-types
post[root_title] Some UX/thinking around Links as content types
post[pending_payout_value] 0.000 SBD
post[total_pending_payout_value] 0.000 STEEM
post[active_votes]
post[replies]
post[author_reputation] 71627050027202
post[promoted] 0.000 SBD
post[body_length] 0
post[reblogged_by]
post[html] <p>There's one specific quote I really want to dive into from <a href="https://steemit.com/steem/@steemitblog/proposed-upgrade-for-blockchain-incentives">steemitblog's latest post, "Proposed Upgrade for Blockchain Incentives"</a>.</p> <p>Specifically this line, towards the bottom under "Different Curation Rewards for Different Content Types":</p> <blockquote> <p><strong>Links should not have extremely high author rewards because they are almost entirely requests for curation</strong>.</p> </blockquote> <p>Links as a content type (like posts) - it's something I've been thinking about for a while now, but don't see much chatter about. So I figured I'd write a little bit and potentially stir up some excitement for what this could be.</p> <h2>Preface</h2> <p>Throughout this post I am going to be using a mockup I did for a steemit blog (using reprint), which can be found here: </p> <p>http://steem.reprint.io</p> <p>I will be referring to this site as "blog.steemit.com" in screenshots and code samples, as that's what this site could potentially be someday.</p> <p>I also may be biased towards the awesomeness of this idea simply because I am building reprint, and am willing to admit it :)</p> <h2>What would a content type of "Link" be?</h2> <p>Think about how reddit uses in links to external content on other websites, as content on reddit itself. That's the one line pitch for this new type of content.</p> <p>Reddit has two forms of user generated content: links and selfposts (what a terrible name). They are pretty similar in terms of data, with the one major difference. As you browse reddit, clicking the title of a piece of content does one of two things:</p> <ul><li>You're taken to a reddit page, with a post someone wrote in a subreddit, it's comments, and other related information.</li> <li>You're taken off reddit to an external website.</li> </ul><p>Posts here on steemit are what we have now and are just like the first type above. The "link" content type that could be added to steem/steemit would be like the second type above, and act as a way to share content that is off steemit.com. The content could be on any website, even a website powered by steem, or a website powered by a different blockchain.</p> <h2>How would a user submit a link?</h2> <p>Instead of "Submit a Story", you would "Submit a Link". When submitting a Link, it would be similar to submitting a story, except the post of the body would be replaced by a field for you to enter the link. The remaining fields (tags, title, maybe payout options) would remain the same.</p> <p>Any link could be submitted by this method, but one of the cool things about how this could be implemented is that any content created on steem (as a post) could automatically act a link as well. Before diving into that concept, we need to understand what makes a "link" on the blockchain.</p> <h2>How would it work (technically)?</h2> <p>Right now, links could be implemented as a content type simply by creating a comment and specifying a link within the json_metadata.</p> <p><code>json_metadata: { origin: 'https://blog.steemit.com/steem/@steemitblog/proposed-upgrade-for-blockchain-incentives' }</code></p> <p>Links could be a <code>comment</code> in the blockchain, just one where a <code>body</code> field isn't required. They are tagged and indexed, mixed in and ranked right alongside all other content. They just act a bit differently, and may even have different reward structures (as the steemitblog article discussed).</p> <h2>What would the experience on steemit.com be like?</h2> <p>How would this change steemit? This is where the steemitblog/reprint example site comes into play. Imagine if that steemitblog post was submitted with the <code>json_metadata</code> shown above (perhaps automatically through a custom CMS). </p> <p>Here's a series of screenshots showing how the UX would work for that post.</p> <h3>Stumbling upon the post in a feed...</h3> <p><img src="http://i.imgur.com/dLWJ74G.png" alt="img" /></p> <hr /><p><img src="http://i.imgur.com/1PxVDw5.png" alt="img" /></p> <h3>Found on blog.steemit.com (<a href="http://steem.reprint.io/steem/@steemitblog/proposed-upgrade-for-blockchain-incentives">demo</a>)</h3> <p><img src="http://i.imgur.com/3RwZcMT.png" alt="img" /></p> <h3>Back on steemit.com...</h3> <p><img src="http://i.imgur.com/fhC4vB5.png" alt="img" /></p> <h3>Direct links to comments, might make for better community building...</h3> <p><img src="http://i.imgur.com/3FAaQyJ.png" alt="img" /></p> <h3>Example of a "stub" page...</h3> <p><img src="http://i.imgur.com/OksHsSr.png" alt="img" /></p> <hr /><p>These aren't incredibly confusing or difficult changes (I don't think), and would offer users a new way to share content outside of the blockchain, while still creating a reference to them on-chain. </p> <p>There are some technical considerations yet to make about rewards, posting limits, uniqueness requirements, and UX - but I think the idea has an incredible amount of potential.</p> <h2>Automatically linking Steem content</h2> <p>Earlier I mentioned that the <code>body</code> field of a post wasn't required, but that also doesn't mean it has to be empty. I also mentioned that content submitted to steem (the blockchain) could automatically become a link. To end this entire train of thought off, here's how that could all work.</p> <p>Let's say I create this post (the one you're reading), and on this post, I add the <code>json_metadata</code> that a <code>link</code> type comment would have (the <code>origin</code> parameter). The link I use is to my blog, jesta.us, and is specifically to this article (like <a href="http://jesta.us/steem/@jesta/some-ux-thinking-around-links-as-content-types">this example</a>. The attaching of this json data would happen automatically through a CMS on my Reprint blog running on jesta.us, or any other authoring tool, as to not make it difficult.</p> <p>What I've created now on the blockchain is the hybrid of a comment and a link.</p> <p>On my website, I now have a post displaying like any other post. But on steemit.com, it now is automatically displayed as a link, which people can upvote, comment on or click on to visit my website. This one blockchain entry, as read by two different website engines, acting completely different based on the site it's presented on. </p> <h2>Closing up</h2> <p>Just to wrap this up, I believe content types could offer huge opportunities for development around steem. Not steemit.com, but steem, the blockchain. Steem itself has an incredible potential to become a shared foundation, for an unlimited number of websites, all interconnected by people in a way we've never seen before in history.</p> <p>I see a lot of talk about the economics of the platform, and regardless of how heated that side of this experiment gets, just remember how revolutionary it is over here on the web side of things :)</p>
post[html_preview] <p>There's one specific quote I really want to dive into from steemitblog's latest post, "Proposed Upgrade for Blockchain Incentives".</p><p>Specifically this line, towards the bottom under "Different Curation Rewards for Different Content Types":</p>
post[image] http://i.imgur.com/dLWJ74G.png
post[ts] 1479634986
Steem Bounty System - Milestone #1 (Proposal)
2016-09-13 | Tags: [bounty] [bounties] [steem]
links
Blog URL /bounty/@jesta/steem-bounty-system-milestone-1-proposal
Steemit URL https://steemit.com/bounty/@jesta/steem-bounty-system-milestone-1-proposal
SteemDB URL https://steemdb.com/bounty/@jesta/steem-bounty-system-milestone-1-proposal
comment model

      Twig Examples:

      {{ post.title }}
      {{ post.author }}
      {{ post.body }}
    
post[id] 937287
post[author] jesta
post[permlink] steem-bounty-system-milestone-1-proposal
post[category] bounty
post[parent_author]
post[parent_permlink] bounty
post[title] Steem Bounty System - Milestone #1 (Proposal)
post[body] I have been thinking a lot about bounties over the past few weeks, how to systemize it, and how to imbue the spirit of steem directly into it's core. This document focuses on technical requirements, systems and the user experience. I am not the best designer in the world, so I didn't take a stab at the ui/design aspects of the project. Those are secondary to the actual systems behind it anyways. This is what I came up with. **It's huge**, so I broke it into 3 major parts: - A technical/ux concept for an MVP bounty system - Further analysis of specific concepts - My personal thoughts on this system If you're planning on diving into this entire post, I'd recommend setting aside an hour or two to fully comprehend it's design. This post is in direct respond to Milestone #1 from @ned's post, [It's time for a steem bounty system](https://steemit.com/bounties/@ned/it-s-time-for-a-steem-bounty-system). --- # Part 1: The Bounty Website - MVP Edition ## Terminology used in this document Briefly, here's some of the terms I will be using throughout the document. - **Bounty Creator**: The originating user who submits and funds the bounty - **Bounty Hunter**: A user who is submitting work to claim the bounty - **Bounty Backers**: A user who votes on the bounty announcement post - **Bounty Contributors**: A user who contributes additional funds to the bounty - **Bounty Hunter Claim**: Submitted work by a Bounty Hunter to claim a bounty. - **Bounty Reward**: The total reward pool built around a bounty (funding, post rewards, etc). - **Bounty Website**: The specific website that powers this system. I don't have a name for it, so I'll refer to it as such. ## Theoretical requirements for submitting a Bounty in the MVP system - A task that consists of a single phase & reward. - A task that in which a reward will be given to a single Bounty Hunter. - An initial funding of at least 10.000 SBD (arbitrary minimum amount). ## The internal life cycle of a bounty A bounty, as an entity, will have the following lifecycle to flow through. This concept should also be further elaborated into a flow chart with all labeled decisions. 1. Bounty Submission 2. Bounty Creation 3. Bounty Hunter Claims 4. Bounty Conclusion a. Completion b. Cancellation c. Abandonment ### 1. Bounty Submission The Bounty Submission phase is a process performed by someone who has initial funding and wishes to pay someone to complete a task. This person will be the Bounty Creator and associated as the primary point of contact behind this task. 1. Bounty Creator visits the Bounty Website 2. Clicks "Create New Bounty" (no registration necessary) - fills out task title - fills out an introduction/background for the task - fills out the tasks that need to be completed - fills out any additional requirements - fills out contact information - submits form 2. Submission creates a database entry and a unique identifier for the bounty - Bounty is not yet active - Bounty now has a lifespan of 24 hours, in which unfunded bounties will be deleted 3. User is redirected to a confirmation page - User is given the opportunity to review/change the bounty before it's finalized - User is given instructions on how to fund the bounty using SBD/STEEM - Multiple options can exist here, steempay.io/shapeshift/cli_wallet commands 4. Bounty Creator transfers initial funds to @bounty with the identifier provided in the memo field of the transaction. 5. Upon receiving of initial bounty deposit (meeting the minimum bounty requirements): - The first account to deposit is now associated to the bounty as the Bounty Creator - Future versions of the Bounty Website could include controls for the Bounty Creator to manage the bounty into the future. - The confirmation page dynamically updates and shows completed, with a link to the appropriate pages. - Link to view bounty on the Bounty Website. - Link to view the announcement post on steemit.com. - Link to documentation on how you should promote your bounty. - The bounty information can no longer be edited (also due to the 24h lock on posts). - A future version of the Bounty Website could allow the Bounty Owner to "amend" the bounty, showing a full changelog of how the bounty has evolved. 6. The system moves onto the next phase, Bounty Creation. ### 2. Bounty Creation Upon a successful funding and creation of a bounty, the @bounty bot will create a post on the blockchain with an announcement of the bounty. 1. The @bounty bot will create a post: a. Using the #bounties tag (or whatever tags deemed by the community) b. The post will contain: - A summary of the bounty, as filled out in Phase #1 - A bit of information about the Bounty Creator - A large prominent link to visit the Bounty Website to view the live status - This will be important because after 24 hours, the information in the post will be locked - Instructions for Bounty Hunters on how to submit a claim to this bounty (details below) - Instructions for Bounty Contributors on how to add additional SBD to the reward pool (details below) c. If the bounty has been funded with 100 SBD or more (arbitrary amount), the @bounty bot will also vote on the bounty post, contributing to the reward pool and visibility. d. All SBD rewards from the post (24h + 30d) are automatically allocated to the reward pool for the bounty. - This allows a form of non-monetary contributions from the community to support - Any post rewards will be distributed once they're available and the bounty is complete. 2. The Bounty Website will begin displaying the bounty a. All of the information submitted by the Bounty Creator will be displayed on the page of a specific bounty. More details about this page below. b. The bounty will show up on the homepage and the pages which allow you to browse bounties. ### 3. Bounty Hunter Claims For the MVP of this product, we would create Bounty Hunter Claims using the steemit.com posting interface. As the Bounty Website continues to evolve, this process could be internalized within the Bounty Website for ease of submission. 1. Each bounty has a unique identifier associated to it, displayed prominently on the Bounty Website and on the steemit.com post. To submit a claim for the bounty, the user must: - Create a new post using the `bounty-submission` tag as well as a tag with the unique ID of the project, e.g. `bounty-57ccca17c0c84a002b704b71`. - This post will contain the required information to complete the bounty: - Images if it's an image task - Content if it's a content task - Links to external files if it's a development task - The Bounty Hunter could also earn a reward for writing this post and potential tips for the effort. 2. Each Bounty Hunter Claim submitted will be reviewed by the Bounty Creator. - The Bounty Creator could be notified via email/slack/etc of new submissions - The Bounty Creator will provide necessary feedback on entries as needed. 3. All of the Bounty Hunter Claims that are tagged with the `bounty-{id}` tag will be aggregated and displayed on the Bounty Website as potential claims to the bounty. ### 4.a Bounty Completion Once a suitable Bounty Hunter Claim has been submitted, and the Bounty Creator is satisfied. The Bounty Creator can signal the end/award of a bounty. For the MVP of this product, it will be done through the issuing of a specific command from the originating account. In essence, we will have a single command that needs to be issued: `bounty-{id} award account_name` This command can be issued in a number of ways: - Sending a transfer of 0.001 SBD to @bounty with the command as the memo. - Replying to the bounty announcement post with the command as the body. - A future private messaging system with the command. - Creating a new post with the command as it's body and a specific tag. Currently this system is designed in that the Bounty Creator picks an entry to award the bounty. Future "types" of bounties could be created that also allow for voting of the winner or multiple users deciding. ### 4.b Bounty Cancellation If for any reason the bounty owner wants to cancel a bounty, the bounty owner can issue a special command (using the methods above) to halt a bounty. Bounties may need to be canceled due to lack of participation, or failing to reach a specified amount. `bounty-{id} cancel` Once a cancellation is started, it will enter a 3 day period in which funds are released from the time locked savings. During this time, a cancellation can be challenged by anyone to halt the withdraw and dispute it. A user may be in the middle of working on something and wants an opportunity to display their work. Human intervention and moderation will be required at this point for the MVP to ensure no abuse of the system is occurring. After the 3 day cancellation process, all funding to this bounty will be distributed back to the Bounty Contributors who contributed at the exact amount they contributed. Any remaining SBD (from post earnings) will then be powered up by the @bounty bot. ### 4.c Bounty Abandonment If a bounty is abandoned, currently the team behind the Bounty Website would have to reconcile things manually. Questions remain about what constitutes an "abandoned" bounty and efforts should be made to contact the Bounty Creator should this situation arise. Developing an automatic system for this aspect should wait until further evaluation is done. --- # Part 2: Further analysis and elaboration of specific concepts ### Bounty Contributions There are two ways anyone can contribute to a bounty and it's reward: - Large impact: by contributing liquid SBD/STEEM into the bounty pool - Small impact: upvoting the announcement post of the bounty Both of these classes of users will be highlighted on the Bounty Website as users who are helping contribute to the success of the platform. This idea could then morph into leaderboards and profile pages, giving people a place to proudly show their support. Most of this concept should remain outside of the MVP of the product, but can easily be grown into. ### Disputes All disputes will be handled by humans in the beginning. Any part of transferring funds or awarding Bounty Hunters can be disputed and handled by hand. **Arbitration Council** (potentially) - A team of volunteers could be assembled/voted on to handle all disputes that require human intervention. ### Disputes and the 3 day saving account withdraw The bot during it's distribution of rewards has a built-in 3 day dispute period, thanks to the time-locked savings accounts. During that 3-day window, any disputes can be surfaced and the transaction can be halted. This should provide a sufficient oversight window. ### Multiphase bounties (aka milestones) Multiphase bounties should be broken up into multiple bounties for the MVP of this product. The additional complexity it causes should be moved to a later date to avoid release of the initial product. ### Promoted Posts The promoted post system could be used to promote bounties to larger audiences. Anyone using the current system could promote a bounty if they choose to do so. ### Multi-sig Bounty Creator Bounty owners could technically be groups of users who are in control of a multi-sig account. A Bounty Creator could set their posting key to multi-sig to require the modification of a bounty. ### Community voting for bounty awarding This currently can't work, there's a number of reasons as to why we shouldn't use voting on posts/comments as a mechanism to choose who to reward. This could be an entire post about the mechanics of voting and why it wouldn't be the best fit. ### Multiple Bounty Hunter Rewards - reward splitting In an initial capacity, this should be considered a "nice to have". It creates additional layers of complexity in the automation of rewards distribution, and because of this, shouldn't be considered for the MVP. In the future, being able to state "3 rewards" during the creation of our bounty would be ideal. This would then cause the system to split the rewards 3 ways based on the 3 accounts the Bounty Creator has chosen to award. ### Bounty Time Limits The concept of time limits on bounties should be explored outside of the MVP. Determining appropriate lengths and the parameters for abandoned projects will be learned over time. ### Transfers and Testing To start out with, I'd recommend that all transfers actually use multi-sig and someone overseeing the program day to day would ensure the bot is distributing funds correctly. I doubt the volume would be high enough to make this an incredibly burden, but people would need to know that there's a human blocking some transactions so it may take days for approval. ### Weekly Bounty Recap Each week, the @bounty bot could create a recap post of all active and recently completed bounties. This would serve as a health-check to the community and as additional visibility about active bounties to the community. It's another method for the @bounty bot to grow in power and use it's influence to promote bounties. - All active bounties will be displayed in the post with their current information - All bounties completed in the last week will then be listed with results - The SBD earnings of this post could be redistributed into all active bounties or used to fund development of the service - Encourages new users to submit bounties + votes on active bounties ### @bounty bot concept - Acting as a "whale" - The bot could act as a sort of whale account to help bounties with visibility and rewards. Specific criteria would likely have to be enforced to disallow gaming of it's power. - The bot itself grows in power based on SP rewards by it's posting and curating activity. - It could be used to "tip" people who submit meaningful, but not finalized work to a bounty. - Helping self-fund it's own development - paying for infrastructure and development costs. - The bot could author non-bounty posts (maybe patch notes for the program?) to earn SBD + STEEM, then used to pay for services. - The bot could be powered down for a weekly contribution to costs. ### @bounty bot behavior - Incoming Transfer Operations - Any transfer sent with a matching bounty ID will be automatically pooled with other matching IDs - Any transfer sent that has an invalid memo will automatically be send back to it's source. - Outgoing Transfers - Once the specific conditions (smartcontract someday?) are met, the bot distributes the awards accordingly. - Time Locked Savings - All funds received by the @bounty bot will store funds in a the new savings protocol - All funds within the @bounty bot will take 72 hours to release due to this - Potential Escrow Usage - It's possible the bot could use the new escrow feature in some way, but it yet unknown. Currently with the crowdfunding nature of this proposal, escrow may or may not make sense. ### Cost of maintaining the service - The **initial development** of this project isn't a small feat, especially when you're talking about holding and escrowing funds for projects. Security and monitoring should be considered in every aspect of the development of this system's automation. - I would put roughly 2-3 months of development time on the MVP of this project to build the foundation right. It may go a lot faster than that, but it's a comfortable timeframe to not feel rushed and cut corners. - High level components: - The frontend Bounty Website - Submission of Bounty - Viewing of a Bounty - Browsing, searching, filtering of Bounties - The @bounty bot(s) - A process to monitor and handle automated transactions - A process to create and monitor posts - Support System setup and considerations - Infrastructure Setup - Ongoing/future development - Maintaining APIs with the changing steem blockchain - Implementing native solutions and creating a single site experience - Integrating new payment methods for funding - Adding user/management interfaces - Mobile implementation - Monitoring - Post monitoring for spam/abuse - Daily Reports to keep tabs on if any attempts to game the system occur - Vigilant monitoring of the bots and wallets - Infrastructure - This setup requires a multi-server infrastructure. Estimating ~100 USD a month. --- # Part 3: My personal thoughts on the bounty system and going forward TLDR: This project, done right, really isn't as simple as it sounds. As you can see from the above outlines and thoughts, building a system that embraces the reward structure and ideology of steem isn't as simple as customizing a CMS. I've spent a non-insignificant amount of time already exploring the concepts behind it, and I didn't even scratch the surface of an effective user interface/design. I am incredibly happy to share this thought experiment with all of you and hopefully some of the concepts and ideas will help spark new thoughts. There are a number of concepts here that could be expanded upon for the bounty system or potentially for other applications. To close this out - I am uncertain currently of how much further I will be pushing this project in a development capacity. The bounty system is a large undertaking that I could see myself spending the next few months absolutely focused on. It's also a huge responsibility to take on, especially regarding the security and integrity surrounding the system. I'll be exploring this idea further over the coming week or so to really decide how to proceed.
post[json_metadata]
[tags]
[0] bounty
[1] bounties
[2] steem
[users]
[0] ned
[1] bounty
[links]
[0] https://steemit.com/bounties/@ned/it-s-time-for-a-steem-bounty-system
post[last_update] 2016-09-13T04:03:27
post[created] 2016-09-13T04:03:27
post[active] 2016-09-16T17:44:00
post[last_payout] 2016-10-14T06:34:00
post[depth] 0
post[children] 42
post[children_rshares2] 0
post[net_rshares] 0
post[abs_rshares] 0
post[vote_rshares] 0
post[children_abs_rshares] 0
post[cashout_time] 1969-12-31T23:59:59
post[max_cashout_time] 1969-12-31T23:59:59
post[total_vote_weight] 0
post[reward_weight] 10000
post[total_payout_value] 1344.204 SBD
post[curator_payout_value] 114.371 SBD
post[author_rewards] 2036674
post[net_votes] 375
post[root_comment] 937287
post[max_accepted_payout] 1000000.000 SBD
post[percent_steem_dollars] 10000
post[allow_replies] 1
post[allow_votes] 1
post[allow_curation_rewards] 1
post[beneficiaries]
post[url] /bounty/@jesta/steem-bounty-system-milestone-1-proposal
post[root_title] Steem Bounty System - Milestone #1 (Proposal)
post[pending_payout_value] 0.000 SBD
post[total_pending_payout_value] 0.000 STEEM
post[active_votes]
post[replies]
post[author_reputation] 71627050027202
post[promoted] 0.000 SBD
post[body_length] 0
post[reblogged_by]
post[html] <p>I have been thinking a lot about bounties over the past few weeks, how to systemize it, and how to imbue the spirit of steem directly into it's core. This document focuses on technical requirements, systems and the user experience. I am not the best designer in the world, so I didn't take a stab at the ui/design aspects of the project. Those are secondary to the actual systems behind it anyways.</p> <p>This is what I came up with. <strong>It's huge</strong>, so I broke it into 3 major parts:</p> <ul><li>A technical/ux concept for an MVP bounty system</li> <li>Further analysis of specific concepts</li> <li>My personal thoughts on this system</li> </ul><p>If you're planning on diving into this entire post, I'd recommend setting aside an hour or two to fully comprehend it's design.</p> <p>This post is in direct respond to Milestone #1 from @ned's post, <a href="https://steemit.com/bounties/@ned/it-s-time-for-a-steem-bounty-system">It's time for a steem bounty system</a>.</p> <hr /><h1>Part 1: The Bounty Website - MVP Edition</h1> <h2>Terminology used in this document</h2> <p>Briefly, here's some of the terms I will be using throughout the document.</p> <ul><li><strong>Bounty Creator</strong>: The originating user who submits and funds the bounty</li> <li><strong>Bounty Hunter</strong>: A user who is submitting work to claim the bounty</li> <li><strong>Bounty Backers</strong>: A user who votes on the bounty announcement post</li> <li><strong>Bounty Contributors</strong>: A user who contributes additional funds to the bounty</li> <li><strong>Bounty Hunter Claim</strong>: Submitted work by a Bounty Hunter to claim a bounty.</li> <li><strong>Bounty Reward</strong>: The total reward pool built around a bounty (funding, post rewards, etc).</li> <li><strong>Bounty Website</strong>: The specific website that powers this system. I don't have a name for it, so I'll refer to it as such.</li> </ul><h2>Theoretical requirements for submitting a Bounty in the MVP system</h2> <ul><li>A task that consists of a single phase &amp; reward.</li> <li>A task that in which a reward will be given to a single Bounty Hunter.</li> <li>An initial funding of at least 10.000 SBD (arbitrary minimum amount).</li> </ul><h2>The internal life cycle of a bounty</h2> <p>A bounty, as an entity, will have the following lifecycle to flow through. This concept should also be further elaborated into a flow chart with all labeled decisions.</p> <ol><li>Bounty Submission</li> <li>Bounty Creation</li> <li>Bounty Hunter Claims</li> <li>Bounty Conclusion a. Completion b. Cancellation c. Abandonment</li> </ol><h3>1. Bounty Submission</h3> <p>The Bounty Submission phase is a process performed by someone who has initial funding and wishes to pay someone to complete a task. This person will be the Bounty Creator and associated as the primary point of contact behind this task.</p> <ol><li>Bounty Creator visits the Bounty Website</li> <li>Clicks "Create New Bounty" (no registration necessary) <ul><li>fills out task title</li> <li>fills out an introduction/background for the task</li> <li>fills out the tasks that need to be completed</li> <li>fills out any additional requirements</li> <li>fills out contact information</li> <li>submits form</li> </ul></li> <li>Submission creates a database entry and a unique identifier for the bounty <ul><li>Bounty is not yet active</li> <li>Bounty now has a lifespan of 24 hours, in which unfunded bounties will be deleted</li> </ul></li> <li>User is redirected to a confirmation page <ul><li>User is given the opportunity to review/change the bounty before it's finalized</li> <li>User is given instructions on how to fund the bounty using SBD/STEEM <ul><li>Multiple options can exist here, steempay.io/shapeshift/cli_wallet commands</li> </ul></li> </ul></li> <li>Bounty Creator transfers initial funds to @bounty with the identifier provided in the memo field of the transaction.</li> <li>Upon receiving of initial bounty deposit (meeting the minimum bounty requirements): <ul><li>The first account to deposit is now associated to the bounty as the Bounty Creator <ul><li>Future versions of the Bounty Website could include controls for the Bounty Creator to manage the bounty into the future.</li> </ul></li> <li>The confirmation page dynamically updates and shows completed, with a link to the appropriate pages. <ul><li>Link to view bounty on the Bounty Website.</li> <li>Link to view the announcement post on steemit.com.</li> <li>Link to documentation on how you should promote your bounty.</li> </ul></li> <li>The bounty information can no longer be edited (also due to the 24h lock on posts). <ul><li>A future version of the Bounty Website could allow the Bounty Owner to "amend" the bounty, showing a full changelog of how the bounty has evolved.</li> </ul></li> </ul></li> <li>The system moves onto the next phase, Bounty Creation.</li> </ol><h3>2. Bounty Creation</h3> <p>Upon a successful funding and creation of a bounty, the @bounty bot will create a post on the blockchain with an announcement of the bounty.</p> <ol><li>The @bounty bot will create a post: a. Using the #bounties tag (or whatever tags deemed by the community) b. The post will contain: <ul><li>A summary of the bounty, as filled out in Phase #1</li> <li>A bit of information about the Bounty Creator</li> <li>A large prominent link to visit the Bounty Website to view the live status <ul><li>This will be important because after 24 hours, the information in the post will be locked</li> </ul></li> <li>Instructions for Bounty Hunters on how to submit a claim to this bounty (details below)</li> <li>Instructions for Bounty Contributors on how to add additional SBD to the reward pool (details below) c. If the bounty has been funded with 100 SBD or more (arbitrary amount), the @bounty bot will also vote on the bounty post, contributing to the reward pool and visibility. d. All SBD rewards from the post (24h + 30d) are automatically allocated to the reward pool for the bounty.</li> <li>This allows a form of non-monetary contributions from the community to support</li> <li>Any post rewards will be distributed once they're available and the bounty is complete.</li> </ul></li> <li>The Bounty Website will begin displaying the bounty a. All of the information submitted by the Bounty Creator will be displayed on the page of a specific bounty. More details about this page below. b. The bounty will show up on the homepage and the pages which allow you to browse bounties.</li> </ol><h3>3. Bounty Hunter Claims</h3> <p>For the MVP of this product, we would create Bounty Hunter Claims using the steemit.com posting interface. As the Bounty Website continues to evolve, this process could be internalized within the Bounty Website for ease of submission.</p> <ol><li>Each bounty has a unique identifier associated to it, displayed prominently on the Bounty Website and on the steemit.com post. To submit a claim for the bounty, the user must: <ul><li>Create a new post using the <code>bounty-submission</code> tag as well as a tag with the unique ID of the project, e.g. <code>bounty-57ccca17c0c84a002b704b71</code>.</li> <li>This post will contain the required information to complete the bounty: <ul><li>Images if it's an image task</li> <li>Content if it's a content task</li> <li>Links to external files if it's a development task</li> </ul></li> <li>The Bounty Hunter could also earn a reward for writing this post and potential tips for the effort.</li> </ul></li> <li>Each Bounty Hunter Claim submitted will be reviewed by the Bounty Creator. <ul><li>The Bounty Creator could be notified via email/slack/etc of new submissions</li> <li>The Bounty Creator will provide necessary feedback on entries as needed.</li> </ul></li> <li>All of the Bounty Hunter Claims that are tagged with the <code>bounty-{id}</code> tag will be aggregated and displayed on the Bounty Website as potential claims to the bounty.</li> </ol><h3>4.a Bounty Completion</h3> <p>Once a suitable Bounty Hunter Claim has been submitted, and the Bounty Creator is satisfied. The Bounty Creator can signal the end/award of a bounty. For the MVP of this product, it will be done through the issuing of a specific command from the originating account.</p> <p>In essence, we will have a single command that needs to be issued:</p> <p><code>bounty-{id} award account_name</code></p> <p>This command can be issued in a number of ways:</p> <ul><li>Sending a transfer of 0.001 SBD to @bounty with the command as the memo.</li> <li>Replying to the bounty announcement post with the command as the body.</li> <li>A future private messaging system with the command.</li> <li>Creating a new post with the command as it's body and a specific tag.</li> </ul><p>Currently this system is designed in that the Bounty Creator picks an entry to award the bounty. Future "types" of bounties could be created that also allow for voting of the winner or multiple users deciding.</p> <h3>4.b Bounty Cancellation</h3> <p>If for any reason the bounty owner wants to cancel a bounty, the bounty owner can issue a special command (using the methods above) to halt a bounty. Bounties may need to be canceled due to lack of participation, or failing to reach a specified amount.</p> <p><code>bounty-{id} cancel</code></p> <p>Once a cancellation is started, it will enter a 3 day period in which funds are released from the time locked savings. During this time, a cancellation can be challenged by anyone to halt the withdraw and dispute it. A user may be in the middle of working on something and wants an opportunity to display their work. Human intervention and moderation will be required at this point for the MVP to ensure no abuse of the system is occurring.</p> <p>After the 3 day cancellation process, all funding to this bounty will be distributed back to the Bounty Contributors who contributed at the exact amount they contributed. Any remaining SBD (from post earnings) will then be powered up by the @bounty bot.</p> <h3>4.c Bounty Abandonment</h3> <p>If a bounty is abandoned, currently the team behind the Bounty Website would have to reconcile things manually. Questions remain about what constitutes an "abandoned" bounty and efforts should be made to contact the Bounty Creator should this situation arise. Developing an automatic system for this aspect should wait until further evaluation is done.</p> <hr /><h1>Part 2: Further analysis and elaboration of specific concepts</h1> <h3>Bounty Contributions</h3> <p>There are two ways anyone can contribute to a bounty and it's reward:</p> <ul><li>Large impact: by contributing liquid SBD/STEEM into the bounty pool</li> <li>Small impact: upvoting the announcement post of the bounty</li> </ul><p>Both of these classes of users will be highlighted on the Bounty Website as users who are helping contribute to the success of the platform. This idea could then morph into leaderboards and profile pages, giving people a place to proudly show their support. Most of this concept should remain outside of the MVP of the product, but can easily be grown into.</p> <h3>Disputes</h3> <p>All disputes will be handled by humans in the beginning. Any part of transferring funds or awarding Bounty Hunters can be disputed and handled by hand.</p> <p><strong>Arbitration Council</strong> (potentially) - A team of volunteers could be assembled/voted on to handle all disputes that require human intervention.</p> <h3>Disputes and the 3 day saving account withdraw</h3> <p>The bot during it's distribution of rewards has a built-in 3 day dispute period, thanks to the time-locked savings accounts. During that 3-day window, any disputes can be surfaced and the transaction can be halted. This should provide a sufficient oversight window.</p> <h3>Multiphase bounties (aka milestones)</h3> <p>Multiphase bounties should be broken up into multiple bounties for the MVP of this product. The additional complexity it causes should be moved to a later date to avoid release of the initial product.</p> <h3>Promoted Posts</h3> <p>The promoted post system could be used to promote bounties to larger audiences. Anyone using the current system could promote a bounty if they choose to do so.</p> <h3>Multi-sig Bounty Creator</h3> <p>Bounty owners could technically be groups of users who are in control of a multi-sig account. A Bounty Creator could set their posting key to multi-sig to require the modification of a bounty.</p> <h3>Community voting for bounty awarding</h3> <p>This currently can't work, there's a number of reasons as to why we shouldn't use voting on posts/comments as a mechanism to choose who to reward. This could be an entire post about the mechanics of voting and why it wouldn't be the best fit.</p> <h3>Multiple Bounty Hunter Rewards - reward splitting</h3> <p>In an initial capacity, this should be considered a "nice to have". It creates additional layers of complexity in the automation of rewards distribution, and because of this, shouldn't be considered for the MVP.</p> <p>In the future, being able to state "3 rewards" during the creation of our bounty would be ideal. This would then cause the system to split the rewards 3 ways based on the 3 accounts the Bounty Creator has chosen to award.</p> <h3>Bounty Time Limits</h3> <p>The concept of time limits on bounties should be explored outside of the MVP. Determining appropriate lengths and the parameters for abandoned projects will be learned over time.</p> <h3>Transfers and Testing</h3> <p>To start out with, I'd recommend that all transfers actually use multi-sig and someone overseeing the program day to day would ensure the bot is distributing funds correctly. I doubt the volume would be high enough to make this an incredibly burden, but people would need to know that there's a human blocking some transactions so it may take days for approval.</p> <h3>Weekly Bounty Recap</h3> <p>Each week, the @bounty bot could create a recap post of all active and recently completed bounties. This would serve as a health-check to the community and as additional visibility about active bounties to the community.</p> <p>It's another method for the @bounty bot to grow in power and use it's influence to promote bounties.</p> <ul><li>All active bounties will be displayed in the post with their current information</li> <li>All bounties completed in the last week will then be listed with results</li> <li>The SBD earnings of this post could be redistributed into all active bounties or used to fund development of the service</li> <li>Encourages new users to submit bounties + votes on active bounties</li> </ul><h3>@bounty bot concept</h3> <ul><li>Acting as a "whale" <ul><li>The bot could act as a sort of whale account to help bounties with visibility and rewards. Specific criteria would likely have to be enforced to disallow gaming of it's power.</li> <li>The bot itself grows in power based on SP rewards by it's posting and curating activity.</li> <li>It could be used to "tip" people who submit meaningful, but not finalized work to a bounty.</li> </ul></li> <li>Helping self-fund it's own development - paying for infrastructure and development costs. <ul><li>The bot could author non-bounty posts (maybe patch notes for the program?) to earn SBD + STEEM, then used to pay for services.</li> <li>The bot could be powered down for a weekly contribution to costs.</li> </ul></li> </ul><h3>@bounty bot behavior</h3> <ul><li>Incoming Transfer Operations <ul><li>Any transfer sent with a matching bounty ID will be automatically pooled with other matching IDs</li> <li>Any transfer sent that has an invalid memo will automatically be send back to it's source.</li> </ul></li> <li>Outgoing Transfers <ul><li>Once the specific conditions (smartcontract someday?) are met, the bot distributes the awards accordingly.</li> </ul></li> <li>Time Locked Savings <ul><li>All funds received by the @bounty bot will store funds in a the new savings protocol</li> <li>All funds within the @bounty bot will take 72 hours to release due to this</li> </ul></li> <li>Potential Escrow Usage <ul><li>It's possible the bot could use the new escrow feature in some way, but it yet unknown. Currently with the crowdfunding nature of this proposal, escrow may or may not make sense.</li> </ul></li> </ul><h3>Cost of maintaining the service</h3> <ul><li>The <strong>initial development</strong> of this project isn't a small feat, especially when you're talking about holding and escrowing funds for projects. Security and monitoring should be considered in every aspect of the development of this system's automation. <ul><li>I would put roughly 2-3 months of development time on the MVP of this project to build the foundation right. It may go a lot faster than that, but it's a comfortable timeframe to not feel rushed and cut corners.</li> <li>High level components: <ul><li>The frontend Bounty Website</li> <li>Submission of Bounty</li> <li>Viewing of a Bounty</li> <li>Browsing, searching, filtering of Bounties</li> <li>The @bounty bot(s)</li> <li>A process to monitor and handle automated transactions</li> <li>A process to create and monitor posts</li> <li>Support System setup and considerations</li> <li>Infrastructure Setup</li> </ul></li> </ul></li> <li>Ongoing/future development <ul><li>Maintaining APIs with the changing steem blockchain</li> <li>Implementing native solutions and creating a single site experience</li> <li>Integrating new payment methods for funding</li> <li>Adding user/management interfaces</li> <li>Mobile implementation</li> </ul></li> <li>Monitoring <ul><li>Post monitoring for spam/abuse</li> <li>Daily Reports to keep tabs on if any attempts to game the system occur</li> <li>Vigilant monitoring of the bots and wallets</li> </ul></li> <li>Infrastructure <ul><li>This setup requires a multi-server infrastructure. Estimating ~100 USD a month.</li> </ul></li> </ul><hr /><h1>Part 3: My personal thoughts on the bounty system and going forward</h1> <p>TLDR: This project, done right, really isn't as simple as it sounds.</p> <p>As you can see from the above outlines and thoughts, building a system that embraces the reward structure and ideology of steem isn't as simple as customizing a CMS. I've spent a non-insignificant amount of time already exploring the concepts behind it, and I didn't even scratch the surface of an effective user interface/design.</p> <p>I am incredibly happy to share this thought experiment with all of you and hopefully some of the concepts and ideas will help spark new thoughts. There are a number of concepts here that could be expanded upon for the bounty system or potentially for other applications.</p> <p>To close this out - I am uncertain currently of how much further I will be pushing this project in a development capacity. The bounty system is a large undertaking that I could see myself spending the next few months absolutely focused on. It's also a huge responsibility to take on, especially regarding the security and integrity surrounding the system. I'll be exploring this idea further over the coming week or so to really decide how to proceed.</p>
post[html_preview] <p>I have been thinking a lot about bounties over the past few weeks, how to systemize it, and how to imbue the spirit of steem directly into it's core. This document focuses on technical requirements, systems and the user experience. I am not the best designer in the world, so I didn't take a stab at the ui/design aspects of the project. Those are secondary to the actual systems behind it anyways.</p><p>This is what I came up with. It's huge, so I broke it into 3 major parts:</p>
post[image]
post[ts] 1473757407
[proposal] A potential alternative to Voting Power, Voting Tokens?
2016-09-03 | Tags: [steemit] [steem] [sip]
links
Blog URL /steemit/@jesta/proposal-a-potential-alternative-to-voting-power-voting-tokens
Steemit URL https://steemit.com/steemit/@jesta/proposal-a-potential-alternative-to-voting-power-voting-tokens
SteemDB URL https://steemdb.com/steemit/@jesta/proposal-a-potential-alternative-to-voting-power-voting-tokens
comment model

      Twig Examples:

      {{ post.title }}
      {{ post.author }}
      {{ post.body }}
    
post[id] 840857
post[author] jesta
post[permlink] proposal-a-potential-alternative-to-voting-power-voting-tokens
post[category] steemit
post[parent_author]
post[parent_permlink] steemit
post[title] [proposal] A potential alternative to Voting Power, Voting Tokens?
post[body] I can't help but think we're now hitting the point where the system behind voting, voting power, is far too complicated. People don't seem to fully comprehend it (myself included), and as changes are made, we need to learn all over again. We need something that can be packaged up in an easy to consume format with a simple UI. A system that overall feels like it benefits users over bots, and allows for semi-regular visitors to have an impact like daily visitors. Here's my take on a proposed, "seemingly-radically" different system... ## Voting Tokens Each account would have a balance of "voting tokens". These tokens would be "spent" as the account holder chooses to vote on a post. These tokens are not transferable between accounts and have no value (until used, as a vote). - Each token would represent 10% of a vote from the specific account. - You can use a maximum of 10 tokens per vote on a comment or post. - Each account regenerates 50 tokens per day automatically. - Each account can have a maximum of 350 tokens at any given time (7 days * tokens per day). - **Added based on feedback**: Each account could choose the precision of the voting tokens they use. If users wanted 500 tokens per day, based on 1% weight per token, the interface could be updated to reflect this. Useful for whales who want to be able to vote with 1%. Instead of having a percentage value of how powerful your votes are, and a decreasing percentage with each vote in succession, this system assumes that an account would **always** vote with a set percentage of it's weight, derived it's steem power. ### Why this direction? It's a lot easier for a user to understand "I have 20 tokens left" than "ok, I have 88.47% voting power left, that means I have 2 100% votes left if I want to get back to 100% in around 24 hours". This is a cryptocurrency, people understand balances and tokens. In fact, most people understand these things based on any credit/token system they've ever used, or any video game they've ever played. The percentage style system itself, while accomplishing many great things with it's sophisticated nature, is honestly confusing as hell. I'm still confused by parts of it, and I'm a level beyond a power user. Simplifying this system into something easy to use, consumable, understandable and fun is going to help engage the hardcore as well as the casual users. These benefits are what is going to help steemit grow. ### Comparing tokens to the new proposed 5 votes/day system Does this whole thing sound somewhat reasonable? If so, were you one of the people incredibly against the proposed 5 votes/day limit in 0.14.0? You might be surprised, but this system is pretty similar to that. There's one fundamental change that allows additional flexibility, which I think would make the entire concept of limiting a lot more acceptable. Let's start with the similarities between the two systems: - If 50 Voting Tokens are awarded each day, each with 10% weight, this equals out to be 5x 100% votes per day. The same as proposed for 0.14.0. - If you can use a maximum of 10 Voting Tokens per post, that's equal to 1x 100% weight vote, which is the same type of vote you can cast right now. - The tokens would allow each user to vote on anywhere from 5 posts to 50 posts a day. Comparing tokens to vote weight, it would be between 5x 100% votes and 50x 10% votes per day. - Regeneration intervals could be 50 tokens every 24 hours, 10 tokens every 4.8 hours, or 1 token every 28.8 minutes. This mirrors almost identically the proposed regeneration rate in 0.14.0. So what was the one fundamental difference? **The decrease in power after every vote**. With the current (live) and proposed 0.14.0 system, after each vote your overall weight drops to a percentage. An example of this is: - An account is at 100% voting power with 100 SP. - The account votes on a post, with 100% weight, applying the full weight of 100 SP. - The account now has ~96% voting power. - The account votes on a post, with 100% weight, and now because of voting power, it only applies ~96 SP worth of voting power. - The account now has ~92% voting power. - (repeat) If you don't have a break between your votes, there's no regeneration, and your vote has less of an impact. I'm not a fan of this, even as a regular user. I visit sporadically throughout the day, and my votes are typically concentrated batches, which puts me at a disadvantage from someone (or something) that votes at the perfect times. I'd like to have the opportunity to have the same impact, as I imagine most people would. I think it's a bit crazy that just reshaping how this is presented, and altering one mechanic of the system, can have such a drastic impact on the perception towards it. ### Notes on the interface and how users would see voting tokens The interface for this system I imagine would be incredibly simple. You're going to have a number and an icon that looks like either a vote or a coin of some kind. Maybe both. - **Tokens could be represented as a simple number** on the top navigation bar to indicate how many tokens you have stored and ready to use. This would be much easier to understand than an arbitrary percentage. - After each vote, the UI can dynamically update to show your remaining tokens. - The voting interface itself wouldn't have to change much, we could use the existing vote slider, except now it's a range from 1-10. We could also show a balance of tokens on the slider itself. - This interface highlights a true hard cap on the number of votes. Technically this is already happening, since you can't vote if you're at 0% voting power. Most of us don't see it currently, but we likely would more often after 0.14.0. - You would be unable to vote after expending all of your voting tokens, until you regenerated a new one. - [Strike this, this isn't true in the current system and would make the system gameable, thanks @arhag] ~~If you uncast a vote, you would be returned your voting tokens, just like currently you are returned your voting power~~. ### Controlling the token distribution rates through witnessing The configuration of this system should be delegated to witnesses. Moving these settings to witness votes would also prevent us from needing hard forks in the future. Witnesses could vote on these values, much like the account creation fee, to adapt as the communities demands change. - Witnesses can vote for `voting_token_per_day`, starting at 50 (per day). - Witnesses can vote for `voting_token_limit`, starting to 350 (7 days worth). The values would be set based on the median value of the top 19 witnesses, like all other votes. ### Potential economic "sinks" I'm throwing this out there as a "**maybe**", because this should be an entire concept explored itself. BUT, we might just be able to burn SBD/Steem to receive a proportional award of additional voting tokens. If you've got money to burn and want to vote on more things you could. Just burn a somewhat proportional amount of the chosen currency to get an equivalent amount of tokens. You get free tokens every day, but if you want more, pay. The "freemium" model. I could add another 3-5 paragraphs explaining the benefits of burned coins, but we'll save that for another day. ## Improvements over the newly proposed system in 0.14.0 ### Levels the playing field between humans and bots **Problem:** With the proposed new voting system in 0.14.0, you can cast 5x votes with 100% of your weight every 24 hours. But there's only one VERY specific way you can actually do it. Here's a example: - An account is at 100% Voting Power, and casts 1 vote @ 100% weight on a post. - The account's Voting Power decreases to 96% because of the 100% weighted vote. - 4.8 hours pass, the account's Voting Power is now back at 100%. - Repeat This pattern gives the account the most impact for their 5 votes, all truly being at 100% within a 24 hour window. The problem with the above scenario is that you have to wait exactly 4.8 hours between votes to optimally achieve this, and most people aren't going to vote exactly every 4.8 hours. You know who can though? Bots. Bots have a clear advantage if the strategy is to cast all 5 votes each day at 100%. While weight and voting power is only a part of the overall strategy, it's something humans cannot compete against. You can also scale this down to any variable vote weight, which just reduces the time needed between votes (you could vote with 10% weight every 28.8 minutes and stay at 100%). Again, another win for bots. **How Voting Tokens Helps:** The voting token system solves this problem by letting a user cast all 5 of those votes at any point in the 24 hour period, all at 100%. ### Flexibility for daily or weekly curators **Problem**: In the current and proposed system, if you aren't on steemit for a few days, you're wasting the potential of your voting power and curation rewards. The majority of the population isn't going to visit steemit every day (whether we want them to or not), which gives the daily users and bots an advantage over the general public. Some may argue this is not a problem, and daily curators should be rewarded more, but we need a system that encourages casual participation as well. An example in the current system for a casual account would be: - An account is at 100% Voting Power on Saturday and ends up casting 15 votes @ 100% weight. Under the newly proposed rules, that accounts Voting Power would decrease to ~54.20%. - As each vote is cast, the accounts voting power by ~4%. - The account recharges to 100% Voting Power again by Monday night (20% per day). - The account doesn't visit again until next Saturday, and has now wasted any potential regeneration cycles that could have been occurring Tuesday through Saturday. **How Voting Tokens Helps:** With the voting token system, this user could visit on a Saturday, and issue up to 35 votes at 100%, expending the entire balance of tokens. Then when visiting a week later, would be able to do the same again, allowing them the full benefit of their SP/Vest balance. # Final Thoughts I'm putting this out here as a thought experiment. I'd love to hear what you think. What I've laid out likely has problems that I couldn't possibly foresee, so I also really want to know why this wouldn't work. I've been thinking about it on and off all day, and think there's a lot of merit here. I honestly don't know if the solution we're looking for is in adjusting the numbers of the current system. My current belief is that in order to get as close to perfection as possible, we may need to fundamentally change the system to be a more user friendly and forgiving system. I feel this is closer.
post[json_metadata]
[tags]
[0] steemit
[1] steem
[2] sip
[users]
[0] arhag
post[last_update] 2016-09-03T07:17:00
post[created] 2016-09-03T02:44:45
post[active] 2016-09-13T17:37:15
post[last_payout] 2016-10-04T04:55:48
post[depth] 0
post[children] 71
post[children_rshares2] 0
post[net_rshares] 0
post[abs_rshares] 0
post[vote_rshares] 0
post[children_abs_rshares] 0
post[cashout_time] 1969-12-31T23:59:59
post[max_cashout_time] 1969-12-31T23:59:59
post[total_vote_weight] 0
post[reward_weight] 10000
post[total_payout_value] 166.788 SBD
post[curator_payout_value] 14.010 SBD
post[author_rewards] 194392
post[net_votes] 316
post[root_comment] 840857
post[max_accepted_payout] 1000000.000 SBD
post[percent_steem_dollars] 10000
post[allow_replies] 1
post[allow_votes] 1
post[allow_curation_rewards] 1
post[beneficiaries]
post[url] /steemit/@jesta/proposal-a-potential-alternative-to-voting-power-voting-tokens
post[root_title] [proposal] A potential alternative to Voting Power, Voting Tokens?
post[pending_payout_value] 0.000 SBD
post[total_pending_payout_value] 0.000 STEEM
post[active_votes]
post[replies]
post[author_reputation] 71627050027202
post[promoted] 0.000 SBD
post[body_length] 0
post[reblogged_by]
post[html] <p>I can't help but think we're now hitting the point where the system behind voting, voting power, is far too complicated. People don't seem to fully comprehend it (myself included), and as changes are made, we need to learn all over again. </p> <p>We need something that can be packaged up in an easy to consume format with a simple UI. A system that overall feels like it benefits users over bots, and allows for semi-regular visitors to have an impact like daily visitors.</p> <p>Here's my take on a proposed, "seemingly-radically" different system...</p> <h2>Voting Tokens</h2> <p>Each account would have a balance of "voting tokens". These tokens would be "spent" as the account holder chooses to vote on a post. These tokens are not transferable between accounts and have no value (until used, as a vote).</p> <ul><li>Each token would represent 10% of a vote from the specific account.</li> <li>You can use a maximum of 10 tokens per vote on a comment or post.</li> <li>Each account regenerates 50 tokens per day automatically.</li> <li>Each account can have a maximum of 350 tokens at any given time (7 days * tokens per day).</li> <li><strong>Added based on feedback</strong>: Each account could choose the precision of the voting tokens they use. If users wanted 500 tokens per day, based on 1% weight per token, the interface could be updated to reflect this. Useful for whales who want to be able to vote with 1%.</li> </ul><p>Instead of having a percentage value of how powerful your votes are, and a decreasing percentage with each vote in succession, this system assumes that an account would <strong>always</strong> vote with a set percentage of it's weight, derived it's steem power.</p> <h3>Why this direction?</h3> <p>It's a lot easier for a user to understand "I have 20 tokens left" than "ok, I have 88.47% voting power left, that means I have 2 100% votes left if I want to get back to 100% in around 24 hours".</p> <p>This is a cryptocurrency, people understand balances and tokens. In fact, most people understand these things based on any credit/token system they've ever used, or any video game they've ever played. The percentage style system itself, while accomplishing many great things with it's sophisticated nature, is honestly confusing as hell. I'm still confused by parts of it, and I'm a level beyond a power user.</p> <p>Simplifying this system into something easy to use, consumable, understandable and fun is going to help engage the hardcore as well as the casual users. These benefits are what is going to help steemit grow.</p> <h3>Comparing tokens to the new proposed 5 votes/day system</h3> <p>Does this whole thing sound somewhat reasonable? If so, were you one of the people incredibly against the proposed 5 votes/day limit in 0.14.0?</p> <p>You might be surprised, but this system is pretty similar to that. There's one fundamental change that allows additional flexibility, which I think would make the entire concept of limiting a lot more acceptable. Let's start with the similarities between the two systems:</p> <ul><li>If 50 Voting Tokens are awarded each day, each with 10% weight, this equals out to be 5x 100% votes per day. The same as proposed for 0.14.0.</li> <li>If you can use a maximum of 10 Voting Tokens per post, that's equal to 1x 100% weight vote, which is the same type of vote you can cast right now.</li> <li>The tokens would allow each user to vote on anywhere from 5 posts to 50 posts a day. Comparing tokens to vote weight, it would be between 5x 100% votes and 50x 10% votes per day.</li> <li>Regeneration intervals could be 50 tokens every 24 hours, 10 tokens every 4.8 hours, or 1 token every 28.8 minutes. This mirrors almost identically the proposed regeneration rate in 0.14.0.</li> </ul><p>So what was the one fundamental difference? <strong>The decrease in power after every vote</strong>. With the current (live) and proposed 0.14.0 system, after each vote your overall weight drops to a percentage. An example of this is:</p> <ul><li>An account is at 100% voting power with 100 SP.</li> <li>The account votes on a post, with 100% weight, applying the full weight of 100 SP.</li> <li>The account now has ~96% voting power.</li> <li>The account votes on a post, with 100% weight, and now because of voting power, it only applies ~96 SP worth of voting power.</li> <li>The account now has ~92% voting power.</li> <li>(repeat)</li> </ul><p>If you don't have a break between your votes, there's no regeneration, and your vote has less of an impact. I'm not a fan of this, even as a regular user. I visit sporadically throughout the day, and my votes are typically concentrated batches, which puts me at a disadvantage from someone (or something) that votes at the perfect times. I'd like to have the opportunity to have the same impact, as I imagine most people would.</p> <p>I think it's a bit crazy that just reshaping how this is presented, and altering one mechanic of the system, can have such a drastic impact on the perception towards it.</p> <h3>Notes on the interface and how users would see voting tokens</h3> <p>The interface for this system I imagine would be incredibly simple. You're going to have a number and an icon that looks like either a vote or a coin of some kind. Maybe both.</p> <ul><li><strong>Tokens could be represented as a simple number</strong> on the top navigation bar to indicate how many tokens you have stored and ready to use. This would be much easier to understand than an arbitrary percentage.</li> <li>After each vote, the UI can dynamically update to show your remaining tokens.</li> <li>The voting interface itself wouldn't have to change much, we could use the existing vote slider, except now it's a range from 1-10. We could also show a balance of tokens on the slider itself.</li> <li>This interface highlights a true hard cap on the number of votes. Technically this is already happening, since you can't vote if you're at 0% voting power. Most of us don't see it currently, but we likely would more often after 0.14.0.</li> <li>You would be unable to vote after expending all of your voting tokens, until you regenerated a new one.</li> <li>[Strike this, this isn't true in the current system and would make the system gameable, thanks @arhag] ~~If you uncast a vote, you would be returned your voting tokens, just like currently you are returned your voting power~~.</li> </ul><h3>Controlling the token distribution rates through witnessing</h3> <p>The configuration of this system should be delegated to witnesses. Moving these settings to witness votes would also prevent us from needing hard forks in the future. Witnesses could vote on these values, much like the account creation fee, to adapt as the communities demands change.</p> <ul><li>Witnesses can vote for <code>voting_token_per_day</code>, starting at 50 (per day).</li> <li>Witnesses can vote for <code>voting_token_limit</code>, starting to 350 (7 days worth).</li> </ul><p>The values would be set based on the median value of the top 19 witnesses, like all other votes.</p> <h3>Potential economic "sinks"</h3> <p>I'm throwing this out there as a "<strong>maybe</strong>", because this should be an entire concept explored itself. BUT, we might just be able to burn SBD/Steem to receive a proportional award of additional voting tokens. If you've got money to burn and want to vote on more things you could. Just burn a somewhat proportional amount of the chosen currency to get an equivalent amount of tokens.</p> <p>You get free tokens every day, but if you want more, pay. The "freemium" model.</p> <p>I could add another 3-5 paragraphs explaining the benefits of burned coins, but we'll save that for another day.</p> <h2>Improvements over the newly proposed system in 0.14.0</h2> <h3>Levels the playing field between humans and bots</h3> <p><strong>Problem:</strong> With the proposed new voting system in 0.14.0, you can cast 5x votes with 100% of your weight every 24 hours. But there's only one VERY specific way you can actually do it. Here's a example:</p> <ul><li>An account is at 100% Voting Power, and casts 1 vote @ 100% weight on a post.</li> <li>The account's Voting Power decreases to 96% because of the 100% weighted vote.</li> <li>4.8 hours pass, the account's Voting Power is now back at 100%.</li> <li>Repeat</li> </ul><p>This pattern gives the account the most impact for their 5 votes, all truly being at 100% within a 24 hour window.</p> <p>The problem with the above scenario is that you have to wait exactly 4.8 hours between votes to optimally achieve this, and most people aren't going to vote exactly every 4.8 hours. You know who can though? Bots. Bots have a clear advantage if the strategy is to cast all 5 votes each day at 100%. While weight and voting power is only a part of the overall strategy, it's something humans cannot compete against.</p> <p>You can also scale this down to any variable vote weight, which just reduces the time needed between votes (you could vote with 10% weight every 28.8 minutes and stay at 100%). Again, another win for bots.</p> <p><strong>How Voting Tokens Helps:</strong> The voting token system solves this problem by letting a user cast all 5 of those votes at any point in the 24 hour period, all at 100%.</p> <h3>Flexibility for daily or weekly curators</h3> <p><strong>Problem</strong>: In the current and proposed system, if you aren't on steemit for a few days, you're wasting the potential of your voting power and curation rewards.</p> <p>The majority of the population isn't going to visit steemit every day (whether we want them to or not), which gives the daily users and bots an advantage over the general public. Some may argue this is not a problem, and daily curators should be rewarded more, but we need a system that encourages casual participation as well. </p> <p>An example in the current system for a casual account would be:</p> <ul><li>An account is at 100% Voting Power on Saturday and ends up casting 15 votes @ 100% weight. Under the newly proposed rules, that accounts Voting Power would decrease to ~54.20%.</li> <li>As each vote is cast, the accounts voting power by ~4%.</li> <li>The account recharges to 100% Voting Power again by Monday night (20% per day).</li> <li>The account doesn't visit again until next Saturday, and has now wasted any potential regeneration cycles that could have been occurring Tuesday through Saturday.</li> </ul><p><strong>How Voting Tokens Helps:</strong> With the voting token system, this user could visit on a Saturday, and issue up to 35 votes at 100%, expending the entire balance of tokens. Then when visiting a week later, would be able to do the same again, allowing them the full benefit of their SP/Vest balance.</p> <h1>Final Thoughts</h1> <p>I'm putting this out here as a thought experiment. I'd love to hear what you think. What I've laid out likely has problems that I couldn't possibly foresee, so I also really want to know why this wouldn't work. I've been thinking about it on and off all day, and think there's a lot of merit here.</p> <p>I honestly don't know if the solution we're looking for is in adjusting the numbers of the current system. My current belief is that in order to get as close to perfection as possible, we may need to fundamentally change the system to be a more user friendly and forgiving system. I feel this is closer.</p>
post[html_preview] <p>I can't help but think we're now hitting the point where the system behind voting, voting power, is far too complicated. People don't seem to fully comprehend it (myself included), and as changes are made, we need to learn all over again. </p><p>We need something that can be packaged up in an easy to consume format with a simple UI. A system that overall feels like it benefits users over bots, and allows for semi-regular visitors to have an impact like daily visitors.</p>
post[image]
post[ts] 1472888685
steemdb.com - open source blockchain explorer and data playground (alpha release)
2016-08-24 | Tags: [steemdb] [steemstats] [steem]
links
Blog URL /steemdb/@jesta/steemdb-com-open-source-blockchain-explorer-and-data-playground-alpha-release
Steemit URL https://steemit.com/steemdb/@jesta/steemdb-com-open-source-blockchain-explorer-and-data-playground-alpha-release
SteemDB URL https://steemdb.com/steemdb/@jesta/steemdb-com-open-source-blockchain-explorer-and-data-playground-alpha-release
comment model

      Twig Examples:

      {{ post.title }}
      {{ post.author }}
      {{ post.body }}
    
post[id] 727733
post[author] jesta
post[permlink] steemdb-com-open-source-blockchain-explorer-and-data-playground-alpha-release
post[category] steemdb
post[parent_author]
post[parent_permlink] steemdb
post[title] steemdb.com - open source blockchain explorer and data playground (alpha release)
post[body] One thing I get asked for a lot on steemstats.com is historical data. The problem I ran into was in the way steemstats was designed - everything is loaded in real time from the blockchain. I needed a way to store and retrieve data based on time and date - [steemdb.com](https://steemdb.com) (steem database) is the concept I ended up with, which will allow all of us to use this data. Before I go further, **this post will be split into two parts**: the first part is for everyone and outlines the benefits [steemdb.com](https://steemdb.com) brings to steem users; and the second part for the developers interested in learning and/or contributing. Also - **This is a super early alpha, it might crash :)** # Introducing steemdb.com, the website steemdb is about being able to look at data in different ways, as well as back historically in time, using techniques that aren't currently available through the steem blockchain. It also serves as a playground for new ideas and experiments. It's a block explorer at heart, but doesn't feel like your typical explorer. I'd invite you to check out my account overview here: [https://steemdb.com/@jesta](https://steemdb.com/@jesta) or you can even continue reading this post via steemdb: [https://steemdb.com/steemdb/@jesta/steemdb-com-open-source-blockchain-explorer-and-data-playground-alpha-release](https://steemdb.com/steemdb/@jesta/steemdb-com-open-source-blockchain-explorer-and-data-playground-alpha-release) ### Currently steemdb allows you to do the following things: - View detailed account information + historical charts - View detailed information about posts - View the current witnesses + mining queue - Search for accounts using the box in the upper right - (Experiment #1) Browse posts by creation date, filter by tag, sorted by either votes or payouts **You currently can't do anything that requires a login** - steemdb is all about exploration for the time being. This post is going to get long, so for those of you who need a TLDR, I'd invite you to scroll through the small gallery of images below that show the various pages available. --- ## Account View Example: [https://steemdb.com/@jesta](https://steemdb.com/@jesta) The account view breaks down the different components of an account into separate tabs and tries to make the information easy to digest. You can look at anyone's account with this detail. It also charts and shows historical data for some areas of information to track changes over time. It's not mean to be a replacement to steemstats, but a tool that steemstats could link to to learn about others. **Much of this data will be available on steemstats.com in the near future**. I'll also hopefully be providing some public APIs of the same thing for everyone else to use. This is all dependent on how optimized I can make the data and how much the infrastructure would cost to scale. ![Imgur](http://i.imgur.com/sYfxZMo.png) --- ## Post View Example: [https://steemdb.com/steemstats/@jesta/steemstats-0-3-4-new-live-post-inspector-and-incoming-witness-votes](https://steemdb.com/steemstats/@jesta/steemstats-0-3-4-new-live-post-inspector-and-incoming-witness-votes) This was my take on how I'd want to explore the data behind a post. It's not interactive at this point, but already provides a bit more insight than we have here on steemit. It features the content broken out into a tabular view based on data aspect, and a sidebar that shows you about the author, other things they've written, and other meta information. I've also included buttons on each post to quickly view it on steemit.com, just in case you discover something you'd like to vote on or respond to. ![Imgur](http://i.imgur.com/tWkzLnJ.png) --- ## Witness View [https://steemdb.com/witnesses](https://steemdb.com/witnesses) This section is a mirror of the witness page on [https://steemd.com/witnesses](https://steemd.com/witnesses). It displays information important to the witnesses and miners on the steem network. ![Imgur](http://i.imgur.com/sLRUPdx.png) --- ## Posts by Date (Experiment #1) Example: [https://steemdb.com](https://steemdb.com) (the current homepage) This section was designed as an experimental view of data on the blockchain. This was my first attempt at organizing the data on steem in a more "content silo'd" fashion to see how it could be browsed. I plan on doing a number of experiments on different ways to view the content in an attempt to help determine the best way to present it. My thought is that I'll be able to move a lot faster (since it's a database, not a blockchain) and help prototype what sort of things we may see here someday on steemit.com. Currently, the posts page is set to: - **Grouping**: It's grouped by the `creation date`. You only view one day at a time, and can go forwards and backwards in time. - **Sorting**: Posts by default are sorted by payouts which can be changed to votes. - **First Tag Priority**: If you click on a tag, if will only show you posts where that is the **first tag**. It's pretty interesting to go back in time and view what was popular on specific dates. It's even more interesting when you pick a tag, and then paginate by date. I've found a few posts that I never would have seen by doing this. ![Imgur](http://i.imgur.com/BMfi8Ko.png) --- ![Imgur](http://i.imgur.com/wLnw4eT.png) --- ## What's next for steemdb.com (the website)? The short version is more historical data, charts, APIs and ways to view the data that exists on the blockchain. One of the biggest goals with steemdb is to help people learn about all the various aspects of the steem platform. steemstats.com has the same goal, but just from a very different angle. steemstats.com is about someone specific, and steemdb.com is about everyone in general. Over time, I think that these two projects will integrate with each other more and more. The steemdb platform will also be used to show the community alternate ways that the content here on steem can be presented. I plan on trying out a bunch of interfaces you're likely familiar with to see what works best and what the community would like. I feel the best way to actually garner feedback is with a prototype, so I plan on delivering them, hopefully with the help of others! Speaking of which... --- # Introducing aaroncox/steemdb - the code https://github.com/aaroncox/steemdb Let me start by saying I most definitely followed the mantra of "do things that don't scale" for this prototype. If I never updated this code ever again, it wouldn't be scalable to the size that I believe steem can achieve. In fact I don't even know how the servers will hold up with the announcement and general usage of the site. Gotta love these alpha versions! **It's also not really that easy to use yet**! The reasons for this are: - It's 2 weeks old - I used technologies I didn't have to learn - I'm learning the best ways to retrieve the data from the blockchain Just like steem itself, if you're going to get involved, you're going to have to be able to figure how things work without documentation (for now). Learn to ask questions - lots of them. I'd invite you to join the #steemdb channel on steemit.chat, as I'll try to focus any interested parties there. If you join to promote your posts... you're gonna get the evil eye. ### The technologies behind steemdb currently Technology stack was chosen based on technologies I've used recently, not what's best. I'm still working full time on other projects and steem is still only a portion of my time each week. So if I needed a hammer, and all I could find was a rock, I used it. That doesn't mean these technologies can't change and be adapted. Remember, it's an alpha and an experiment... Currently these are the components that make up the project: 1. **Data Storage**: MongoDB. Say what you will about it, but I was able to throw blocks of json at it, index it, and then begin querying/aggregating it. 2. **The Website**: Powered by PHP7/nginx, using the Phalcon 3 framework, and a small collection of composer packages. On the frontend it uses semantic-ui for UI and plottable.js for charts. It connects to MongoDB as well as directly to the steem blockchain (very lightly). 3. **The Services**: Written in Python3, and powered by Piston, these services act as the synchronization tools between the blockchain and the database. All of this is encapsulated in a variety of docker containers that's controlled through `docker-compose`. ### Future direction of the project Since this is the first release, a firm direction hasn't been set in stone. I'd like to see a number of improvements, as well as some optimizations, to really firm up it's core. Right now off the top of my head, I believe it's immediate future includes: - Some build processes to help manage js/css dependencies. It's very manual right now. You'll actually find a nice symlink from the public folder into the bower components. - Cleaning up the synchronization scripts so they don't store quite so much data. Right now there's a lot of duplicate data, including posts, so the database is huge. Luckily disk space is cheap right now, and the project is still rather limited. - The charts aren't in the best of places. The JS is actually stored in a volt file simply because docker was fighting me by corrupting my JS files. - Most of the aggregation queries should be moved out of the controllers and into the appropriate models for reusability. There's very little duplicate code right now, but it might get out of hand if that pattern continues. There are also some loftier goals of removing the frontend from PHP, and using something like react. This would make the PHP layer purely an API for the frontend to interact with. ### How do I run the damn thing? I will get a full development environment guide up in the coming weeks. It's going to take a **LOT** of disk space and some patience for the setup. You're going to have to build your own entire database version of the 4+ million blocks in the blockchain. Currently, completely unoptimized, it's consuming `21.943GB` of disk space on my server. If this is something you're interested in - the first step I'd take in getting started is setup a local steemd instance and synchronize the entire blockchain to a local computer/server. It just so happens I wrote a [guide on a web instance of steemd](https://steemit.com/steem/@jesta/building-a-high-availability-steemd-node-for-web-apis) a few weeks ago. I'd start there. The first step of running steemdb is going to be letting the services run for like 6-12 hours as it creates your database. --- # Wrapping things up I'm pretty excited about this project, being able to query the database for pretty much any bit of information is like having a super power. I will do my best to keep the community up to date of changes, digest feedback, and help shape it into another great tool for the community to use. Philosophically, steemdb is what I'd consider to be the 3rd and final part of the trinity of projects I've been working on: - steemstats: All about you and your data - steemdb: Aggregate information about everyone and everything - steempress: Taking your data and letting you start your own website These projects combined will hopefully form a powerful open source combination to help contribute to the overall steem ecosystem. steempress is up next in the list of priorities, with two new themes to implement and a few projects that have expressed interest in using it to power their ideas. As a current developer, backup witness, writer and normal guy - I hope to continue being a meaningful part of this community far into the future. Thank you all for your support!
post[json_metadata]
[tags]
[0] steemdb
[1] steemstats
[2] steem
[links]
[0] https://steemdb.com
post[last_update] 2016-08-24T05:25:54
post[created] 2016-08-24T05:23:54
post[active] 2016-09-10T22:21:42
post[last_payout] 2016-09-24T14:20:09
post[depth] 0
post[children] 64
post[children_rshares2] 0
post[net_rshares] 0
post[abs_rshares] 0
post[vote_rshares] 0
post[children_abs_rshares] 0
post[cashout_time] 1969-12-31T23:59:59
post[max_cashout_time] 1969-12-31T23:59:59
post[total_vote_weight] 0
post[reward_weight] 10000
post[total_payout_value] 4703.655 SBD
post[curator_payout_value] 475.071 SBD
post[author_rewards] 3369147
post[net_votes] 541
post[root_comment] 727733
post[max_accepted_payout] 1000000.000 SBD
post[percent_steem_dollars] 10000
post[allow_replies] 1
post[allow_votes] 1
post[allow_curation_rewards] 1
post[beneficiaries]
post[url] /steemdb/@jesta/steemdb-com-open-source-blockchain-explorer-and-data-playground-alpha-release
post[root_title] steemdb.com - open source blockchain explorer and data playground (alpha release)
post[pending_payout_value] 0.000 SBD
post[total_pending_payout_value] 0.000 STEEM
post[active_votes]
post[replies]
post[author_reputation] 71627050027202
post[promoted] 0.000 SBD
post[body_length] 0
post[reblogged_by]
post[html] <p>One thing I get asked for a lot on steemstats.com is historical data. The problem I ran into was in the way steemstats was designed - everything is loaded in real time from the blockchain. I needed a way to store and retrieve data based on time and date - <a href="https://steemdb.com">steemdb.com</a> (steem database) is the concept I ended up with, which will allow all of us to use this data.</p> <p>Before I go further, <strong>this post will be split into two parts</strong>: the first part is for everyone and outlines the benefits <a href="https://steemdb.com">steemdb.com</a> brings to steem users; and the second part for the developers interested in learning and/or contributing.</p> <p>Also - <strong>This is a super early alpha, it might crash :)</strong></p> <h1>Introducing steemdb.com, the website</h1> <p>steemdb is about being able to look at data in different ways, as well as back historically in time, using techniques that aren't currently available through the steem blockchain. It also serves as a playground for new ideas and experiments. It's a block explorer at heart, but doesn't feel like your typical explorer.</p> <p>I'd invite you to check out my account overview here:</p> <p><a href="https://steemdb.com/@jesta">https://steemdb.com/@jesta</a></p> <p>or you can even continue reading this post via steemdb:</p> <p><a href="https://steemdb.com/steemdb/@jesta/steemdb-com-open-source-blockchain-explorer-and-data-playground-alpha-release">https://steemdb.com/steemdb/@jesta/steemdb-com-open-source-blockchain-explorer-and-data-playground-alpha-release</a></p> <h3>Currently steemdb allows you to do the following things:</h3> <ul><li>View detailed account information + historical charts</li> <li>View detailed information about posts</li> <li>View the current witnesses + mining queue</li> <li>Search for accounts using the box in the upper right</li> <li>(Experiment #1) Browse posts by creation date, filter by tag, sorted by either votes or payouts</li> </ul><p><strong>You currently can't do anything that requires a login</strong> - steemdb is all about exploration for the time being.</p> <p>This post is going to get long, so for those of you who need a TLDR, I'd invite you to scroll through the small gallery of images below that show the various pages available.</p> <hr /><h2>Account View</h2> <p>Example: <a href="https://steemdb.com/@jesta">https://steemdb.com/@jesta</a></p> <p>The account view breaks down the different components of an account into separate tabs and tries to make the information easy to digest. You can look at anyone's account with this detail. It also charts and shows historical data for some areas of information to track changes over time. It's not mean to be a replacement to steemstats, but a tool that steemstats could link to to learn about others.</p> <p><strong>Much of this data will be available on steemstats.com in the near future</strong>. I'll also hopefully be providing some public APIs of the same thing for everyone else to use. This is all dependent on how optimized I can make the data and how much the infrastructure would cost to scale.</p> <p><img src="http://i.imgur.com/sYfxZMo.png" alt="Imgur" /></p> <hr /><h2>Post View</h2> <p>Example: <a href="https://steemdb.com/steemstats/@jesta/steemstats-0-3-4-new-live-post-inspector-and-incoming-witness-votes">https://steemdb.com/steemstats/@jesta/steemstats-0-3-4-new-live-post-inspector-and-incoming-witness-votes</a></p> <p>This was my take on how I'd want to explore the data behind a post. It's not interactive at this point, but already provides a bit more insight than we have here on steemit. It features the content broken out into a tabular view based on data aspect, and a sidebar that shows you about the author, other things they've written, and other meta information.</p> <p>I've also included buttons on each post to quickly view it on steemit.com, just in case you discover something you'd like to vote on or respond to.</p> <p><img src="http://i.imgur.com/tWkzLnJ.png" alt="Imgur" /></p> <hr /><h2>Witness View</h2> <p><a href="https://steemdb.com/witnesses">https://steemdb.com/witnesses</a></p> <p>This section is a mirror of the witness page on <a href="https://steemd.com/witnesses">https://steemd.com/witnesses</a>. It displays information important to the witnesses and miners on the steem network.</p> <p><img src="http://i.imgur.com/sLRUPdx.png" alt="Imgur" /></p> <hr /><h2>Posts by Date (Experiment #1)</h2> <p>Example: <a href="https://steemdb.com">https://steemdb.com</a> (the current homepage)</p> <p>This section was designed as an experimental view of data on the blockchain. This was my first attempt at organizing the data on steem in a more "content silo'd" fashion to see how it could be browsed.</p> <p>I plan on doing a number of experiments on different ways to view the content in an attempt to help determine the best way to present it. My thought is that I'll be able to move a lot faster (since it's a database, not a blockchain) and help prototype what sort of things we may see here someday on steemit.com.</p> <p>Currently, the posts page is set to:</p> <ul><li><strong>Grouping</strong>: It's grouped by the <code>creation date</code>. You only view one day at a time, and can go forwards and backwards in time.</li> <li><strong>Sorting</strong>: Posts by default are sorted by payouts which can be changed to votes.</li> <li><strong>First Tag Priority</strong>: If you click on a tag, if will only show you posts where that is the <strong>first tag</strong>.</li> </ul><p>It's pretty interesting to go back in time and view what was popular on specific dates. It's even more interesting when you pick a tag, and then paginate by date. I've found a few posts that I never would have seen by doing this.</p> <p><img src="http://i.imgur.com/BMfi8Ko.png" alt="Imgur" /></p> <hr /><p><img src="http://i.imgur.com/wLnw4eT.png" alt="Imgur" /></p> <hr /><h2>What's next for steemdb.com (the website)?</h2> <p>The short version is more historical data, charts, APIs and ways to view the data that exists on the blockchain.</p> <p>One of the biggest goals with steemdb is to help people learn about all the various aspects of the steem platform. steemstats.com has the same goal, but just from a very different angle. steemstats.com is about someone specific, and steemdb.com is about everyone in general.</p> <p>Over time, I think that these two projects will integrate with each other more and more.</p> <p>The steemdb platform will also be used to show the community alternate ways that the content here on steem can be presented. I plan on trying out a bunch of interfaces you're likely familiar with to see what works best and what the community would like.</p> <p>I feel the best way to actually garner feedback is with a prototype, so I plan on delivering them, hopefully with the help of others! </p> <p>Speaking of which...</p> <hr /><h1>Introducing aaroncox/steemdb - the code</h1> <p>https://github.com/aaroncox/steemdb</p> <p>Let me start by saying I most definitely followed the mantra of "do things that don't scale" for this prototype. If I never updated this code ever again, it wouldn't be scalable to the size that I believe steem can achieve. In fact I don't even know how the servers will hold up with the announcement and general usage of the site. Gotta love these alpha versions!</p> <p><strong>It's also not really that easy to use yet</strong>! The reasons for this are: </p> <ul><li>It's 2 weeks old</li> <li>I used technologies I didn't have to learn</li> <li>I'm learning the best ways to retrieve the data from the blockchain</li> </ul><p>Just like steem itself, if you're going to get involved, you're going to have to be able to figure how things work without documentation (for now). Learn to ask questions - lots of them.</p> <p>I'd invite you to join the #steemdb channel on steemit.chat, as I'll try to focus any interested parties there. If you join to promote your posts... you're gonna get the evil eye.</p> <h3>The technologies behind steemdb currently</h3> <p>Technology stack was chosen based on technologies I've used recently, not what's best. I'm still working full time on other projects and steem is still only a portion of my time each week. So if I needed a hammer, and all I could find was a rock, I used it.</p> <p>That doesn't mean these technologies can't change and be adapted. Remember, it's an alpha and an experiment...</p> <p>Currently these are the components that make up the project:</p> <ol><li><strong>Data Storage</strong>: MongoDB. Say what you will about it, but I was able to throw blocks of json at it, index it, and then begin querying/aggregating it.</li> <li><strong>The Website</strong>: Powered by PHP7/nginx, using the Phalcon 3 framework, and a small collection of composer packages. On the frontend it uses semantic-ui for UI and plottable.js for charts. It connects to MongoDB as well as directly to the steem blockchain (very lightly).</li> <li><strong>The Services</strong>: Written in Python3, and powered by Piston, these services act as the synchronization tools between the blockchain and the database.</li> </ol><p>All of this is encapsulated in a variety of docker containers that's controlled through <code>docker-compose</code>.</p> <h3>Future direction of the project</h3> <p>Since this is the first release, a firm direction hasn't been set in stone. I'd like to see a number of improvements, as well as some optimizations, to really firm up it's core.</p> <p>Right now off the top of my head, I believe it's immediate future includes:</p> <ul><li>Some build processes to help manage js/css dependencies. It's very manual right now. You'll actually find a nice symlink from the public folder into the bower components.</li> <li>Cleaning up the synchronization scripts so they don't store quite so much data. Right now there's a lot of duplicate data, including posts, so the database is huge. Luckily disk space is cheap right now, and the project is still rather limited.</li> <li>The charts aren't in the best of places. The JS is actually stored in a volt file simply because docker was fighting me by corrupting my JS files.</li> <li>Most of the aggregation queries should be moved out of the controllers and into the appropriate models for reusability. There's very little duplicate code right now, but it might get out of hand if that pattern continues.</li> </ul><p>There are also some loftier goals of removing the frontend from PHP, and using something like react. This would make the PHP layer purely an API for the frontend to interact with.</p> <h3>How do I run the damn thing?</h3> <p>I will get a full development environment guide up in the coming weeks. It's going to take a <strong>LOT</strong> of disk space and some patience for the setup. You're going to have to build your own entire database version of the 4+ million blocks in the blockchain. Currently, completely unoptimized, it's consuming <code>21.943GB</code> of disk space on my server.</p> <p>If this is something you're interested in - the first step I'd take in getting started is setup a local steemd instance and synchronize the entire blockchain to a local computer/server. It just so happens I wrote a <a href="https://steemit.com/steem/@jesta/building-a-high-availability-steemd-node-for-web-apis">guide on a web instance of steemd</a> a few weeks ago. I'd start there.</p> <p>The first step of running steemdb is going to be letting the services run for like 6-12 hours as it creates your database.</p> <hr /><h1>Wrapping things up</h1> <p>I'm pretty excited about this project, being able to query the database for pretty much any bit of information is like having a super power. I will do my best to keep the community up to date of changes, digest feedback, and help shape it into another great tool for the community to use.</p> <p>Philosophically, steemdb is what I'd consider to be the 3rd and final part of the trinity of projects I've been working on:</p> <ul><li>steemstats: All about you and your data</li> <li>steemdb: Aggregate information about everyone and everything</li> <li>steempress: Taking your data and letting you start your own website</li> </ul><p>These projects combined will hopefully form a powerful open source combination to help contribute to the overall steem ecosystem. steempress is up next in the list of priorities, with two new themes to implement and a few projects that have expressed interest in using it to power their ideas.</p> <p>As a current developer, backup witness, writer and normal guy - I hope to continue being a meaningful part of this community far into the future. Thank you all for your support!</p>
post[html_preview] <p>One thing I get asked for a lot on steemstats.com is historical data. The problem I ran into was in the way steemstats was designed - everything is loaded in real time from the blockchain. I needed a way to store and retrieve data based on time and date - steemdb.com (steem database) is the concept I ended up with, which will allow all of us to use this data.</p><p>Before I go further, this post will be split into two parts: the first part is for everyone and outlines the benefits steemdb.com brings to steem users; and the second part for the developers interested in learning and/or contributing.</p>
post[image] http://i.imgur.com/sYfxZMo.png
post[ts] 1472034234
Dockerized + Pistonized version of clayop/steemfeed for Witnesses
2016-08-15 | Tags: [witness-category] [steem] [witnesses]
links
Blog URL /witness-category/@jesta/dockerized-pistonized-version-of-clayop-steemfeed-for-witnesses
Steemit URL https://steemit.com/witness-category/@jesta/dockerized-pistonized-version-of-clayop-steemfeed-for-witnesses
SteemDB URL https://steemdb.com/witness-category/@jesta/dockerized-pistonized-version-of-clayop-steemfeed-for-witnesses
comment model

      Twig Examples:

      {{ post.title }}
      {{ post.author }}
      {{ post.body }}
    
post[id] 606336
post[author] jesta
post[permlink] dockerized-pistonized-version-of-clayop-steemfeed-for-witnesses
post[category] witness-category
post[parent_author]
post[parent_permlink] witness-category
post[title] Dockerized + Pistonized version of clayop/steemfeed for Witnesses
post[body] ![https://blog.docker.com/wp-content/uploads/2013/08/KuDr42X_ITXghJhSInDZekNEF0jLt3NeVxtRye3tqco.png](https://blog.docker.com/wp-content/uploads/2013/08/KuDr42X_ITXghJhSInDZekNEF0jLt3NeVxtRye3tqco.png) [As a brand new witness](https://steemit.com/witness-category/@jesta/witness-thread-jesta), I was having one hell of a time getting everything setup for my `publish_feed`script. Everything I found needed a cli_wallet running and serving a http rpc with my key in it. Unlocking and locking wallets felt a little insecure and I figured there had to be a better way. I started doing research on how we could do away with the cli_wallet instance as a requirement and make it a standalone application. After a half day of research, I forked [clayop/steemfeed](https://github.com/clayop/steemfeed) and creating a new version that no longer uses the cli_wallet, but instead uses @xeroc's [piston](https://github.com/xeroc/piston). It creates the signed `publish_feed` transactions and broadcasts them via the database_api rather than the wallet_api. I also wrapped it in a docker configuration for easier management. Special thanks to everyone (including @clayop) who worked on this project previously. You can find my fork of this steemfeed publishing tool here: https://github.com/aaroncox/steemfeed [You can also view all of the changes I've made in this single commit](https://github.com/aaroncox/steemfeed/commit/2d197e703491d1b0650049ac73b4d7f49433c105). # Running ## Installing Docker I'm not going to go into detail about installing docker, [there's plenty of documentation for that already](https://docs.docker.com/engine/installation/). Just make sure docker works from your command line, `docker info` is a good command to see if you're connected properly. ## Clone the Repository Clone down the repository to the desired location: `git clone git@github.com:aaroncox/steemfeed.git` ## Configuration The entire configuration is now controlled through a `.env` file that you'll create inside of the project. I've placed a template file, `.example.env`, in the root of the project that you can copy as a default. Copy the example to the proper place: `cp .example.env .env` Then open this file in your favorite editor. There are only 2 values you **need** to fill out: - **feed_account**: The account name of the witness account. - **feed_wif**: The WIF ACTIVE Private Key for the witness account. This is used to sign transactions. There are plenty of other adjustable configuration options, all of which already have default values. ## Run it There are two ways to run this in docker: ### Run in the foreground If you'd like for this to be an active process on your machine, run this command: `docker-compose up` The output of the application will be displayed on your terminal window. To stop the process, use `CTRL+C`. ### Run in the background (daemon) If you'd like for this to be a background process on your machine, run this command: `docker-compose up -d` If you'd like to view it's logs, you should be able to just run: `docker logs -f steemfeed_app_1` To stop the background process: `docker stop steemfeed_app_1` ## Rebuilding the Docker image due to Code Changes Since this is docker, the code has been copied in place during your first build. If you are modifying the code itself and need to rebuild the docker image, you can run: `docker-compose build` If you're actively developing and want to rebuild and run, just run: `docker-compose build && docker-compose up` ## That's it! You've got a price feed updater running now. Feel free to suggest changes, fork my code, or submit some pull requests! I'm pretty thrilled with how this all worked out, though there are still a few things that need to be done: - The two classes I added, `Exchange_rate` and `Feed_publish` will need to be implemented eventually (and properly) into the libraries provided by @xeroc. - Default values should probably be defined if the environmental variables are unset. - I cleaned up the dependancies as best I could, but there may still be some strays. I'm still relatively new to python. Good luck witnessing!
post[json_metadata]
[tags]
[0] witness-category
[1] steem
[2] witnesses
[users]
[0] xeroc
[1] clayop
[image]
[0] https://blog.docker.com/wp-content/uploads/2013/08/KuDr42X_ITXghJhSInDZekNEF0jLt3NeVxtRye3tqco.png
post[last_update] 2016-08-15T03:59:06
post[created] 2016-08-15T01:03:54
post[active] 2016-08-16T09:53:45
post[last_payout] 2016-09-14T15:56:57
post[depth] 0
post[children] 8
post[children_rshares2] 0
post[net_rshares] 0
post[abs_rshares] 0
post[vote_rshares] 0
post[children_abs_rshares] 0
post[cashout_time] 1969-12-31T23:59:59
post[max_cashout_time] 1969-12-31T23:59:59
post[total_vote_weight] 0
post[reward_weight] 10000
post[total_payout_value] 199.367 SBD
post[curator_payout_value] 26.713 SBD
post[author_rewards] 141725
post[net_votes] 212
post[root_comment] 606336
post[max_accepted_payout] 1000000.000 SBD
post[percent_steem_dollars] 10000
post[allow_replies] 1
post[allow_votes] 1
post[allow_curation_rewards] 1
post[beneficiaries]
post[url] /witness-category/@jesta/dockerized-pistonized-version-of-clayop-steemfeed-for-witnesses
post[root_title] Dockerized + Pistonized version of clayop/steemfeed for Witnesses
post[pending_payout_value] 0.000 SBD
post[total_pending_payout_value] 0.000 STEEM
post[active_votes]
post[replies]
post[author_reputation] 71627050027202
post[promoted] 0.000 SBD
post[body_length] 0
post[reblogged_by]
post[html] <p><img src="https://blog.docker.com/wp-content/uploads/2013/08/KuDr42X_ITXghJhSInDZekNEF0jLt3NeVxtRye3tqco.png" alt="https://blog.docker.com/wp-content/uploads/2013/08/KuDr42X_ITXghJhSInDZekNEF0jLt3NeVxtRye3tqco.png" /></p> <p><a href="https://steemit.com/witness-category/@jesta/witness-thread-jesta">As a brand new witness</a>, I was having one hell of a time getting everything setup for my <code>publish_feed</code>script. Everything I found needed a cli<em>wallet running and serving a http rpc with my key in it. Unlocking and locking wallets felt a little insecure and I figured there had to be a better way. I started doing research on how we could do away with the cli</em>wallet instance as a requirement and make it a standalone application.</p> <p>After a half day of research, I forked <a href="https://github.com/clayop/steemfeed">clayop/steemfeed</a> and creating a new version that no longer uses the cli<em>wallet, but instead uses @xeroc's <a href="https://github.com/xeroc/piston">piston</a>. It creates the signed <code>publish_feed</code> transactions and broadcasts them via the database</em>api rather than the wallet_api. I also wrapped it in a docker configuration for easier management. Special thanks to everyone (including @clayop) who worked on this project previously. </p> <p>You can find my fork of this steemfeed publishing tool here: https://github.com/aaroncox/steemfeed</p> <p><a href="https://github.com/aaroncox/steemfeed/commit/2d197e703491d1b0650049ac73b4d7f49433c105">You can also view all of the changes I've made in this single commit</a>.</p> <h1>Running</h1> <h2>Installing Docker</h2> <p>I'm not going to go into detail about installing docker, <a href="https://docs.docker.com/engine/installation/">there's plenty of documentation for that already</a>. Just make sure docker works from your command line, <code>docker info</code> is a good command to see if you're connected properly. </p> <h2>Clone the Repository</h2> <p>Clone down the repository to the desired location:</p> <p><code>git clone git@github.com:aaroncox/steemfeed.git</code></p> <h2>Configuration</h2> <p>The entire configuration is now controlled through a <code>.env</code> file that you'll create inside of the project. I've placed a template file, <code>.example.env</code>, in the root of the project that you can copy as a default. Copy the example to the proper place:</p> <p><code>cp .example.env .env</code></p> <p>Then open this file in your favorite editor. There are only 2 values you <strong>need</strong> to fill out:</p> <ul><li><strong>feed_account</strong>: The account name of the witness account.</li> <li><strong>feed_wif</strong>: The WIF ACTIVE Private Key for the witness account. This is used to sign transactions.</li> </ul><p>There are plenty of other adjustable configuration options, all of which already have default values.</p> <h2>Run it</h2> <p>There are two ways to run this in docker:</p> <h3>Run in the foreground</h3> <p>If you'd like for this to be an active process on your machine, run this command:</p> <p><code>docker-compose up</code></p> <p>The output of the application will be displayed on your terminal window. To stop the process, use <code>CTRL+C</code>. </p> <h3>Run in the background (daemon)</h3> <p>If you'd like for this to be a background process on your machine, run this command:</p> <p><code>docker-compose up -d</code></p> <p>If you'd like to view it's logs, you should be able to just run:</p> <p><code>docker logs -f steemfeed_app_1</code></p> <p>To stop the background process:</p> <p><code>docker stop steemfeed_app_1</code></p> <h2>Rebuilding the Docker image due to Code Changes</h2> <p>Since this is docker, the code has been copied in place during your first build. If you are modifying the code itself and need to rebuild the docker image, you can run:</p> <p><code>docker-compose build</code></p> <p>If you're actively developing and want to rebuild and run, just run:</p> <p><code>docker-compose build &amp;&amp; docker-compose up</code></p> <h2>That's it!</h2> <p>You've got a price feed updater running now. Feel free to suggest changes, fork my code, or submit some pull requests! </p> <p>I'm pretty thrilled with how this all worked out, though there are still a few things that need to be done:</p> <ul><li>The two classes I added, <code>Exchange_rate</code> and <code>Feed_publish</code> will need to be implemented eventually (and properly) into the libraries provided by @xeroc. </li> <li>Default values should probably be defined if the environmental variables are unset.</li> <li>I cleaned up the dependancies as best I could, but there may still be some strays. I'm still relatively new to python.</li> </ul><p>Good luck witnessing!</p>
post[html_preview] <p>As a brand new witness, I was having one hell of a time getting everything setup for my publish_feedscript. Everything I found needed a cliwallet running and serving a http rpc with my key in it. Unlocking and locking wallets felt a little insecure and I figured there had to be a better way. I started doing research on how we could do away with the cliwallet instance as a requirement and make it a standalone application.</p><p>After a half day of research, I forked clayop/steemfeed and creating a new version that no longer uses the cliwallet, but instead uses @xeroc's piston. It creates the signed publish_feed transactions and broadcasts them via the databaseapi rather than the wallet_api. I also wrapped it in a docker configuration for easier management. Special thanks to everyone (including @clayop) who worked on this project previously. </p>
post[image] https://blog.docker.com/wp-content/uploads/2013/08/KuDr42X_ITXghJhSInDZekNEF0jLt3NeVxtRye3tqco.png
post[ts] 1471241034
accounts
accounts loaded from the configuration
tags
tags loaded from the configuration
steem configuration
    resources/config/config.yaml - `steem` variable
  
host https://node.steem.ws
blog configuration
    resources/config/config.yaml - `blog` variable
  
theme develop
title reprint powered blog
subtitle blockchain powered blog
elements
[author] 1
[category] 1
[payout] 1
[votes] 1
[comments] 1
filters
[accounts]
[jesta]
[0] post