StoryPress: 4 design mistakes

I've been working on StoryPress for a while now and took some opinionated design choices right from the start. After a few months, I am now looking back on these choices.

In case you want to develop, or think of developing a decentralised application, this article might be of interest for you.

1. Focusing too much on gas costs

Victim of outrageous Ethereum gas cost Post Traumatic Syndrom, I worked very hard on the StoryPress smart contract to make it as gas efficient as possible. This work led to more complicated code, and more complicated user experience.

The worst good idea was probably the CHRF token (this cherry internal balance of the cherries that you own inside the StoryPress smart contract.) This was all done in order to lower the costs of cherry token transfers, but led to complicated details that are not easily grasped by new users.

This also forced me to develop fill() and withdraw() functions to transfer your cherries in and out of the StoryPress smart contract. This also forced me to keep track of the balance of each of the users inside the StoryPress smart contract.

All in all, gas cost were often lower, but the overall experience is a pain.

2. StoryPress smart contract is a monolith

This was a dire consequence of this CHRF and internal StoryPress smart contract user balance. I tried to figure out a was to put the different functionalities of StoryPress.info inside independent smart contracts, but with that initial design choice, this was not possible.

That was another mistake. A much better design would be to have 3 separate contracts:

1. one to handle story publication
2. one to handle comments
3. one to handle reactions (likes)

3. Forcing the use of Cherries

I am absolutely sure that using a special token (here Cherries) to publish, comment, react, prevents bots, spam, ... and give fair and transparent rewards to authors is a good idea. This is the whole point of StoryPress: a publishing platform that fairly rewards authors, and has almost no spam.

Why not directly pay in FTM? Because nobody can make any prediction on the price of FTM in the long term. If it goes to the moon, then the publishing platform will just get too expansive to participate to.

That's why I need this intermediate token, whose target peg is currently at 1 FTM, but it can be lowered in case FTM goes to the moon.

Why not using a stablecoin then? Because nobody knows which stablecoin will still be operating by the end of 2023. It's not even sure that stablecoins other than CBDC will still be legal in a few months and I surely don't want to endorse CBDCs if they are the only legal stablecoins left around. Stablecoins are too uncertain.

But to participate in StoryPress, you need to buy Cherries on SpookySwap, AND allow them to be spent by the StoryPress smart contract. This is easy for those of us who are used to DEXes, but newcomers to the web3 space will start with a too complicated experience.

That is precisely why I tried to make the onboarding experience easier, but this is not enough. When I wrote the cherry dealer smart contract, I realise what I should have done:

Publishing stories, making comments and reacting should first be done by paying one or a few cherries for those who want to, but users should be able to shunt this cherry step if they want to, and directly pay in FTM (that will get automatically converted to cherries via a behind the scene oracle call).

1. write your story
2. click the write story to IPFS button
3. click the save to Fantom button by directly paying with your FTM. No need to buy cherries first if you don't want to care.

That would be a much simpler user experience.

4. Forgetting about NFTs

That's the last and biggest mistake. I considered it when I started writing the StoryPress smart contract, but I first did not really like the idea of rogue authors buying and selling stories. Second, I must admit that I just did not know how to write NFTs and adapting them to the rest of StoryPress's logic was, back then, above my level of Solidity junior.

But when I look back, it is now obvious to me that each of your story should be an NFT. Each author should be able to sell or buy stories from others. StoryPress should not only be a place where you can easily publish your stories, but it also should be a story marketplace.

Conclusion

I am very proud of StoryPress.info: anybody can publish stories easily for less than 10 cents. The decentralised structure of StoryPress is made so that anybody can integrate their stories in their website: just query the Fantom blockchain and grab the story content from IPFS, then render it on your website.

StoryPress.info is a front-end of that application that runs on Fantom and IPFS, but anyone else can build another competing front-end. Unlike many other publishing platforms, I don't want to host your content (that's why it's on IPFS), nor own your content (that's why it is not in my private database, but on Fantom's public permissionless blockchain).

But after almost a year working hard on it, I do acknowledge that some major design flaws prevent easy user onboarding, and neglecting the whole NFT ecosystem was a terrible mistake.

Please, don't hesitate to add a comment if you have other critics. If you see other design flaws, or missing features. I'll read with real attention all your feedback.

The show must go on

I'll now work on a new version of StoryPress. Back to Solidity coding for me. Then the whole User Interface (that is, StoryPress.info) will have to be adapted. Then I'll have to migrate the data from the current monolithic StoryPress smart contract, to the future 3 dedicated StoryPress smart contracts.

That way, I'll turn the 75 stories I've written on StoryPress into 75 story NFTs. ;-)

Stay tuned, a lot is coming ...