With this post, I really want to try and get a feel if an old STEEM project of mine, abandoned for obvious reasons in the past, would have the support of the HIVE community if I were to pick it up again as a new HIVE project. Apart from that, but for me very much related, I want to use this post to make the HIVE development community think about the idea of a long term roadmap towards moving HIVE to become a 2nd layer codebase on top of more flexible substrate blockchain technology.
With the responses I will hopefully get on this post I hope to:
- Figure out if I should revive this project.
- Find out if there are any oversights to the general system ideas described below, and get feedback that might help me implement it.
- Maybe find other devs who could pick up a part of the system.
- Maybe find a clojure mentor (as I would very much like to combine this project with mastering Clojure)
- Hopefully get feedback on the idea of making this project a pilot for a FlureeDB based side chain that could potentially grow towards a level-1 blockchain sitting below HIVE.
- Discuss the need for alternatives for account-bound funds for a system like this.
If the answer to the first question is NO, unfortunately the answers to the rest of the questions would become less usefull, so I hope this could end up as a useful project beneficial to the HIVE ecconomy.
On me slacking off
This post won't be complete without a short note on me slacking off with respect to HIVE development ever since moving to HIVE. When I moved to HIVE, after a longish period of having gone inactive on STEEM resulting from some actions by SteemitInc, I was motivated to start doing HIVE development work again. The first thing on my list was a rewrite of my old asyncsteem library and its experimental never-past-alpha successor. I started of with fresh motivation, but then I started slacking off. The reasons for this are multiple:
- The disappearance of utopian-io. I was kind of used to being able to make some money from releases of my code and usage tutorials by posting on utopian-io. I hate to admit it, but the loss of this incentive did play a role.
- The fact that the COVID19 data sets, both data analysis end and arguing with idiots about the data, has sucked up much of my spare time.
- The lack of any pull, encouragement or input from any of the former users of my asyncsteem Python library to my plans for a new replacement asynchronous Python JSON-RPC library for HIVE and BLURT.
The combination ot these three has resulted in me not putting in the new effort into doing development for the platform I was planning to.
There have recently been some changes that are prompting me to change this reality. But probably not by rejuvenating and rewriting an old Python library that it seems nobody is really waiting for.
I need to do something with HIVE and FlureeDB
For my day job I have been working with the absolutely amazing blockchain based graph database FlureeDB that recently open sourced its ledger clojure codebase. The database has support for so called smart functions, also written in clojure.
When FlureePBC open sourced its code, I immediately though of HIVE. I had looked at the HIVE C++ codebase when HIVE was still called STEEM, and let's just say, looking at the codebase and how it was documented, as a senior dev with two decades of C++ under my belt, the code looked such that if anyone from the STEEM C++ dev team had applied for a dev function in my team, I would have strongly advised HR against the hire. So what was the though that came to me when looking at the FlureeDB open source project, given my experience with FlureeDB? My imediate thought was,
damn, I should write a HIVE-node port on top of FlureeDB. My next though was, nah, I can't possibly do that as a spare-time-only one-man development team. And really I can't. I've been known to bite off more than I can chew on open source efforts, and I'm not going to make that mistake again this time around.
So the idea slowly changed. I don't want to do an overly ambitious mega project with FlureeDB and HIVE. At least, not yet. I want to do a modest but useful project. A project that benefits the HIVE community as a whole, not just devs that aren't really waiting for what I'm writing for them. There were a few projects I was actively working on in STEEM days, and that I abandoned when SteemitInc started to become unreliable and unpredictable. Untill yesterday I really couldn't make up my mind about the FlureeDB/HIVE project I wanted to start off with. All I knew is I wanted it to be challenging yet very much bite-sized. I wanted it to make sense to use FlureeDB for. And I wanted it to be small enough so that I might maybe use it to get my feet wet with Clojure.
The onboarding gap
Then @nathanmars posted a Tweet that set me thinking. Nathan tweeted:
"*If you could only ask one person to join #HIVE Network who would you ask ?*"
His tweet made me realize just how relevant the ideas underlying my old and abandoned STEEMSENSE-EU project still really are.
Why? None of the people that I feel really should join HIVE for their amazing content would ever be interested in joining HIVE given that doing so would require a massive leap of faith. Top content providers earn add revenues on other platforms. Add revenues generated by a huge following of non-HIVE users build up over the years. A move to HIVE would make this asset, these followers, basically useless. The content provider would basically be starting from scratch, building up a new following but now of HIVE users.
Add revenues on HIVE
I think it is important, no crucial, for us to realize, however much we all know how amazing this platform is, established top content providers will never make this leap.
I would suggest that:
If we want to onboard top content providers, and do so without damaging the platform, we need to create a HIVE add revenue economy.
This idea was what STEEMSENSE was about. This idea is what I would like to revive as my first get-my-feet-whet project combining HIVE with FlureeDB.
So what is the base idea. I can sum that up quite concisely:
- Provide add-revenues as an onboarding feature to bring in top content providers
- Weave the add revenue system into the HIVE economy. Allow HIVE users to advertise using an AddSense like bidding system.
- Partial burn. The platform is a beneficiary, not the devs, not the hosters.
- Should work without a dedicated WUI, using Peakd.com,
Base setup
Consider there to be four parties involved in the proposed project:
- The content-provider with a large non-HIVE following.
- The advertiser who wants non-HIVE exposure for his/her HIVE content.
- The onboarder who vouches for the integrity of the content-provider.
- The add-platform-account.
Advertiser
Lets start by looking a the system from the point of view of the advertiser.
An advertiser who wants to use the proposed system, creates a banner adhering to size and file type conventions. Something like this:
Layout landing page:
- Landing page content
- Advertising banner
- (semi-)hidden campaign and language info
- (semi-)hidden advertiser thresholds
- (semi-)hidden onboarder thresholds
- (semi-)hidden content qualifiers
- (semi-)hidden bids.
(semi-)hidden config
Let's start with the (semi-)hidden config. As I don't want to develop any custom GUI, the project won't be using any custom_json, at least not in its first implementation. The system should be usable from front-end sites like hive.blog, peakd.com or any of the hive-engine tribe sites. To acomplish this, I propose using markdown links wighout any text in them. These will be invisable on peakd, and will be somewhat visible on hive.blog.
[](someconfig)[](someotherconfig)
campaign and language info
The first part of the config on a landing page defines the campaign and the language. Ther can be multiple landing pages for a campaign. The primary landing page should have a lang-default config.
[](HS:campaign:ragnarok-promotion)
[](HS:lang-default:en)
Secondary landing pages in alternative languages would reference the same campaign. It is important to note that secondary landing pages inherit the value of all other configs from the master landing page of the campaign.
[](HS:campaign:ragnarok-promotion)
[](HS:lang:nl)
advertiser thresholds
To fight potential abuse, the advertiser can set tresholds for the account of the content provider. The below example would specify that the content providers where the add may apear should:
- Have an account that is at least 90 days old.
- Have at least 500 HIVE powered up on their account
- Have a reputation of at least 50
[](HS:account-age:90)
[](HS:hive-power:500)
[](HS:reputation:50)
We should find and pick sane defaults for each of these.
onboarder thresholds
The above tresholds would be an undesireable feature from an onboarding perspective. For this reason the advertiser should also specify treshold values for a potential onboarder. The onboarder will vouch for the content provider he/she onboarder as described later in this post.
The below example specifies that the/a onboarder account should be:
- At least 3 years old
- Have at least 5000 HIVE powered up
- Have a reputation of at least 65
[](HS:onboard-account-age:1095)
[](HS:onboard-hive-power:5000)
[](HS:onboard-reputation:65)
As before, we should define sane defaults for these values.
content qualifiers
The next set of configs defines where the adversisor wants his adds to appear. And also important, where not.
In our example below we have my alter-ego @pibara wanting to advertise his novel on the two main HIVE sites and on the #creativecoin tribe site but not any of the other tribe sites.
The page the add can appear on should at least use the tag fiction as one of the first five tags of the page plus aditionally one of the tags sff,sf,sciencefiction and *scifi" in one of the first five tags of the page. Pages also using one of the tags erotica or horror excluded, as pages made by bananafish or with bananafish as beneficary are also excluded.
[](HS:sites:hive.blog,peakd.com,creativecoin.xyz)
[](HS:tag-oneof:fiction:5)
[](HS:tag-oneof:sff,sf,sciencefiction,fantasy:5)
[](HS:tag-blacklist:erotica,horror)
[](HS:account-blacklist:@bananafish)
bids
The final bit of hidden config are the bids.
A bid config is build up from the following sub fields:
- user list (wildcard if undefined)
- tag list (wildcard if undefined)
- bid amount per clickthrough
- coin of the bid (first version shall be HIVE only)
- The maximum number of clicks per hour
The example below combines three bids:
- A bid of 0.5 HIVE per click for pages created by one of the users @mattockfs or @pibarabot using the scifi tag.
- A bid of 0.4 HIVE per click on posts using either the sciencefiction, or the scifi tag.
- A bid of 0.3 HIVE per click on any other post matching the filters defined in the previous sub-section
[](HS:bid:::0.3:HIVE:30)
[](HS:bid::sciencefiction,scifi:0.4:HIVE:30)
[](HS:bid:@mattockfs,@pibarabot:scifi:0.5:HIVE:120)
tags
A landing page should use the following tag as very first tag to be considered a landing page:
- hivesense-campaign
adding budget
A created landing page won't be active untill a budget is added to the campaign. To add a budget to the campaign, a transfer is used to a add-system user account. During development the testing add-system user account will most likely be @pibarabot. At the end of this blog post I'll discuss the need for an alternative to such an account, but this fals outside of the scope of the project I'dd like to start working on if people feel its a good idea.
A transfer to @pibarabot (or it's production successor, hopefully an account owned by a trusted top-20 witness), should include a memo field spacifying the campaign the budget is for.
campaign:ragnarok-promotion
expanding blacklist from page
When, despite of the reputation age and HIVE power filters, abuse happens, the campaign owner can expand the existing blacklist by commenting on the content provider's content page and mentioning the add system account.
Blacklisting the page for a given campaign:
@pibarabot blacklist page ragnarok-promotion
Blacklisting the content provider for a given campaign
@pibarabot blacklist user ragnarok-promotion
Blacklisting the content provider for currwent and future campaigns
@pibarabot blacklist user
In the extreme case that an onboarder has vouched for multiple misbehaving content providers, the advertiser could blacklist the onboarder.
@pibarabot blacklist onboarder
Ending a campaign
By default a campaign will run for 30 days. The advertiser can prematurely stop the campaign by mentioning the add system account in a comment to the landing page.
@pibarabot campaign end
Content-provider
For the content-provider including an add is as simple as pasting something like the following
piece of HTML at the end of the page.
<A HREF="http://hivesense.timelord.ninja/redir">
<IMG SRC="http://hivesense.timelord.ninja/banner">
</A>
And than to add the tag hivesense-content as auxillary tag to the page for the system to pich up on.
If the content-provider has just been onboarded and doesn't have enough reputation, account age and hive power to be implicitly trusted by advertisers, the content-provider should use the hivesense-onboardme tag to notify potential onboarders that (s)he wants help getting onboarded. Note that this is meant only for newly onboarded top content providers wilt a good non-HIVE reputation and a large non-HIVE following.
Onboarder
For an onboarder, onboarding a new content provider is as simple as commenting on a hivesense-onboardme content page and mentioning the add system account as follows:
@pibarabot onboard
Budget usage
Now to the important part. Budget usage. Any unused budget at the end of a campaign will be refunded. Used budget, once a week and with a minimum 24 hour cool down window is distributed for 75% to the content-providers that facilitated the clicks. The remaining 25% is burned (send to @null).
Budget that was used, but that was generated by a now blacklisted page or user in the last 24 hours prior to being blacklisted is burned as well. This seems like the fairest option as both a pay-out and a refund could invite playing the system.
Why this project is a temp fix
While I feel the project I propose doing here might help boost the HIVE ecconomy, there is a fundamamental problem with how it can currently be implemented. Funds shouldn't be stuck in 3th party accounts, ever, in order to implement a system like this. That is what smart contracts are for. HIVE doesn't curently have a sufficiently powerfull system for this, and its not likely it will get a good one if it gets one. The best alternative there curently is is to leverage the trust that HIVE witnesses have and get one of the top witnesses to create and manage the add system account. It is however important to not that even that is a hack. We need smart contracts for building HIVE sub-systems like this.
Why V.2.0 of this project could become a pilot to HIVE as second layer protocol
If I remember correctly @blocktrades first talked about the idea of moving HIVE up to become a second layer protocol. I know this isn't the type of first layer @blocktrades was refering to, but I feel that a FlureeDB network could provide a solid layer one for a system like HIVE. Not in one step though.
In version one of the proposed project I would like to just use FlureeDB as a database. One seperate database for each of the add system nodes.
A next logical step would be interconnecting the FlureeDB nodes in a consensus set-up. I'm not a system admin, but I understood this should be possible. If we get the add system to work with a distributed FlureeDB side-chain, this side-chain could become the home of more side-chain projects.
The third step, if we have multiple projects running on the smae side-chain would be to try and define a migration path. Move more and more HIVE features migrate to the side-chain till the used part of the HIVE blockchain has become lean and mean.
The 4th and last step would be the hardest one. Turn the side-chain into the level-one chain and move HIVE itself on top.
Let me be clear, I'm in no way sure the abouve roadmap is realistic, but if we don't make the first two steps, we shall never find out. I believe the foundation that FlureeDB could offer as a substrate for a clean and lean layer-2 HIVE blockchain I believe offers massive promise.
The support for powerfull smart functions that can be used to construct the type of smart contracts needed to implement a system-account-free addvertising system is just one of the features this move might eventually enable.
Developer and/or witness feedback?
If you made it this far into my post: Thank you for sticking in there, I know it has been a long read. As said, I'm not sure yet if I should implement this system, if the community wants me to, I will. If it doesn't, I've learned from my python lib experiences, so I won't be maing anything people arent waiting for. Personaly I think onboarding top content providers could provide a huge boost to the HIVE ecconomy. I also feel the posibility of a FlureeDB side-chain deserves exploration. So please everybody, let me know what you think. Should I pick up this project and create a version 1.0? Are there any oversights that would make this system exploitable? Are there any other devs who would like to work on this project with me? Anyone who is experienced in Clojure who would like to mentor me on using this project to further master that language?
Feedback on my idea to explore a FlureeDB based side chain that could potentially grow towards a level-1 blockchain sitting below HIVE is also very much welcome. And if anyone has ideas that could help or avoid or attenuate some of the drawbacks of using an add-system system account that manages funds, I'm all ears.