What is Curator?
Curator is an app for organized curation of Steem posts; curator comes with curating interface and full automated smart voting bot functionality. Posts can be filtered by app, category or author.
Repo: https://github.com/peerquery/curator
Demo: https://steem-curator.herokuapp.com
What can curator do?
Curator comes with the following functionalities:
Dashboard
Curator comes with a minimalist but informative dashboard to view:
- bot's stat's: voting power, steem power, delegation and more
- curation stats: total posts for the day, daily goal, approved, ...
- team strength and a few other details
Curation
The curation page allows team members to view posts and approve or reject a post. To prevent double curation, each post is shown to a curator only once, and no two curators will see the same posts at once.
Curators have the choice to approve, reject or ignore a post; there is no option to report or flag yet. For approved posts, the percent of vote(weight in %) the bot should deliver and the corresponding ratings are:
- 1% Nice
- 3% Average
- 5% Interesting
- 10% genius
- 15% Awesome
- 20% Remarkable
- 25% Exceptional
- 30% Outstanding
Re-curation
In the same curation page, every already approved post can be re-curated as re-rejected. Similarly, every rejected post can be re-approved.
Currently, anyone can re-curate an already curated post. In the next update this functionality will be reserved for moderators. That way curators can only curate a post once, then only moderators can re-curate already curated posts.
Voting bot
The owner sets the voting interval for the bot in the .env file. The bot fetches one approved post from and DB and votes it at the frequency of the interval set by the owner in the .env file(VOTE_INTERVAL_MINUTES).
In the demo interval in the is 5 minutes, so every 5 minutes the bot will check for one approved posts and vote it. After voting, the bot will comment on the post, building the comment from:
- the curator and approved %; eg: Approved for 5% vote by
- curator's remarks about the curation; eg: Very nice and original work
- default site message of the main project as set by owner/admins; eg: Visit us at cr.tor. Looking for something to support? Delegate SP to support our work!
In the above case, the final comment for the post would be:
Approved for 5% vote by
Remarks: Very nice and original work.
Visit us at cr.tor. Looking for something to support? Delegate SP to support our work!
The vote amount in USD calculated during vote and added to recorded for the post on the post in the DB. This way we can see the amount awarded for every voted post.
In next editions, this will be used to calculated how much money has been awarded to all curators by the project and more.
For posts rejected by curators or moderators, no comment is left on their post. Curation is a voluntary service, hence authors will not have their posts spammed with messages of rejection since they might never have asked for it to be curated. For instance, if you are curating on the tag: love, or on all posts from the app busy.app, not everyone whose posts come from these category or app are interested in your curation service. Hence if you do not appreciate their content, there is no need to "spam" it with a rejection message.
Team functionality
Curator is built for team work. There is no limit to the number of people that could be added to a team. To add a person, you simple get their Steem account and email. Then you send them a invite using the Curator's team page. They will receive an email with a secure link to activate and set their password.
There are four roles in a Curator team, in the order of decreasing authority:
- Owner - the entity(person, business or org) that installed the Curator server. The owner account is created during DB setup even before the server is launched - using info from the .env file. This account has veto and cannot be managed. There can be only one owner account, in general terms will be considered as super-admin.
- Admins - the admins are added by the owner or another admin only. Admins will manage sitewide settings(bot rate, bot resting day, footer text, ...), moderators and curators. There can be multiple admins. Admins manage the team and can add(invite) or remove a moderator or curator. Admins can admit a user to the banned blacklist group.
- Moderators - moderators will only inspect the work of curators - prior to the work being voted by the bot. Moderators can approve(termed re-approve) a post rejected by a curator or they can reject(termed re-reject) a post approved by a curator(both activities are termed re-curation). Moderators can admit a user to the probation blacklist group.
- Curators - curators will simple curate: approve or reject a post. Curators can only report users to the blacklist, but only moderators can admit a user to the banned blacklist group.
Please note that these separation of capabilities will be implemented in the next update. For now all users have full admin(not super-admin/owner) rights.
The non-curation members include:
- sponsors: sponsors who will delegate Steem Power to users
- editor: prepare editorial summary of top curated posts to be published on curation blog or as content for email digest
- developer: frontend customization, pulling updates via Git and development of custom features
Team activity stream
The Activity page lets you see a stream of activities of the team. You can view curation, re-curation, team management and more.
Not all activity views are active in this version yet.
Secure auth
Curator's auth system is built to be very secure, using the latest Node.js security measures. No passwords are handled beyond the server, all passwords are hashed with 12 rounds of bcrypt salt.
No passwords are auto-generated. New team members only receive email to set their own password, which in the future will be validated for strength.
All activation tokens are hashed with their hashes stored in DB, also they are one-time tokens. Logged users receive an httpOnly signed cookie which contains the JWTs of their account, email, role and authority.
JWTs are read only on the server where a user object created and added to the navbar using the .ejs renderer. This means the entire stateless auth system is handled server side.
Password reset comes with a confirmation email to inform the user of all password resets.
You can review the code for yourself, and if you find an loopholes please create an issues or fixing pull.
Blacklist system
Curator's blacklist allows the team(owner, admins, moderators and curators) to exclude certain authors from Curation. This is for excluding known spammers or authors whose content does not meet a Curator community's standards.
There are 4 different categories of blacklists:
- Reported: This is where authors are admitted to when their content is flagged by a Curator. Authors on reported list for a week who have not been admitted to probation will be eligible to have their reported status removed.
- Probation: Moderators review reported authors and admit those deserving on probation. After a month of being on probation, if an author is not admitted to the banned category then their probation can be lifted.
- Banned: This is reserved for admin to banned users. Users on the banned lists will be banned for at least a year before their banned could be removed.
- Opt-out: this is for authors who ask to be excluded from a Curation service but also serves a very important second purpose: all team members are automatically put on the out-out list. This way content from none of the team will be indexed for Curation.
Note: the full functionality of the blacklist will be implemented in coming updates. For now, all you can do is simple admit accounts to blacklist.
Landing page
The landing page of Curator is the homepage. For now its only a static page but in the next update will come with dynamic content to show the sponsors, and live statistics(total team, total amount in $ rewarded, total curation, ...).
Curator also comes with a custom 404 page.
Why Curator?
The main reason for developing curator is to serve as a common curation interface for the coming Peer Query beta. However I realized Steem lacks a common curation tool, and most curators rely on either SteemSQL and the PowerBI interface or Discord servers for curation.
Then came the idea to develop Curator as a standalone(from Peer Query) app so anyone could deploy it to curate content on Steem regardless of the app, author or category.
Initially I had wanted to build Curator without an internal content DB such that it would rely on App Stream's curation APIs. However, I realized App Stream was too much of a heavyweight for a simple community service.
Most people would not want to deploy several resources to host App Stream just to be able to use Curator. Hence I borrowed App Stream's content-to-DB filtering modules for Curator, making it a single standalone curation app.
Who can use curator?
Anyone can use curator. For the initial setup you would need to know HTML to do a few editing on the frontend as well as how to deploy a Node.js app.
How can Curator help?
Serve as common Curation interface
With the coming features such as chat in next updates, curation on Steem should be easier and less depended on general purposes apps such as Steemit chat and Discord.
Improve Steem content quality
While this version is only a demonstration of the concepts behind Curator, I hope the subsequent versions would be adopted by curation communities.
With the ease of curation provided by curator, hopefully more people will get into the business of curation. In the advent of curation-as-a-business movement, content quality on Steem would be improved, great authors would be rewarded and hopefully investors would appreciate Steem more.
Serve as app Curation interface
Curator might be an easy way for Steem apps and dapps owners and communities such as steemit, busy, utopian, dtube, steempress, peerquery beta(coming soon) and more to curate content from their communities.
Note that its not just the app creators but also the community who can curate from an app. Consider, since just about anyone can deploy Curator, multiple parties can curate from the app: Steemit, Busy, .... The same can be said of categories and authors.
In the extreme case for example, when the future "official" Peer Query curation is live but a segment of the community does not appreciate our work, they could easily deploy their own Curator-powered Curation service to curate content the tag or app: "peerquery" and compete with the "official" Peer Query curation. The same can be said of other apps.
This possibility will allow for multiple Curator-powered services to exist even on the same category, app or author. Curation monopoly would not be possible, and the advent of competing Curation services would cause curators to maintain a high standard to ask to attract more Steem Power delegation.
Separate app from community(hivemind?)
Traditionally, the most common way to curate content from a client is if it is created from it. With Curator, you can curate content even without an app.
Without a client at all, a Curator-powered curation service can curate on posts from a tag, regardless of the app they are created on.
This is great for community building and community tailored curation services. You can curate by a article category, author or publishing app.
Connect witnesses and community(curation-as-a-service)
While Steem is a social blockchain, most of the witnesses campaigns have become sole capitalist ventures. If more communities were adopt Curator, this could change.
Curator could provide an opportunity for witnesses and wanna-be witnesses to delegate Steem Power to support curation services in their respective communities.
Such a social contribution would let witnesses show their respect and support for the community's authors. In turn, I believe most community members would vote for witnesses who have delegated Steem Power to curate content from their community.
Become a sustainable SMT business model(curation-as-a-business)
With the advanced version of Curator and Smart Media Tokens(SMT), anyone can setup a curation service powered by their own SMT.
In the coming updates of Curator, the bot system will be able to vote:
- content from the projects' blog
- vote content from the team's members' blog accounts
This model will mean that the Curator model could become a self-sustaining business model which financially rewards not only authors but also the team and also finances the project itself.
Two interesting features coming up are Curator/curation-based reputation and email digest subscriptions. Exciting times are ahead for curation, # curation-as-a-service and # curation-as-a-business.
Current state of Curator
The current state of Curator is only a minimum viable product. According to my testing and as evident on the demo, Curator does most of the things it is expected to do.
Curator could be used to curate and upvote posts on Steem, invite/add team members and vote on crated content. The system works, however bear in mind that's its still work in progress.
If you find any bugs, you might want to create issues to highlight it. I will be updating Curator swiftly and in a timely manner.
What's next for Curator
Lots of exciting features(modules) are in development while some are in testing and will be integrated in the next update. Coming features include for next update:
- team profile/account page
- team wallet page to view earnings
- sponsors showcase and bluff page removal page in office
- sponsors listing and management page
- segregation of team capabilities according to role
- community page for authors
- reputation system for authors
- password reset for team
In cooking pot
- full voting bot to vote projects's blog and blog of curators and other team members
- socket.io live chat for team members with three modes: public, personal and snap
- email subscribe option for community to receive digests of curated posts
- documentation and support pages for Curator
- sitewide settings control page for user, admins and owner
- dynamic sitemap to allow indexing of pages by search engines
- public api to allow for thirdparty developer to access selected data for their apps
- feature improvements and minor updates
- page templates for footer links
- full working blacklist system
Tech stack:
- Node.js
- DSteem
- Mysql
- Semantic UI
- JQuery
Install recommendation
Curator is developed to facilitate group curation, making it obvious you would need a team to work on curator. One team member however which is not very visible but very important is a frontend web developer with GIT experience.
If you intend to use the current Curator or any of the future updates, I would strongly recommend you get a developer on your team for two important reasons:
You need a developer for frontend editing
As you can see on the demo, Curator has a default homepage with custom placeholder content. However, if you are to use Curator, you would definitely want to use a have your own custom version which would have customized content according to your vision, goals and brand.
Since the frontend of Curator is only static .ejs(.html) files with no UI frontend framework(no React, Vue, Angular), any web developer with only basic HTML(no need for CSS or JS) knowledge can edit them.
You need a developer for repo branch management
Curator would see major new features and improvements in next updates, Curator is not fully automated or dynamic. Most of the pages are static .ejs(.html) templates which are served.
During setup, you would be required to update(edit) these static templates by replacing the placeholder texts and images used in the default source code with your own brand information.
However, every new update comes with the default placeholder content, hence if you attempt to directly use a new update, all your custom branded content would be lost and would require you to set them up again - even though your DB content and already curated works would still remain intact.
For this reason you would need a develop with GIT experience who can pull only the updates to your repo without pulling and merging the entire repo which would only override your custom content with the default contents.
Let me use an example to illustrate this: you setup Curator, then in the next update you attempt to use the entire new code repo. What would happen is that the source homepage would override your current homepage content. After such an indiscriminate update(which I am cautioning against), your homepage would look like the one in the demo - all your custom edits would be gone.
With a developer with GIT experience, you can pull only the updates into your repo without pulling the entire repo.
If you do not want to deal with branch management, you might want to wait for a more matured version to before deploying.
Using Curator
Installation
Like App Stream, Curator uses native Mysql(no Sequelize), lots of tables, views and lots(40+) of complex stored procedures.
Manual setup would be tedious and inefficient, hence a custom setup manager module automatically setups the DB for you, creating all tables, all inserting all default data as well as creating all stored procedures for you.
Follow the following setups to Curator locally:
- clone the repo: https://github.com/peerquery/curator
- navigate to the local repo folder in Git bash or CMD,
- npm install to install dependencies
- setup your own email STMP server and enter details in .env file - or use Ethereal.email for testing
- rename sample.env to .env and configure every single blank field
- start server using: node/nondemon setup
- view Curator at http://localhost
- use any graphical Mysql DB interface such as PHPMyAdmin or Workbench to explore DB
Project links
Github repo: https://github.com/peerquery/curator
Working demo: https://steem-curator.herokuapp.com
The Curator demo
The demo's details
The details to login to the owner account for the demo can be found in the Read Me on Github. Note that on the demo, the DB populating engine is turned off and the demo runs on a pre-populated DB. This means new posts are not indexed into the DB of the demo for curation.
Lots of Steem posts are created evry minute, and if I were to leave the populating engine on, within a week the demo's DB would consume huge volumes of data.
Fresh content is not necessary for testing Curator so I pre-populated the DB and turned the populating engine off.
Also, the account used as the voting bot for the demo is my dev account, 
These and all other custom setups are only for the demo, the default code works as expected.
Conflicting ghost activities
Remember that Curator comes with only one owner account, and that is what I am giving out to test the demo. This means it is possible that multiple people with "owner" account will be logged in at the same time.
The consequences would be overlapping activities. When you do something, someone else might undo it. So if you invite a team, someone can remove it. If you approve a posts, someone else might unapproved it, ...
Bottomline: there may be more than one person active on the demo at the same time, yet they all share the same account and same capabilities, so naturally you might notice things being done for you which are were not actually done by you.
Viewing the "virtual" emails
Email STMP in demo is powered by Ethereal.email. Ethereal.email is only for demo purposes and so does not deliver the actual emails sent, instead they are all caught into its system and served on its system.
The keys to Ethereal.email account used for the demo can be seen in the Read Me on Github. Login at Ethereal.email with these keys to view all email invites sent to new team members from Curator's demo.
Recommendations
After logging in using the demo default owner account, create a new account for yourself by using the team page to invite any vanity email to join.
Visit and login to Ethereal.email using the account provided above, access the messages tap to view the invite email you sent to your vanity email.
Click the button in the email, complete the process to activate your own custom account. Now, logout of the owner account and login using your vanity email and password.
Now test Curator from your very own account!
One important request: remember that the demo actually works, it will leave whatever remarks you leave while curating as real comments under the real post. Please leave nice comments, else you would be littering the actual posts with spam comments.
Roadmap
- Rapid completion of Curator
- Implement curator on Peer Query beta(after launch)
- Add Curator to the Steem Institute for continued development and promotion of use
Final note
After App Stream, Curator is second tool we will need to power Peer Query beta - which would be a complete redesign and move away from the current tag browser interface into a full blown platform.
With Steem Institute's essentials set, I will hurry through with the development of Curator so we could launch Peer Query beta, and then 
Thanks to everyone who has supported my work this far.