height[bot]
commented
3 months ago Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword
link(e.g. "Link T-123").💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.
Seems to have mostly been a unity + webgl branch, #28 #50 #48
Create a feature on individual anomalies to claim them to a user's profile. Send a request to Flask with the following information:
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)
Metadata tags (as JSON) → Things like dataset, discovery info, etc.
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:
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
Owner → reinforce the relationship between profiles table & planets table
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
TokenID → Id of the anomaly on the contract (for future discussion → where does the split between ERC1155 & ERC721 occur in the flow?
ChainID → What chain is the address on?
Owner Address → Just in case the owner address is different to the id in profiles of Owner …. for debugging purposes only atm
Forks → JSON. Who has forked this anomaly
ForkFrom → UUID. What was the original ID of this anomaly (if it was forked)
Posts → What shortform/discussion posts & comments was this anomaly mentioned in?
Articles → What long-form discussions was this anomaly mentioned in?
Datasets → What datasets was this anomaly part of?
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.
Huly®: STAR_-81