⛓🪁 ↝ February Product Flow · Discussion #1 · Signal-K

Discussion

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 / Discord
  • 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))