---
# System prepended metadata

title: 'Blacksmiths v3 Working Session #1'
tags: [' working session', ' notes', v3]

---

---
tags: v3, working session, notes
---

# Blacksmiths v3 Working Session #1

- Agenda: https://hackmd.io/OwQa8aH_R7mBVjc4IDz6cg
- Goals:
    - Identify items to turn into specific tasks

## Initial Tasks

- What do we need to do to begin turning UX specs into stories and specific stories for folks to work on?
- How can we split teams and identify who works on which areas?

## Initial v3 Scope (Reference v3 Scope Doc)

- What are we initially building?
    - **POC of Summoning App with features**:
        - Hard mode summoning app
        - v1 of subgraph, DH Baal contract, Baal summoner contract
        - Rage versions of component library and SDK/utilities
        - Design: UI Design & UX Specs
    - **Simple Hub application**:
        - List of DAOs user is in
        - (Design will need to take a pass at this)
        - Dig into our data SDK to explore and support fetching for 2 main scenarios:
            - 1) Scoped to a user
            - 2) Scoped to a DAO
    - **Core DAO UI**:
        - As we move along we can dig deeper into this

### Summon & Hub Design Review

- Review the summon designs
- Review data inputs/outputs
- Identify micro/macro components to put into the component library
    - Repeat this process as we go
- 

## What can we start with?

### Ops

- Build out GH Actions and deployment targets (Keating)
    - Libraries to `npm` and frontend to Skynet
    - Domain set up for Skynet deploys: `alpha.summon.daohaus.club`
    - GH Actions/Deployment Pipelines:
        - Component library
        - Subgraph deployment
        - Serverless deployment
- Monorepo setup
    - Point to internal filepaths and alias
    - Packages:
        - Subgraph
            - Research local Graph deployment
            - Local Graph node for development
        - UI/Component library
        - Baal Contract (down the line)
            - How can we simplify the Baal repo and make it more straightforward for folks?
            - Can we release Baal as a `npm` package similar to OpenZeppelin?
            - Research how to maintain connection to initial Moloch Mystics repo will require research 
            - Do we want all of this in our Rage repos?
- Local development docs
    - Do a session to make sure folks are on the same page
    - Set up the `env`
    - README for each package at a basic level
    - How to get started with the Monorepo?
- Anything going into Rage repo should be willing to deprecate
    - Anything built for prod should live in regular monorepo
- Figure out QA 
- Common linter/prettier configurations
    - Ensure everyone is aligned and using these
    - Do a session to ensure that everyone is able to run things locally
    - Sync folks usage (can also sync up with `.vscode` setups)
- Component Library notes:
    - (add these back, was talking so need to revisit notes!)

### General Thoughts on Haus Libraries

- Give alpha version of AriaKit a test in addition to ReachUI and RadixUI
    - Andy having issues with AriaKit alpha -- may be too early, but going to pair with Keating to check this out
- What do we want to call these?
- How will we handle cards that have a lot of unknowns -- how do we communicate this w/o it slowing progress?

## Activities and Questions

- How do we want to transition Rage apps to Sage apps?
    - What does this look like? 
    - How/when do we transition? Are there different teams?
        - Rage (alpha) -> beta -> release (v1)
- Milestone -> step back and identify what needs to happen while transitioning?
    - Tests, documentation, share learnings, etc.
- What other app boilerplate stories can we write?
    - What routes are needed for an app?
    - What pages are needed?
    - Navigation
    - Basic layout
    - Can create an `nx generator` that is DAOhaus specific when we identify common layouts
- How can we identify and leverage common patterns and pull these into our libraries?

## How to Split Teams?

- May be awkward at first -- this'll evolve over time
    - Patient early on, but worth exploring at an initial grouping
- **Contract/Subgraph**
    - Sam
    - dekan
    - Keating
- **Summon App Rage**
    - Jord
    - Andy (overlaps with component library)
    - Output:
        - Playing with initial version of component library
        - Data SDK / utils -- pull out utils as they're being used
            - Will SDK include interacting with s3, subgraph, contract? Any third party data service? Does this include tx legos?
                - How do we want to update the tx legos?
                - Read/transform
                - Does this also come with a set of utils?
                    - Encode/action/working with ABIs
- **Component Library**
    - Andy (starting on the micro elements of component library)
    - Jord (starting on the macro elements)
    - Planning to meet in the middle as their work converges
