What's the intended data/storage consumption design for a social Polkadot Product?

Hey there,

After playing around for two days and exploring different designs of how to store my data for a Product, I am still unsure about the right design choices.

As an example, let’s say I try to create a bulletin board in the style of 4chan, where posts are ephemeral and disappear after some amount of time.

This is my best line of thinking so far:

  • Since posts can disappear, I can store the content on the bulletin chain
  • To retrieve the content from within the app, I see these options
    1. I can index the whole bulletin chain from within the app to filter for the content that is app-related
    2. I can store CID pointers in smart contracts
    3. I could break out of the host to ask an off-chain indexer

(1) is feasible rn on devnet, but will likely not be in the long-term.
(2) is what I see as the most practical approach rn, but it requires additional requests to approve (among the numerous requests that already have to be approved already)
(3) is feasible, but I think not what we want to have.

Within the design space of storing a CID as a head pointer in a smart contract, I was exploring how to have less transactions/approvals to sign. One option I see is to create a proxy account in the local kvStore that gets delegated limited permissions and sent a few tokens to send messages to the bulletin board on behalf of the user.


I wonder what the design choices are that you see to store and retrieve data for a social app like this while minimizing interruptions that diminish the user experience.

1 Like