CLI Feature: Launch FCL development wallet

[srinjoyc]

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

Currently, when developing Flow applications locally, the FCL dev wallet must be started as a separate Docker container on the user's machine.

While having a Dockerized version of the dev wallet may be useful without the emulator for specific scenarios, such as a testnet demonstration app, the overwhelming majority of the time, users will want to use the two tools together for local development.

Local development on Flow is complex. This effort seeks to remove the burden of startup and configuration of the dev wallet, removing one more source of configuration errors in local development.

This effort proposes bundling the dev wallet server as part of the emulator, and starting the wallet service alongside the emulator when working locally, removing the necessity for users to configure and run the dev wallet docker container manually.

Experience Required

• Familiarity with Go
• Familiarity with the Flow CLI
  Familiarity with the Flow Emulator
• Familiarity with bundling a JS client-server application into a discreet runnable program.
• Familiarity with WASM as a packaging format (bonus, not required)

Minimum Feature Set (Acceptance Criteria)

• Dev wallet is configured and runs on emulator startup
• CLI flag for starting the emulator without the wallet
• CLI displays FCL configuration information stdout (code snippet indicating how to connect FCL to the dev wallet service)
• Debugging output for dev wallet service (preferably as a tail or logs command similar to Heroku eg flow dev-wallet logs --tail)

Milestone Requirements

1. Create a mockup demonstrating the UI/UX for this feature
2. Add FCL dev wallet code to the emulator
3. Run dev wallet in a separate (or, supervised?) process on emulator startup
4. Users can work with the dev wallet without using Docker

Software Requirements

Maintainability

• The tools or libraries used to construct the solution should be well vetted and well maintained
• Code should be written in a way where it's easily extensible to new functionality and semantic enough for open-source developers to contribute to.

Testing

• All core logic should have unit tests.
• Follow testing guidelines on the respective repositories you need to modify.

Other Requirements

Error Reporting

• The dev wallet should report an error when it cannot connect to the emulator.
  • Prints a clear error message to the browser console
  • Displays what is expected (connection string for the emulator ...etc)

Documentation

• The following pieces of documentation needs to be completed alongside the code for a successful submission:
  • A quick walkthrough guide for this feature with screenshot examples.
  • Add usage to the existing CLI Docs

Code standards or guidelines

• Follow the general contribution guidelines located here.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.
• The UI should be easy to understand for newcomers to Flow development.
• Extra points for functionality related to accounts not explicitly mentioned in this outline.

Resources

• General Resource Guide
• FCL Dev Wallet
  • Repository
• Emulator
  • Repository
  • Documentation
  • Original Reference Issue
• CLI
  • Repository
  • Documentation

[10thfloor]

Hello there.
Mackenzie here. 🏄🏼‍♂️ I'm part of the Developer Experience team at Flow. Glad you're checking out this issue.
I can help answer any questions you might have about what you see here, and if you decide to take this on, I'll be your primary point of contact for you or your team.

Please add your comments/questions here, or find me on the Flow Discord (mack)

Happy hacking!
🚀

[10thfloor]

Another note about this issue. We could also expand the scope of this issue to include starting the dev-wallet as a feature/service within the desktop GUI proposed here.

[bluesign]

I think this would be a great task if it was to convert dev-wallet into a client-side-only app.

• It would be a tier 3 task. (I think it is pretty easy)
• all API / signing sides can be managed from the front-end too.
• people could just embed dev-wallet easily in dapps ( even conditional builds like: when in not "production mode" )
• when static JS client app, you can bundle and serve from flow-cli (without any tricks needed)

I don't see any immediate blockers, but of course, I may be missing something.

[10thfloor]

Yes, we could include that as a viable submission as well.

[bluesign]

@10thfloor I made a PoC at http://flow.tymianek.com/demo/

All FCL Wallet features are just static html and js.
( currently requires refresh after first connect, and after actions of adding deleting accounts etc)

Setting up in app with:

window.fcl.config()
  .put("accessNode.api", "http://localhost:8080")
  .put("challenge.handshake", "http://flow.tymianek.com/fcl/authn.html") 

Requires local emulator with :

address: 0xf8d6e0586b0a20c7
keyId: 0
privateKey: 84f82df6790f07b281adb5bbc848bd6298a2de67f94bdfac7a400d5a1b893de5
accessNode: http://localhost:8080

I am thinking to add some cookie/localStorage for settings, and then host on some public URL.

[10thfloor]

Sweet.
Now let's add to the emulator, and serve it up on another port when the emulator is started?

[bluesign]

Yeah I need to make it a bit more maintainable, maybe some webpack rules etc. But should be easy. This is just a PoC actually I made in an hour.

BTW is there a specific reason for another port? We can also bind to 8080 also probably with some path ( /wallet etc )

[10thfloor]

Fair enough. A new port will help distinguish that it is a separate service, and not part of the 'emulator api', but certainly not required otherwise.

[bluesign]

A new port will help distinguish that it is a separate service, and not part of the 'emulator api'

This is good point, different port would be better for sure

[bluesign]

Team: https://www.hackerearth.com/challenges/hackathon/flip-fest/dashboard/3744a70/team/
@bluesign (Tackling solo)
plan time: 2021-10-17

I will try to make this configurable, also optionally with possibility to use flow.json accounts.

[psiemens]

@bluesign Nice! Moving this to approved :)

[bluesign]

I will move on to testing and documentation parts if all good, but not sure about how to unit test this part.

[kimcodeashian]

Good day @bluesign!

Thanks so much for all your hardwork & participation. In order to finalize winners & prepare for prize payout, we'll need the following actions from your end.

Please provide the following information by Nov 17, 2021, (in this GH Issue is fine):

1. Team Information

• Team Members Information - Github Username + Email Contact + Percentage of prize allocation (total should = 100%)
• All mentioned members MUST react to the post with a 👍 which will act as confirmation that the information is correct, or a 👎 to indicate that the information is not correct.
• We will be reaching out via e-mail

🎖IMPORTANT: We will only proceed with prize payouts once all members have confirmed with 👍 on the post.

2. Video Demo (optional)

• Please provide a 5-minute video demo to be featured & showcased in the FLIP Fest Closing Ceremonies
• Link format & Downloadable (eg. Google Drive, Vimeo)
• Content Format (Problem Statement, your work / how you solved it, final outcome)

We will be hosting Closing Ceremonies on November 23rd, 8AM PT where we'll having closing remarks from Dete & will be announcing the winners! I'll share the details here before Nov 17.

[bluesign]

@bluesign deniz@edincik.com 100%

[kimcodeashian]

Hey folks,

We've received and reviewed over 82 submissions! What an amazing community on Flow! To commemorate all the hard work done, we have finalized winners and will be announcing them during our Closing Ceremony on Nov 23rd, 8AM PT. Be sure to join us - there may be some attendance prizes & a keynote from our CTO, Dete 😉!

RSVP here so you don't miss out! See you then!