Some thoughts on potential improvements of the STEEM/steemit platform.

At the moment of writing this blog post, I'm listening to mpswaves, hosted by @aggroed, where a group of top witnesses including @someguy123, @elear, @carlgnash and @drakos share their thoughts on the future of steem/steemit and on the main priorities they see in problems that need solving and issues that need addressing.

While many of the obvious issues come up, it is interesting to find that how these guys think about the platform from their position as the witness is quite distinct from the way I personally, as a mere minnow, fiction author, security geek and software developer think about the issues currently facing the platform.

It could be some of the issues I'm seeing are just the result of my personal bubble that I'm living in just as everyone is living in a bit of a bubble, or it could be these issues are real and important issues that the guys running the show (witnesses and core devs) are simply not seeing.

In this post I want to discuss five of the seven issues I currently see with the platform, hoping that maybe, just maybe my post might catch the eye of one or more of the witnesses or core devs and they might get discussed. I won't discuss the other two, because these two were discussed on the show so there is zero need to bring them to anyone's attention.

The five subject I would like to bring to people's (especially witnesses and core-devs) attention are the following:

1. Ads economy and bringing in top content creators.
2. Security vulnerability rewards.
3. Least authority, authentication vs authorization.
4. Services economy and cooperative content creation.
5. Distributed frontend

An ads economy and bringing in top content creators.

Arguably the value of the STEEM blockchain for a huge part is determined by the value of the content. More high-quality content, To get more top-quality content, the platform needs to attract top-content creators. The problem though is that top content creators are likely to get quite decent adds revenues from their current blogging platform. Steemit may hold the promise of future revenues, but for access to these revenues, these top bloggers, vloggers, and other top content providers will have to build a whole new audience from the ground up. Now let's be fair: steem/steemit is a great platform, but I'm sure even the most die-hard fan of the platform will understand a top content provider has zero incentive to simply throw away add revenues by moving his blog/vlog to steemit. It just isn't going to happen.

What is desperately needed in the STEEM ecosystem is an ads economy. To build such an economy a shift is needed in the way we think about non-account-holder visits. To understand, lets look at it from the other side. I recently released my novel Ragnarok Conspiracy on multiple e-book outlets. While it is doing quite nicely on Smashwords and Google Play, I still have zero sales on Amazon. So what do I do, I run an ad campaign. It doen't matter where I run the campaign on, what is important that I'm paying about $0.40 per click right now for this campaign and that money isn't flowing into the STEEM economy. There is no real alternatives for adds on steemit currently. Sure I could make a post and use the promotion function, but how many clicks would that buy me. I could pay vote bots to upvote my post so I'll end up in the trending content, but again, apart from the obvious issues with bypassing the curation system with vote bots, it isn't going to reach my intended audience in an in any way relevant way.

What is needed is an ad economy. A way for someone like me to run an ad campaign and an opportunity for top content providers to leverage their existing non-steemit following.

Security vulnerability rewards.

A while back, while reading through the docs and trying to get a grasp of the inner workings of the JSON-RPC STEEM API for my worth on the asyncsteem JSON-RPC python library for STEEM, I ran into a double voting vulnerability that I reported. I wasn't looking for it, but as I'm always security minded I stumbled upon it and reported it with a link to a blog post describing the problem. The result: the devs came up with mana and the problem got addressed in HF20. Great, a problem gets reported and gets promptly fixed. But there is an issue. The problem is the economic incentive for reporting issues. For me as a mere minnow, there was little incentive not to report the problem. I only have about 1200 SP to my name in total, so for me exploiting the double voting vulnerability instead of reporting it was never something that came to mind. But how about the next time? I made a few cents from my blog post on the subject, mostly from my own vote. I did get contacted though by someone showing interest in my security analysis skillset and my skills as a developer. The person in question was careful not to be too explicit, so I'm not disclosing any info to anyone here, but there was an interest communicated with respect to early access to information if I was to stumble upon something in the future, as was the prospect of a well-payed development job. My interpretation was that this person was carefully implying (s)he would pay me and pay me well to write vulnerability exploiting code if I ever were to find another vulnerability like that again. As said, I'm not 100% sure of the malicious intent of the person who contacted me, it might just be me being paranoid and connecting dots that aren't really connected, but as a general rule, I think its safe to say that in general, vulnerabilities are worth money to potential wrongdoers. The higher the value of the STEEM platform, the higher the value of undisclosed vulnerabilities will become. It's just a matter of security analysts and unscrupulous stakeholders to find each other and economic incentives will do the rest.

