Support for discussions

[kwunyeung]

This will be very useful for proposal discussions on Cosmos Hub

[RiccardoM]

Context

Currently the Post object contains a reference to its parent inside the field called ParentID. While this might be sufficient, it fails to provide a sufficient way of implementing discussions.

Browsing online, the most well-known platform that allows to implement discussions on any website is probably Disqus.

This service allows any user to implement a comment-and-answer based system inside any HTML page. The aim of this implementation proposal is to allow anyone to create a new Post that provides the same functionality.

Discussion support implementation proposal

The support for discussions that I've thought is based on a revisit of the Post type:

type Post struct {
    PostID         PostID         `json:"id"`
    ParentID       PostID         `json:"parent_id"` // Id of the post of which this post is an answer of
    Message        string         `json:"message"`
    Created        int64          `json:"created"`     
    LastEdited     int64          `json:"last_edited"`
    Owner          sdk.AccAddress `json:"owner"`
    AllowsComments bool           `json:"allows_comments"` // Tells whether the user can comment or not on this post
    Comments       []PostID       `json:"comments"`        // Ids of the comments that are answers to this post
}

Changes

• Added the AllowsComments field allowing the creator of a generic post to decide whether or not to permit other users to add comments to its post
• Added the Comments slice telling immediately which post ids represents comments to the post

New operations

No new operation should be implemented. The creation of discussion posts can be done through the creation of simple posts.

State management

There must be a change into how the state is managed, particularly on what happens when a new post is created.

Currently, when a post is created, the only operation that is done is saving it inside the state. Now, with the addition of the AllowsComments and Comments fields, the following operations must be done before saving a new post object:

1. Check that the parent post accepts comments.
   If the ParentID post is a valid post id, we must check that the post having the specified ParentID id accepts comments. If not, an error must be returned and the post must not be saved.

2. Update the Comments field of the parent post.
   If the parent post accepts comments, before saving the comment into the state, when must retrieve the parent post object, and update the Comments array appending the new comment's PostID object. This will ensure that later reads will return the correct value of associated comments for the parent post object.

[kwunyeung]

Can we build an iterator to find out all the child Post but not adding a Comments slice?

[RiccardoM]

Can we build an iterator to find out all the child Post but not adding a Comments slice?

Actually, what we can do is remove the proposed Comments slice and store the comments related to a post inside the store as an entry which has:

• Key equals to the post id
• Value equals to a slice of post ids (that reference the comments)

I would avoid using only an iterator as it might bring the complexity of retrieving all the comments hierarchy up to as we would have to iterate thought all the posts list each time we want to get the comments of a single post.

By storing the comments of a single post inside a slice associate to the post id, we can instead achieve a lower complexity if I'm not wrong.

[kwunyeung]

You are right. This is always a trade-off for using key-value pair database. I see the same issue on MongoDB as well. It's not like how we can retrieve data in RDBMS. Keep the Comments if it will have better performance.