Changing the way PostIDs are created

[RiccardoM]

Context

Currently when creating a new Post, it's ID field is generated sequentially by taking the last id and adding 1 to it.

While this surely works, it is just a very naive way of generating ids in a very determininistic way that might have some downsides as newer ids can be inferred.

A part from this, a serie of checks must be put in place in order to maintain the ordering of such ids, as I've also outlined inside #90.

Solution

In order to properly change this, I propose a new way of deterministically generating post IDs that cannot be infered and also will allow for some performance improvements:

sha-256(post_creation_date + post_creator + post_subspace) 

This way we could also remove the current way of checking if a post collides with another one which is currently causing a lot of performance probles as we iterate over all the posts.

Using this ID system, instead, we could simply check if such key already exists inside the store and if it does, it means the post is duplicated.

The implementation could be done directly inside the NewPost method, generating the ID there instead of outside of it.

Notes

When implementing this, a migration should also be implemented to transform 0.3.0 post ids into the new type by performing the appropriate convertion.

[leobragaz]

I'm starting today afternoon with this