I've begun writing tests in Hardhat, and I'm second-guessing some of my design choices.

I feel most of the design work is done, and I'm reaching out to my good friend Carlos, a brilliant Ethereum security engineer to see how he would approach the design.

Here's what I'm sharing:

Stonewall is a decentralized text-based posting platform.
Data is permanant and undeditable.

This looks like reddit/twitter/etc, basically:
Topics (AMERICA)
Posts (Historical record- first-hand account of an event)
Comments (May have comments themselves, no limit to depth)

posts and comments are ordered beneath their parent by value-
authors and readers send value to posts and comments they like.
the order may change over time as readers donate or new posts/comments are created.

New topics like 'America' are created when users create them by posting about them.
Posts are stored as keccak hashes:
    keccak256(abi.encode("AMERICA")) -> 0xd2f...b0a6

Topics may have any number of posts
Posts may have any number of comments
Comments may have any number of sub-comments, of infinite/arbitrary depth

additionally, topics and posts each have their own 'relevance list'
the relevance list offers readers similar topics/posts
the relevance list is also user-generated and ranked by user-donated value

the MVP allows users to:
-create posts (which create a new topic, if it doesn't exist)
-create comments
-send value to posts and comments they like (maybe triggering the data to re-order)
-add topics to the relevance list for a topic/post
-see the ranked posts and comments beneath a topic
-see the relevance list of similar topics/posts

Challenges:
-storing comments of arbitrary nested depth
-re-ordering posts/comments efficiently
-ensuring content is stored statically, such that links never break
-ensuring content doesn't collide in storage
-designing a simple system to link topic/posts to relevance lists

my solutions to the challenges feel naive; to ensure unique data storage slot generation, I've decided store the structure of posts/comments in a uint256 2d array on each parent element- each parent has its own defined depth and has a list of children which determine width.

for value-based ordering, keep an ordered list of pointers in the parent element. re-ordering efficiently... a basic insertion algo will work, but it feels sloppy to not consider gas limits. It could be possible to allow users to determine where they'd like the data to be indexed, then simply calculate an appropriate cost and ensure there's no problem. Finally, the static linking would enable each parent to store a similarly-ordered list.

Let's see what Carlos comes up with!

peer review