Extend the concept of subspaces

[RiccardoM]

Context

Since Desmos is thought to be a protocol on top of which to create a lot of different social apps, in order to distinguish on which app users are creating posts we introduced the notion of subspaces. A subspace is currently represented by a SHA-256 hex-encoded string and identifies the app on which posts should be visualized or inside which a user has blocked another user. This value is then used inside posts, via the Subspace field.

This naive implementation, however, allows any user to post on any subspace, creating the space for potential spam attacks. Image the following scenario:

• A developer creates a new dApp that posts on Desmos
• Someone gets the dApp subspace value from the blockchain explorer, and starts spamming the app
• Since the dApp has no idea how to distinguish between allowed users and spammers, it will display all the messages

Introducing permissioned and permissionless subspaces

In order to remove the possibility of external spam attacks, what we could do is extend the notion of subspace. What I'm envisioning is not a simple SHA-256 string, but a new entity that can even allow or disallow users from posting there.

I think that a subspace should be like a social network on its own:

• it's created by someone
• the creator can allow either some people (i.e. the registered users), or everyone, to create posts there

For this reason, what I suggest is to create a new x/subspaces module inside which we allow the following operations:

Operation	Who can do this on-chain
Create a new subspace	Anyone
Add a new subspace admin	Subspace creator
Allow user to post messages inside such subspace	Subspace creator or admin
Block users to post messages inside such subspace	Subspace creator or admin

By doing this we would allow currently centralized social networks to transition to Desmos more easily than before by having their own permissioned subspace. Thanks to this concept, they would be able to move all their messages on-chain and have a custom tokenomic while preserving the ability to control the users actions by blocking eventual spam or other negative behaviors.

At the same time, since not all dApps might want that strict control, we should also allow subspace creators to specify that their subspace is completely permissionless, meaning that there are no admins and everyone is allowed to post inside there without any control (like it is right now).

I would like to know your opinions on this @kwunyeung @bragaz

[leobragaz]

Like you said, this is actually a good way to build a bridge with which old centralized social networks can start their transition to a more decentralised infrastructure.
I would also add a feature to remove an admin in case his actions become unreasonable and don't match the creator's intent.
What do you guys think about some expiration date for the above operations (excluding the subspace creation)?
For example:

• Block bob to post on this subspace for 3 days.
• Revoke admin after 1 march etc.

[kwunyeung]

I think having a moderate-able subspace is important. However, how far should we go? Should we build this as a smart contract standard instead of a module? Each CosmWASM smart contract should have its own state. That may replace subspace and it could further represent the relationship between a dapp and the smart contract.

[RiccardoM]

As far as I know, this is not even possible. Smart contracts are something that can be written by users and are coded using WASM. We cannot reference a smart contract (which might not even be written) when creating a post. For this reason, we would not be able to create posts inside their specific subspace.

Instead, what we can do is:

1. Enable subspace creators to define a list of admins to that subspace (as @bragaz proposed here)
2. Allow only those admins to perform some operations inside the subspace.

This could allow the admins to write specific smart contracts that can be run only by them, and execute custom operations inside those subspaces as well. Some examples could be:

• mint tokens that are related to that subspace
• block users from acting inside the subspace
• ... and all sort of custom logics that can be implemented in WASM

I think smart contracts should be used to extend the workings of already existing module, instead of replacing them. We create a set or rules that smart contract creators cannot break by defining a x/subspaces module, and then we allow them doing whatever they want using smart contracts.