feat: Support storing Component Fork data in SocialDB via Component Metadata

[charleslavon]

Context

Out of all of the MVP Notification types to be supported, Component Forks are the only event type which is not currently written on-chain.

We need to create a pattern of writing component fork events on-chain and integrate this with the near.org UI and tools like bos-cli-rs, such that when a user forks a component and submits the transaction to write the forked component, a payload is included which writes the forked data on-chain.

This can be accomplished by

1. updating each client which initiates the fork to include the following component metadata

{"fork_of": "original/component/path@blockheightAtOriginalComponentLastPublished"}
2. Creating an indexer that parses component metadata and persists a schema that supports

• Showing a count of the number of forks a component has on its component detail page
• Showing links to forked instances of a component on its component detail page
• Sending a notification to the author of the forked component that includes a link to the forked instance and a timestamp of when the fork occurred.

@pkudinov's team can help leverage an existing QueryAPI indexer to support #2
Related Data Platform Issue

[mpeterdev]

clarifying: the blockheight in the path should be the latest blockheight at which the source component was published (i.e. the version) as opposed to the blockheight at time of fork, correct?

[charleslavon]

That's correct @mpeterdev thanks for chiming in. I've updated the description with a very long name to help make that clear.

[pkudinov]

I propose to store {"fork_of": "original/component/path@blockheightAtOriginalComponentLastPublished"} to not mess up the existing tags for components

[charleslavon]

@milenakrawczyk consider this task for next week's sprint.

[mpeterdev]

Would it make sense for forking (and writing the correct metadata) to be a smart contract operation so that all tools can call the same logic instead of implementing it themselves?

[milenakrawczyk]

@mpeterdev it is an interesting idea. However, I am not sure if it would be easier/more useful than to simply write the metadata with the correct path. The smart contract would need to get the source path as an argument. It might fetch the block height of the path and that would be possibly beneficial. The downside would be that there are two distinct operations instead of one: writing the component + writing the metadata with the source path. The tools would need to implement the logic to know whether a component is a fork or not.

[mpeterdev]

I was suggesting more of a GitHub workflow where the first step is the fork action which takes a component path as an argument and makes a copy of it as-is in your SocialDB widgets space with the appropriate metadata, then you can start editing and saving modifications to the src.

This would also lead to some really interesting analytics where you could index SocialDB fork events since they exist on the blockchain as that.

This could be considered as an improvement down the line if it's overengineering at the moment

[milenakrawczyk]

@mpeterdev I see, this sounds very useful. As far as I understand it could be achieved without a smart contract - it suffices to modify the Fork button so that it saves the data before loading the sandbox. The Fork button could be reused by other gateways as well.
This solution won't work for the bos-cli-rs as when downloading the components, it is not known what account widgets would be deployed to later on. I am wondering whether to implement the fork command in bos-cli-rs instead of modifying the download and deploy commands CC @frol.

[frol]

I agree with @milenakrawczyk, modifying "Fork button" to remember the fork metadata and save it when users publish the component makes more sense to me.

[milenakrawczyk]

Regarding the bos-cli-rs implementation there are two ways that this could be implemented:

• a fork command that would work the same as download but would add a forkOf field to the metadata
• modifying the deploy command to check the source of widgets and adding forkOf when necessary (a PR).

@frol what do you think about these solutions? Forking in general does not go well with bos-cli-rs and this is my main concern.