spent the day considering stonewall's architecture in bukit bintang's 🔥 breakfast spot. I've started building basic examples and tests in solidity in a hardhat project with js and have a bit more clarity.

the data structure of stonewall looks like reddit/twitter/etc:

topics
posts
comments (recursive)

a 'topic' at the top level has a list of any number of posts, which has a list of any number of comments, which themselves may have a list of any number of comments, and so on. All lists are ordered by descending value, and must be re-ordered when the value changes.

for example:

>politician name (topic)
    politician did bad thing!
        >and here's more proof...
        >no they didn't
            >ur an idiot
            >idiot dummy
    politician has fake hair?
        >lol watch this vid...
        >finally some real reporting...
        >yeah obv

a few technical bits of stonewall:

users' posts and comments must be stored in an array of arbitrary length, probably searchable in both directions, so a double linked list seems appropriate
users' posts and comments must be re-organized upon receiving value
comments may be nested arbitrarily deeply
the text length of users' posts and comments submissions are limited by the EVM, but it is possible to allow authors to append more data

posts and comments must be referenceable using unique static IDs both for the EVM and external sharing of content. For example, a link might look like:

https://stonewall.com/post/
https://stonewall.com/comment/

in future planning, topics/posts will be upgraded to support some type of community-powered binding to improve discoverability

Data Structure

Each topic 'already exists' and is discoverable as a hash of an upper-cased human-searchable string (e.g., "HARVARD UNIVERSITY"=0x4841525641524420554e4956455253495459). At this storage slot, there may or may not be a Post (aka an instance of the 'PostComment' struct- posts and comments are about the same)

it's important to know how many top-level posts are here...
Mapping Topic (b32) -> numPosts (used to generate unique PostComment ID for Topics)

PostComments always exist in a double-linked list of posts ordered by value.

Struct PostComment is stored at the hash of (topic(numPosts) for posts, parent(numComments) for comments)

{
author
createdAt
numPages (number of continued pages, else 0)
nextPage (location of next page, else null)
prevPost (location of adjacent higher-value post, otherwise null)
nextPost (location of adjacent lower-value post, otherwise null)
numComments (used to generate unique storage for children)
valueSum
}

PostComments are stored in a double-linked list of PostComments allowing for unlimited size and easy modification due to value change (find new location, update old neighbors' prevPost/nextPost, update own + new neighbors prevPost/nextPost)
Unique permanent storage slot identified by a static ID generated via keccak of parent + index
Allows authors to append additional data, but not delete/modify

dev thoughts for later
///hashing with keccak... encode vs encodepacked, keccak recursive depth limit
///ordering by value optimization... keep another array of ordered values->ids per parent?

This design will need to be modified as I learn more.

In the meantime, I've had some other thoughts about the project as a whole... loving the idea of a simple monospace retro design, can't wait to throw together a demo. in the end, the device to target is the phone, and most battery burn comes from the screen, so white on black minimalism also rocks for performance. Not sure about the final user experience- the most simple user experience I can think of for now is hitting a dex contract with your message and quoting+converting any erc-20 token on the fly.

One little thing that irks me about so many social media sites like X is the fact that comments are hidden, requiring that you click on them. why?? just show the full chain

A devious way to launch this would be to start posting shit about random topics, then get others to piggy-back the headlines. If anyone reads this retroactively, know I'm not dumb enough to actually do this.

Next, I'll either formally define the set of functions or look into the limitations of nested mapping via recursive hashing... it'd be a shame to only get like 12 layers of comment depth.

designing the skeleton