Blockchain immutable - modifying blocks

[redigaffi]

Hello, this is not related to cryptocurrency, it's more about Blockchain.

This is the scenario: Social network built on top of blockchain.

Imagine that a users publish a post. And later he noticed a wrong part in his message and want to edit that part, but since it's already in the Blockchain and it's immutable, how would you proceed in this scenario. I have a way to go, but not sure if it's the best:

Block1:
- id: 1
- type: "post"
- Message: "Hello world"


Block2:
- id: 2
- parent_id: 1
- type: "post"
- Message: "Hello world v2"

So in the users profile would be displayed block1, so the first message unless another block with parent_id pointing to the old block is pointing, then I would use the last "version" of the block.

The idea would be like creating different "versions" of a same block.

Would that be a good fit for this problem?

[1714863798]

1714863798

[1714863798]

1714863798

[1714863798]

1714863798

[bob123]

Would that be a good fit for this problem?

Since you are working on an immutable data structure the only way of accomplishing such an 'update' would be to reference to the old block/tx/message.
You approach should just work fine. That would have been my first approach too.

You just have to keep in mind that you still need verification (only poster of the first message can 'update' this message).

But note that the displaying of those messages (especially the updated messages) is done client-side.
It is definetely possible to see all old messages. The client has to be set up correctly and needs to have the blockchain synced and verified to display all messages/posts correctly.

Lets pretend the following:
Alice does post some text at block X.
Alice does edit this post at block X+10.

If Bob opens his clients and syncs, the moment he reaches block X, he will see the first post by Alice.
This will be the only message bob will see until he has synced up to block X+10.


Short answer: Yes, i think so.

[innovator256]

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

[redigaffi]

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

Could you elaborate your answer a little bit more please?

Would that be a good fit for this problem?

Since you are working on an immutable data structure the only way of accomplishing such an 'update' would be to reference to the old block/tx/message.
You approach should just work fine. That would have been my first approach too.

You just have to keep in mind that you still need verification (only poster of the first message can 'update' this message).

But note that the displaying of those messages (especially the updated messages) is done client-side.
It is definetely possible to see all old messages. The client has to be set up correctly and needs to have the blockchain synced and verified to display all messages/posts correctly.

Lets pretend the following:
Alice does post some text at block X.
Alice does edit this post at block X+10.

If Bob opens his clients and syncs, the moment he reaches block X, he will see the first post by Alice.
This will be the only message bob will see until he has synced up to block X+10.


Short answer: Yes, i think so.

Thanks for the answers, so the idea would have a web platform that will be always keep on sync with the blockchain, so this problem would be solved, since the user has no client and he doesn't needs to update it.

[bob123]

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

Could you elaborate your answer a little bit more please?

I can't follow this statement either..

Thanks for the answers, so the idea would have a web platform that will be always keep on sync with the blockchain, so this problem would be solved, since the user has no client and he doesn't needs to update it.

This would work.
But if this web platform is only running on your server (without being open source), then what is the reason to use a blockchain?
You would create a centralised platform utilizing an inefficient data structure.

If you want to build a centralised platform, use another form of storage. A simple databse would be way more efficient.
If you want to build a decentralised platform, other people need the ability to connect to your network (without relying on your server/web application).

[redigaffi]

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

Could you elaborate your answer a little bit more please?

I can't follow this statement either..

Thanks for the answers, so the idea would have a web platform that will be always keep on sync with the blockchain, so this problem would be solved, since the user has no client and he doesn't needs to update it.

This would work.
But if this web platform is only running on your server (without being open source), then what is the reason to use a blockchain?
You would create a centralised platform utilizing an inefficient data structure.

If you want to build a centralised platform, use another form of storage. A simple databse would be way more efficient.
If you want to build a decentralised platform, other people need the ability to connect to your network (without relying on your server/web application).

Well no, because for example, CryptoKitties is on Blockchain, but the application is running on a private server. So the idea is to have the web application using the Blockchain and having the Blockchain with full access open to the world with an api so everybody who want can build stuff and mess around, so i don't think that's correct, because CryptoKitties is using the same approach, right?

[redigaffi]

you would be creating a problem rather than a solution in the long run. Such data could be stored on ipfs anchored to the actual chain

Could you elaborate your answer a little bit more please?

I can't follow this statement either..

Surely he means such idea/project better done with InterPlanetary File System where node don't need to store each data. On high-level, it's similar with Torrent file distribution.

Would that be a good fit for this problem?

Not bad idea, but IMO it would be better if :
* the type of the changes is "updated_post" or "edited_post", not "post". It's even shorter if we use type_id instead to lower the size.
* Only input the info/post changes to lower the size. Similar with Git commit where git only save the different part to save storage space and make commit process faster.

Good idea, surely that would save a lot of space/memory in the long run, but that would add an extra layer of complexity.