This is a great question. The real trick is going to be in structuring the data so as to minimize the number of per-user queries. I can think of a few ways that can work:
-
Have a “curator” user maintain the list of usernames with each topic. You could structure a forum topic to include the list of usernames of users who have posted at least one comment. In addition, you would store the timestamps at which they posted. This would let you efficiently determine which users’ posts to fetch based on what page of the topic the client is on. To build the topic-to-name-list mapping, you would want to design the app to inform one or more “curator” users whenever you create or post to a topic, so they can build it up for you (more on that in a moment). Then, the read path looks like:
- Load up and render the forum topics from your chosen curators
- When the user clicks on a topic, load up the list of users and timestamps who posted
- When loading the first page, load up the forum posts from the other users in order by timestamp, cutting off at the page boundary.
- When the user clicks the ‘next’ button, load up the next batch of forum posts, and so on.
-
Build an indexer over the set of forum users. You can determine whether or not a Blockstack ID owner created an account on an app by inspecting its profile. Since you can already enumerate all Blockstack IDs, you can asynchronously crawl their profiles and find out who posted which forum post, and when. The forum post body can be encrypted, but presumably the application would store at least a timestamp so the forum posts can be stitched back together as a page (and then decrypted client-side). The indexer would be able to assemble and cache pages server-side, cutting down on the HTTP requests that clients must make. It otherwise serves the (signed and optionally encrypted) forum posts unmodified. The client could be written such that whenever a user stores a topic or forum post, it also sends the indexer a hint that new data exists and should be crawled (so it will show up before the indexer makes another pass). Note that since the data and names are already out there, anyone can run an indexer—the indexer is not part of the trusted computing base, and cannot lock you in.
-
Use an existing application to bootstrap forum post discovery. Users of Graphite, Stealthy.im, Postly, and others already maintain user-to-user links in order to share data. A forum could bootstrap topic discovery from this. Similarly, the client could bootstrap discovery off of the Gaia inbox protocol we’re developing, and could bootstrap off of our decentralized social network initiative.
I think the first option is probably the best option for a forum specifically, since forums are read-mostly and usually don’t need real-time message delivery. Regarding curators, what you could do is have a “bot” user account that you hook up to a server that your forum client contacts to inform it whenever you post a new topic or reply. The curator bot assembles the list of usernames and timestamps for the forum topics, and serves them back to other clients. This architecture would be great for creating a scalable multi-topic forum system like Reddit on Blockstack, since each “sub-forum” could be managed by its own set of curator bots (i.e. running on behalf of the “sub-form admins”) and could implement its own “sub-forum”-specific moderation rules simply by being diligent about adding/removing topics and posts. Users always own their own data, and users always own their own forum posts, and admins retain the ability to fight spam and abuse.