⛓🪁 ↝ February Product Flow

[Gizmotronn]

February Flow - Planets

Notion Page

This discussion is mapping out the infrastructure planning, talking points & questions/updated for the Planet & Metadata infrastructure (DeSci-md/automating-metadata#1).

Referencing: Signal-K/sytizen#16, Signal-K/sytizen#18, Signal-K/Silfur#31, Signal-K/client#19

As of the 11th of February, we have the following fragmented components in the client ecosystem:

• Generator & ‘traditional/real’ Earth map (three.js)
• Lens Protocol Feed, Profile interaction handler & post creation handler
  • Ability to add and return/retrieve custom metadata packets from IPFS for each publication
  • Will be used in the DeSci-backed “Gateway” clone
• Off-chain profiles
• Off-chain post & social graph
  • Different post types, e.g. proposal, documentation, sandbox,
• Staking setup
  • For planets, ships…any item really
  • This could be considered an inventory, we’d just need to update the staking contract to include multiple collections (those collections should be able to be added in the same way NFTs are added to a lazy mint contract)
• Initial Jupyter setup with Flask container & Lightkurve interactions
  • Function to save an image file (.fits format) from a graph generated by a Lightcurve
  • Flask & Postgres helper using psycopg2 → Can interact with the Supabase client
  • Next step → get the .fits file to be uploaded as an image to a user’s profile when they request graphs from a certain tic id
    • A request should be passed from Next to Flask to state which user is calling a new TIC id to be generated

Currently the Lens Protocol is using Chakra UI, while the social graph is using tailwindcss (included custom/plain CSS files). I want to update the Lens Feed to use the <Card /> component defined in the social-graph ./styles dir. Today, I re-integrated the Lens Feed View & graphql headers into the social graph in wb3-12-add-... on .signal-k/sytizen. Hopefully we can use one basic set of CSS rules long-term, each fragment/section (aka component sort of? referring to large sets of components here really) might be initially designed using something like Chakra or Tailwind but long-term we need to migrate it to one standard to keep the package.json as small as possible - might be something else for DAVID to look at.

Still to be added:

• Planet/item (e.g. ship/tool) view
  • I’d recommend taking a look at the traders branch on signal-k/sytizen (and the immediately derived branch[es]) for some initial UI work on what I imagine a draft UI for this would look like
  • Jacinta & Nathan were briefly working on a frontend mockup for this (Nathan has been moved over to the profile section, while Jacinta is working on the brand identity right now…)
  • MVP stage & beyond (potentially immediately before if we add the on-chain interaction before commencing on the full integration procedure, which I think is a smarter option - what are your thoughts @david?) we’ll be having very minimal web3 interactivity for a few reasons (explained below). Basic interactivity will be included - each action will be saved into an array in the relevant foreign key in profiles table, and this can then be added into a ‘dump’ transaction on a breadboard module on-top of Lens publication. For example, if a user ‘mints’ a planet, they’ll just be getting a planet sent to their inventory (the mint button will be interact with a lazy mint, but data will be sent to postgres for the NFT ID and match that with the session?.user?.id tag, so that NFT id is belonging to the user in the off-chain instance but to a default (e.g. u/parselay.lens or u/g1zmotronn.lens) eth wallet on Goerli/Mumbai/Polygon. That planet can then be interacted with off-chain - e.g. adding a building. This offchain interaction [’transaction’] is then stored in Supa, and can be then added to an offchain post on the social graph. All relevant (for a single anomaly/object) social graph posts will then be sent to a single Lens publication that tags those arrays but is published by the default eth bucket/address (pre-MVP)
• Player interactions
• Guilds
  • Chat - Supabase
  • Blueprints → build this into a standalone game item
    • Side note → deeds/[co-]ownership of items, interactions between users and guilds, items
  • Data/ERD structure → will be finalised next week (before the Wednesday DeSci meeting 00:00 GMT)
    • Members
  • Central planet → inherit from Player Interactions & Planet View
    • Will include a spacestation → which includes spaceships & players. Elevator to planets (grown out from station so the station can be migrated/moved)
• Global inventory → ensure that this is formatted equivalent to what would be compatible on an EVM environment
• Lightcurve calling (essentially what ‘anomaly calling’ will be once we have more than just Lightkurve for planet anomalies and more than just one type of anomalies/research point (planets))

Re-integration of on-chain interactivity will occur once the basic UI for the gameplay has been initialised. Currently there is debate internally about whether we use the generated graphql hooks or just the default Lens contract ABI (from @lens-protocol node.js package). We also need to map out the full smart contract & ERD infrastructure later in March DAVID.

[Gizmotronn]

Hey team -> got some discussion around the data types & how we'll be presenting them across the client repository/ecosystem.

Discussion about how data should be presented to the web client from the backend (for this "citizen science" discussion webapp):

https://elianna.notion.site/Dataset-structure-Discussion-42d23cf1ced447138c6ffef1c01df286

Based on my current understanding and very limited scope so far, I'm storing things in a database just as fields.
E.g. stats/fields relating to exoplanet data (say, from the TESS telescope which provides the Lightkurve dataset/module) would include temperature, radius, etc. So there would be a table on the database for planets which is where any dataset relating to "planets" would store its data, and each datapoint would then be tagged by which collection it was part of (e.g. "Exoplanet 42" may have been added by "Survey 21" but is also included in "Survey 27" and everything is in the one table on the db)

Most of the discussion/examples refer to planets simply because that's what we've built up so far

There's a few limitations to this:

1. Some datapoints (say from different collections) may have extra fields (e.g. Survey 31 may have a field for aphelion but every other survey doesn't...so how do we structure for missing fields?
2. What happens if a user wants to add a dataset but adds new fields that are already existing -> e.g. Survey 109 adds a new radius field?
3. What happens if an entry gets duplicated? We could set up a way for people to edit fields, but then how do we moderate that?

Ultimately, I think we can build out the initial system with these limitations for now as it will only be us who's using & building on the platform, which means we can assume that there won't be any malicious intent, and there won't be so much data that it becomes impossible to fix mistakes. Once we have a better understanding of how we'll migrate this over to Nodes we'll hopefully get closer to solving this issues/limitations. I think the way the data will be stored will mostly remain the same -> either datasets in the form of tables, or preferably modules like Lightkurve that can then be imported (maybe we could look for a tool that could automate this process -> storing the data directly on IPFS anyway). Long-term we only will have user data & unpublished content existing on the relational off-chain DB so I think we'll be fine with this model. However, some research on the frontend & API structure will need to be put in as well to ensure that regardless of what model/dataset is being used, anything can be queried by the API and the UX/UI design remains consistent regardless of how many fields or what fields are being displayed

In short, data should be presented in tabular format if possible -> Field Name, Field Content. For every collection/dataset/article we work with, we should write a standard for what each table should consist of so that I can set that up on the backend.

One day soon I hope to provide a direct link to this comment - for now, if you spin up client on localhost:3000, it will be located at https://localhost:3000/journal/Article?id=2

[Gizmotronn]

Signal-K/client#23 Signal-K/client#24 Signal-K/client#25

[Gizmotronn]

I've been working on the action items over the last few days and I've come up with the next steps:
https://www.notion.so/skinetics/February-March-Flow-Planets-8c864b66147c447f82136772336e9bc6?pvs=4#89417cdc9aa4428c8ed4790516392863

Here's the gameplay info (comments and code snippets are available on above Notion link)

Gameplay

Entry point & early user flow

Claim their first anomaly

Explore it (datasets)

• Generator should be moved to “sandbox”

Image generated should be moved here as well

Write an article about it

Tag anomaly id

This should then show up in “article refs”

Once an article has been written (which is basically mimicking the classification process), allow users an opportunity to mint a token, and then display the specific staking action (currently the <StakePlay /> component is in the sandbox tab)

Return the id of the new token, add that to the supabase anomaly row.

Note that as described in tag pages here when online, anomalies are all created as 1155s (lazy minted), and then once classified that 1155 is “burnt” and turned into a 721

Update the user’s reputation, thus allowing them to mint (claim) another anomaly