Hi all. Big shout-out to the second.tech team for the great work on Ark. I put together a MacOS prototype wallet app because I wanted to feel out how some of the sensitive UX bits around boarding. It’s been really interesting to dig in and I wanted to share it here in case others find it useful.
Here’s a demo video:
Also happy to share the code if that’s of interest.
Integrating bark was very straightforward, although I am sure I am still missing various nuances. Some questions and thoughts that came up:
Are fees simply not implemented at all yet? I somehow expected that there’d be a call to provide transaction info and get a fee estimate back. But maybe that’s not how it works?
Is there a way to retrieve the mnemonic via the CLI?
Or switch between different mnemonics to manage multiple wallets?
When loading the balance, does bark automatically refresh VTXOs if needed? Or did I get the wrong impression? If so, isn’t there a cost involved that users should be aware of ahead of time?
What’s the logic around refreshing expired VTXOs? Can they be refreshed just like active ones? Or is there a difference in the process or cost or so?
Is it correct that offboarding happens on a VTXO basis and the user cannot choose an exact amount of sats?
That’s it for now. I am hoping that this experimentation can help the project in some small way, and that I can gather some best practices for the Bitcoin Design Guide.
Thanks again for all the hard work on this project.
Hey, this is amazing, thank you for sharing it. The app looks very macOS-native and I like the way you handle VTXO management, the savings vs payments terminology and the X-Ray page is really cool.
I can answer some of your questions and I’m sure my colleagues will also chime in.
In terms of Ark/lightning fees they have yet to be implemented as we’re still finalizing our fee policy. For onchain payments we don’t expose the fee rates or estimates in the API but I will create some issues on Codeberg as I suspect developers will appreciate such a feature.
No the mnemonic isn’t exposed but in the current API you can find it in ~/.bark/mnemonic
One way to implement this in a wallet would be to use the --datadir flag to control where Bark stores/reads the database and mnemonic files.
In the currently released version I believe it does but in the next version I believe we’ve changed this behaviour, instead users can run bark maintain to refresh expiring VTXOs.
This one I’ll leave for my colleagues to answer.
Yes that is how the current implementation works but you could use the bark send-onchain to send an exact amount without selecting which VTXOs are used. Both require round participation but they serve different purposes.
For fees, I will just add placeholder text in the UI. That way the UI can be roughly figured out now, and get implemented more realistically over time.
Thank you. I figured out how to display it in the settings page now. If the user wants to set up a new wallet with an existing mnemonic, would I also just manually write that file and then bark picks it up? Or is there another process? I did not see any options for “bark create”. Similarly, if I want to delete the wallet, do I just delete those files?
Are the two purposes you mention sending to someone else vs moving funds between your own Ark and on-chain balances?
And a new question. Are there maybe multiple ASPs running for testing cross-ASP transactions?
bark --datadir ~/.bark2 create would create a second wallet. Then every time you use bark just add the --datadir flag before any command.
bark offboard is meant for taking the entire VTXO and moving it onchain, by default to the users onchain wallet but you can specify a different destination address. bark send-onchain is meant for sending a specific amount (can be more than the value of one of your VTXOs) to an onchain address of your choice.
We currently only have a signet ARK server so there isn’t an easy way to test this case other than spinning up your own ARK server and trying to connect a lightning node to ours.
Hello again with another update. I spent the last few days with the basic integration of tags and contacts and better address handling all around, as well as some of the basic lightning functionality. A lot of the application logic has changed, to the detriment of the UI execution (the horror). But there’s a solid foundation now to build on, which I am happy about. And I think you should be able to tell where things are heading, hopefully that’s a good direction for now. Here’s the video overview:
It’s also on the latest beta now. Gotta say, bark is very convenient to work with. Great work there, everyone.
After these larger changes, I want to dig into specific screens and interactions now and polish and tweak. I also have some funds stuck in a perpetual boarding state and seen lightning payments fail, so I’d like to inspect these issues as well.
Any feedback is highly appreciated. And thank you for the shout-out on the platform formerly known as Twitter yesterday.
Sorry for forgetting to respond about the error you were asking about. We’re investigating it and have been making big changes to rounds so it might not be an issue any longer.
In terms of your update it’s looking fantastic, the tag system is really cool!
Thanks for the update. All good, I’m sure you’re all super busy.
Here’s another update with the latest refinements:
What’s in there:
Import native contacts
Auto-assignment of contacts, addresses and transactions
New console view for dev’ing
Receive screen layout update
Tags screen layout update
Bunch more minor layout things
None of those changes are super specific to Ark or Bark, but should be nice “quality of life” improvements.
The contacts stuff is important to me, as I worked on a page for that functionality for the Bitcoin Design Guide some time back (Contacts | Bitcoin Design), but I really haven’t seen it implemented all the way in any wallet. So I am essentially also trying to validate some of the work I did on that page.
I think I’ll next focus on ensuring all the different address formats are handled properly throughout the whole experience (including BIP-353). But let me know if there’s anything else you think deserves some attention.