What is needed to evade this doom scenario is for alternate incentives to be put into place. A reward system for finding and reporting exploitable vulnerabilities. Make the incentive high enough, and not only will vulnerabilities people run in by chance get reported rather than sold to bad guys, people with the right skills will actually end up investing serious amounts of time into doing thorough security reviews of the system. Let me be clear, I'm not asking for any reward for the mentioned vulnerability, it's about future rewards. It's about the security of the platform needing the right incentives for people who find vulnerabilities. It is about creating incentives for people to go look for vulnerabilities proactively.

Least authority, authentication vs authorization

As a capability-based security guy, authorization systems are kind of my thing. I'm mostly using capability paradigms from a system integrity perspective, but the whole concept of capability-based security has taught the security community quite a few things. I could spend a whole series of twenty blogs ranting about the failures of identity-based authorization, but I will try to be short and concise here. For those interested in a somewhat deeper discussion, please visit my old OHM2013 Defeating Trojans slides on SlideShare.

What it all boils down to is that authority should be decomposable, that it should be possible to attenuate authority before delegation and that delegated authority should be revocable. You should never ever need to delegate your identity, and authentication and authorization should be strictly separate concepts.

I know I'm not going to be making friends by saying this, but the existence and implementation of steemconnect and the way it is used today show the dire need for a more capability-based approach to attenuated and revocable. The recent ByteBall airdrop shows just how steemconnect can be the wrong tool for the job in horiffic ways. In order to claim free GBYTEs, steemit users needed to authenticate themselves as steemit users. Proof their identity on steem. There actually is a pretty easy way to do authentication in steem by doing a 0.001 STEEM or 0.001 SBD micro transaction using the memo, but the bot opted to use an authorization service instead. To use the authorization service steemconnect, the user needs to delegate what boils down to a token representing his identity. Be it a revocable identity token, but still. Then the service allows the user a course granularity attenuated delegation without any user controll about (auto) revocation.

Ideally steemconnect should not be needed, the authentication system and authorization system should be fully decoupled and the authorization system should follow and allow for capability-based usage patterns. No third party service should ever be delegated the authority to authenticate, your identity should be yours and yours alone. Your authority, even though flowing from your identity, should be decomposable. Decomposed authority should be atenuatable and revocable, either explicitly by you, or using auto-revocation patterns that can be either time or usage triggered. There are many dangers to using unatenuated authority and to delegating identity. When working with a system such as the STEEM ecosystem, least authority interaction should be a prime concern.

An idea of the type of thing that would be possible using a capability-based approach to authority:

I'm a big fan of what @r0nd0n is doing with his @freezepeach initiative. I could delagate some SP to @freezepeach, but @freezepeach only votes when flag abuse is reported. This means my delegated SP would go to waste most of the time. Now if I could just delegate my authority to vote, and I could wrap this ability is a little capability interaction pattern, I could allow @freezepeach to vote in my name up to twice a day at up to 60% of my full voting strength.

There is decomposition from my full authority to just my ability to vote. There is attenuation from 100% of voting strength down to only 60% and there are capability interaction patterns for revocation, revoking the authority each day after it has been used twice, unrevoking it at day start.

The capability way of thinking about authority creates a place of least authority thinking. A place where small amounths of measured authority can easily be shared without much concern. A place both safe and flexible.

