Support for post subspaces and topics

RiccardoM commented 5 years ago

Context

Ideally, what we want to achieve with Desmos is to enable any developer to create a messaging-based application that is completely decentralized and censorship resistant.

To do this, we need to find a way to distinguish the messages of an application from the ones of other applications built on Desmos.

Subspace implementation proposal

To solve this problem, we can implement the concept of subspace and topic.

A subspace will identify all the messages coming from the same application. For example, all messages coming from BigDipper will have subspace = "bigdipper".

A topic, on the other hand, allows applications to arbitrarily decide the topic of a specific post. For example, inside the bigdipper namespace we might want to have proposal-discussion, private-message and other topics that let the clients easily fetch the messages related to a specific discussion subject.

Storage implementation

The post object should be changed adding two new fields:

type Post struct {
    PostID     PostID         `json:"id"`
    ParentID   PostID         `json:"parent_id"`
    Message    string         `json:"message"`
    Created    int64          `json:"created"`
    LastEdited int64          `json:"last_edited"`
    Owner      sdk.AccAddress `json:"owner"`

    Subspace   string         `json:"subspace"`
    Topic      string         `json:"topic"`
}

The following data should also be stored:

The associated list of post IDs that are part of a specific subspace.
The list of topics associated to a specific subspace
The list of post IDs that are part of a specific topic.

In this way we will be able to fetch in constant time the following data:

The list of messages for a given subspace
The list of topics for a given subspace
The list of messages for a given topic
The subspace of a post
The topic of a post

kwunyeung commented 4 years ago

I think having subspace is not enough. We need to know the corresponding address of the user on the network.

I'm thinking a use case that Dwitter can select different networks and post messages on Desmos as the corresponding identity on that network. For example, if the user select cosmos-hub-3, it's posting messages as a cosmos1-prefix address which can then be indexed by different explorers to show the messages. The subspace here should be referencing the chain-id. We can adapt this with the UCR. And the address need be to generated when the key was restored as the HD path of different networks are not the same (DESMOS is 852, ATOM is 118, IOV is 234, etc.) and we can't simply determine them via the bech32 conversion. The longer term solution is to integrate with IOV but this should be treated as an alternative as we have to cater users without a Starname.

So the message itself should not be storing subspace = "bigdipper". It should be a structure with

{
  chain_id: 'cosmos-hub-3'
  address: 'cosmos1uurhagec2qzyfhlq7reryqjscxzq68p4gfywgp'
}

RiccardoM commented 4 years ago

@kwunyeung I think that due to your request being very application specific, it might suite better the new proposal I've just added: https://github.com/desmos-labs/desmos/issues/52

RiccardoM commented 4 years ago

I'm thinking about revisiting the structure of this implementation, deleting the topic in favor of the implementation of arbitrary data as specified by #52. The Post structure would then be defined as:

type Post struct {
    PostID     PostID         `json:"id"`
    ParentID   PostID         `json:"parent_id"`
    Message    string         `json:"message"`
    Created    int64          `json:"created"`
    LastEdited int64          `json:"last_edited"`
    Owner      sdk.AccAddress `json:"owner"`

    Subspace   string         `json:"subspace"`

    // Arbitrary data as specified by #52
}

I'm also thinking about making the subspace field obligatory so that it cannot be left empty. This would require applications to identify when posting a message, which can lead to an overall more organized chain storage.

desmos-labs / desmos