- **Hub Rage App**
    - Component library (basic components) - Andy
    - More data library work - Keating/Sam?
- **Data**
    - Sam
    - Keating
    - Jord
- Conducting group review as we build this out to identify patterns

## Baal Summon UI Review (Rage)

-  (Figma walkthrough with comments)
-  Potential confusion on ERC20 name/symbol and how it shows in the app (name of token vs. display name in app)
-  UI around Rage Quit:
    -  List of tokens, which do you want to Rage Quit?
        -  Proportion of RQ so not all or nothing
        -  How do we want to handle ignoring spam tokens?
- Data pulled in form:
    - Native currency (likely hardcoded)
    - Leverages user submitted data earlier in the form -- local state
- Shamans:
    - Hide if we publicaly release -- not having available during Summoning
- Tables (macro component) that unifies this
    - Need non RegEx way to handle this
    - Build table UI easily, but also handling and crunching the data into format needed by Baal contract
        - (Not for Rage) but being able to handle CSV value inputs that'll split and generate the table UI
- Visit the docs? -> Loom video of someone summoning?
    - What should this be, especially since it's mostly DH folks using this?
    - Integration with Poster with the HackMD having an embedded video (IPFS link?)
        - Look into service for video hosting
- (Down the road) Poster for Docs
    - Poster should be immutable but docs change often, so this may not be the best usecase
    - Can these pull in existing content and render it?
- Components:
    - Inputs that we're styling (and multiple states)
        - Input, Textarea, Select, Checkbox, Radio, Tooltip
        - Can also optionally include functionality for integration with forms (this has pro/cons)
        - Input, focused, demonstrations for different states for Radio and other components
    - Buttons
        - Button states
        - Primary, secondary (text button)
    - Title and Text
        - Separation of semantic and presentational
    - Accordion 
    - Dropdown/multi-select
    - Table
    - Global Connect Button with multiple states
- Are we using Quiver to handle wallet state?
    - Used in the Yeeter for wallet connection and for one of the transactions
    - Quiver can be used in the Summon Rage App
- Do we have a list of all the input states for validation?
    - Validation on blur, change, submit, helper text, etc.

## Hub App Design (Rage)

- Worthwhile exploring early on for the component and data fetching practices
- Can have same stories as building out Rage apps
- Are we doing a shareable nav?
    - Can take in a nav object and populate items
- Naming components:
    - Thinking about how we want to name macros with the designers to create a shared design language
    - Will theming be included in v3?
        - Light and dark mode, but not sure beyond this
        - Limit to a set amount of things that can change and then we can support a theme object (down the road)
    - MetaUI may have custom theming
    - Could this be moved to a boost?
    - Do we enable user created themes?
        - Identify design tokens to leave the door open for this
- Should our data library hit a lambda that provides what is needed when it's hit? OR should it work on a schedule where it hits services directly
    - Centralizing around our own endpoint may be necessary but we should aim to stay away from this where possible
- Design will need to take a pass at the data being used in this since it'll be difficult to grab
    - When we get to doing this, these conversations will be helpful and inform the data fetching structure
    - Start by trying to hit the services and then reach toward lambdas if/when this becomes an issue
- Do we want to do a click and reveal style UX so we don't grab all this data at once
    - How would we sort it?
- Security -> UX -> Decentralization
    - Decentralizing our state is critical
    - If our getters/setters are semi-centralized at first this could be helpful in other areas
        - Look at use case -> can we use decentralized tech? if so, use it, if not, use a lambda that anyone can read the data from

## Outputs

- Create a backlog with these items
- Begin identifying priorities and owners

## Next Steps

- [ ] Outline initial tasks to get folks working more intentionally on v3
- [ ] Create initial cards from our outline and notes
- [ ] Identify teams (Rage and Sage, for example)
- [ ] Identify general data models (starting on Hub) and data fetching
- [ ] Design Ops Processes (Storybook, Component Library, Figma)
    - [ ] Define design -> developer handoff processes
    - [ ] Identify our core design tokens that will be composed

## Reference

- [v2 data catalog](https://hackmd.io/o7cVYOO4SxiZ03afDDufqA)
- [redux wrapper of an sdk](https://github.com/superfluid-finance/protocol-monorepo/tree/dev/packages/sdk-redux)