Services economy and cooperative content creation.

As we know, its all about valuable content. Outside of the internet, it is quite normal for good content to be produced by multiple people working together, each contributing their own skill. I myself am a skilled software engineer and an amateur indie author. I used to make mean pencil drawings when I was younger, but I stopped and I'm not even half as good now as I used to be at making artwork or illustrations. So if I want to create great fiction content, there should be two roads available to me basically:

• Purchase editing and cover art services
• Work with editor and artist on cooperative content

Let's explore the first. There are many software development projects going on on steem. I have decades of experience in software development, system design, software architectures, quality assurance, security assessment, etc. Enough to make valuable contributions to software projects at a fee. I'dd love to earn money doing software development or code security reviews and use that money to purchase services from for example an editor and an illustrator. The STEEM blockchain has the potential, or rather, had the potential to host a rich and content-oriented active services ecconomy. The idea of a pegged SBD was a perfect fit. Unfortunately, though, SBD turned out not to be as pegged as many, including me, thought it was, and we just come out from a set of massive pumps that laster half a year, destroying any credibility SBD had as a basis for a services economy.

I think it should take top priority to fix SBD in such a way that, while maybe not hard pegged to a single value, the value of the coin is fixed enough to allow for confidence in SBD to be restored enough for a services economy to blossom.

There is another edge to working with different skill sets on content and that is the approach of a time-only investment of all people involved. If the STEEM blockchain could provide the facilities to for example semi-publish content with conditional benefactors set, maybe even allowing for bids on the benefactor section, then the platform could truly get used for high-quality cooperative content creation. Let me scetch a scenario.

• I write a short story and semi-publish it, it is rough unedited but it is a great story, I realize it needs a lot of work editing, and I really need a decent icon illustration for my post. I set a benefactor bid call for up to 40% for an editor and up to 25% for an icon with a deadline of 24 hours.
• Editor one bids 40%.
• Editor two bids 35% and gets the bid.
• Illustrator one bids 20% and gets the bid.
• Editor two edits the work and semi-publishes it.
• I sign off on his work.
• Illustrator one adds an icon.
• I reject the icon and ask for improvements.
• Illustrator one updates the icon
• I sign off on it.
• The story gets fully posted now, edited and with the good icon.
• After 7 days, we all get our shares from the proceedings according to the bids.

I know this is all a bit of a blue skies scenario, but looking at the technology needed to pull it off, most of it is already there. I believe there is huge potential if the platform was augmented to accommodate cooperative content creation. The bids system might be a bridge too far, but there is many ways to make a good enough system that would make cooperative content creation much more natural without creating the need to go off-chain to cooperate.

Distributed frontend

This one would be a huge challenge. One that only a brilliant mind could solve. I think the capability-based approach could provide some of the building blocks, as would the good old CDUCK it's me* approach to DNS, but there are important pieces of the puzzle missing that should require a stroke of brilliance to find and fit in.

With a blockchain based distributed backend, the main availability bottleneck for steem is the web front end. ideally, the web front end should be as distributed and resilient as the backend network.

Fixing this isn't just a STEEM problem, it is a vexing problem other blockchain based systems with a web frontend face as well. The inferiorly distributed frontend, conceptually, is the weakest link in the availability chain.

We need great minds to come to a solution to this problem. The biggest problem is that of implied trust. There are few people with a solid grasp of all aspects required. Blockchain technology, DNS, least authority, and cryptography. Zooko could possibly solve this riddle or the guys from Agoric but its a hard problem in need of careful consideration. Screw it up and you create a vulnerability the size of France. Do it correctly though, and you will have created the most robust web ecosystem humans can hope to build.

Conclusions

I hope that after this rather longwinded post some of you are still there. If you are, agree at least one of these issues is important, and you are in any position to get a witness or core-dev to look at it and consider discussing it with the other core players, that would be amazing.