🌌🤖 ↝ [STA-31] Claim anomalies & return stats

[Gizmotronn]

Create a feature on individual anomalies to claim them to a user's profile. Send a request to Flask with the following information:

1. TIC ID (of the claimed anomaly) → this will be changed to different identifiers based on what type of anomaly it is (could also be multiple identifiers per anomaly if each identifier is used in a different dataset like lightkurve and something else).

   Down the line it will be the other way around - an anomaly will be generated by a user and a TIC ID/identifier will be assigned to it, however for now we're just manually adding anomalies to the database (which will be moved across to the DeSci Nodes setup)

2. Metadata tags (as JSON) → Things like dataset, discovery info, etc.

3. User ID/Account info

Flask will then generate images and return those images, as well as other parameters, which will be passed into the planet's sandbox page -@zaq42 (with the "other parameters" e.g. orbital period being passed into the sandbox's generator). For now, only the "owner" of a planet can edit the sandbox, however users will be able to "fork" someone else's anomaly and manipulate it as they wish.

What needs to be done then? For the frontend, we need to knock in the windows for the images and other metadata to be included, and then I need to update the planets table with the following new fields:

1. Multiplier → will be set to 1 by default, can be edited/changed based on what is returned from Lightkurve. For now, we'll only have one currency → "resources", which in the MVP will be split into the different resource types described here. In the MVP, there will be a different multiplier for each resource type (JSON!). Maybe the multiplier can be set by the earthRadius field for this demo
2. Owner → reinforce the relationship between profiles table & planets table
3. Contract → Address of the planet. This is so that we can return fields to interact with a token (push/pull) on the frontend, like updating/adding metadata. 3, 4, 5 & 6 are more for when we move this data/Supabase instance to an IPFS setup on Nodes
4. TokenID → Id of the anomaly on the contract (for future discussion → where does the split between ERC1155 & ERC721 occur in the flow?
5. ChainID → What chain is the address on?
6. Owner Address → Just in case the owner address is different to the id in profiles of Owner …. for debugging purposes only atm
7. Forks → JSON. Who has forked this anomaly
8. ForkFrom → UUID. What was the original ID of this anomaly (if it was forked)
9. Posts → What shortform/discussion posts & comments was this anomaly mentioned in?
10. Articles → What long-form discussions was this anomaly mentioned in?
11. Datasets → What datasets was this anomaly part of?
12. Returned/Generated fields → JSON

Then we can add some reputation points to the user → for now it can be 1 point for every anomaly they claim/classify, as that's the flow I'm thinking will be in place at MVP.

_{From SyncLinear.com | STA-31}