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.
Neil, I am so appreciative that you approach things that way. This week I realized that Bark supports BOLT-12 offers and Lightning Addresses out of the box and was super impressed. I had avoided looking into those so far because I assumed it would be a massive headache to support. Huge win there.
So here’s the latest update, which is all about sending:
I expected it to be a big task to create really rich send experience, and it really is a lot with all the different payment formats we have, as well as handling multiple layers.
Goal here was to create a super simple send experience, no matter what payment information is thrown at the Send view:
Entry points
Contact
Clipboard, scan or URI click
Manual entry
Address formats:
Ark
BOLT-11 Lightning invoice
BOLT-12 Lightning offer
Bitcoin
Lightning address
Address pointers to resolve
BIP-(3)21 URI
BIP-353 human-readable address (points to a BIP-21)
Other logic
Detect known addresses
Check for network (mis)match (mainnet, testnet, signet, regtest)
Per address, validate sufficient balance and estimate fee
Transaction notes & tagging
It will probably take another week to really refine and polish this.
Do you think what’s in the video is a good direction? What’s good/bad/missing? Is it overkill? Let me know.
Lots of my thinking is based on content from the Bitcoin Design Guide, like the Sending, Payment request formats, and Human readable address pages. Plan is to refine some of the content based on my learnings from Arké.
To me, this is quite a speculative part of the app at this moment, but one that will be really important to get right, because it is about fees, which are one of the primary incentives for using Ark. It will also directly reflect the economics and dynamics of the bitcoin/lightning/ark infrastructure. Quite the moving target, especially with fees structures not finalized in general. First versions of the app might not even have these screens, since there might not even be enough servers to choose from. We’ll see.
So how do we keep users in charge, push for transparency and decentralization, and also keep things simple? I came up with a two-step process where first users state how they think they are going to use the wallet, and then we can calculate estimated fees. They can simply click through if they don’t care, or they can dig deep into the details. Up to them.
What do you make of this? If you were a casual user, would this make sense to you? Would you feel empowered? Or overwhelmed? Is it necessary or unnecessary complexity? Other explorations you’d like to see?
I am sure the Second gang has a lot of thoughts on servers and fees, so I’d be very curious to also hear how this matches their outlook and expectations.
Love the new features and that the work at bitcoin.design is making its way into Arké (in a purist form! )
Sending
For payment fees, I think some users are going to need an “expanded” view for how fees are derived. It’s good that they can learn why they vary so much between payment methods if they want to, and could help them adjust their preferred methods.
Server
Providing fee predictions based on expected spending behavior is a really smart way of presenting server selection options and not something I’d considered before, but obvious in retrospect.
A couple of missing key factors that will affect the fee costs are:
Volume of users on a server, a proxy for the network effect—the more users on the server the more people you’ll be able to pay over Ark instead of Lightning or on-chain.
Related to above, the ratio of Ark/Lightning/on-chain payments a user expects to make.
Not sure if Ark servers will be revealing those figures and it’ll be difficult for a user to predict their protocol usage, so don’t have a good suggestion on how to factor these in yet!
PS. I wish you hadn’t lingered on screens making Second look like the most expensive option!
I also got feedback in the Bitcoin Design Discord that estimating your own usage is probably a hard to impossible task for most people. A suggestion was to pick a good default (still with an option to change it for the determined users), and then track usage & fees for a month or so and make a suggestion to switch servers based on how the math pans out. An alternative that I would like to explore further. But I may wait until fees are implemented, so there’s actual math to work with.
I do hope that we get some very transparent Ark server admins that present their services well (reliability, fees, team, security…) and we don’t end up with a list of IP addresses from anons. Adding logos, names and website links in there was my way to nudge into that direction.
To your first point, showing volume of users might lead to centralization. Is that something to be concerned about? Or maybe the liquidity requirements will put a natural cap on servers size?
At Second we’ll be super transparent with uptime stats, fees, and team. Hope others do the same.
Obviously I’m biased because Second’s business model is based on running an Ark server, but some level of centralization is an inherent part of the Ark protocol that users need to get comfortable with. At current levels of bitcoin adoption, I don’t see more than a handful of active Ark servers being viable.
Users should not make decisions purely on which server has the greatest number of users, but it will be a factor. The fact we expect users will—all things being equal—prefer a server with more network effect, suggests that from a UX perspective wallets should be sharing this information—users are going to find it out one way or another.
Users are going to see lower fees paying to users of the same server vs. users of other Ark servers, plus probably some speed benefits. So there will be organic forces driving them to the most popular servers.
I don’t expect liquidity being a constraint on server size either. A user refreshing on one server requires the same amount of liquidity as another, and you’d expect through economies of scale, a larger server will have advantages in obtaining access to capital than a smaller server. Also, a smaller server will see a higher proportion of Lightning payments, which are liquidity-requiring operations, so more liquidity will be required relative to the volume of payments.
Rather, I’d expect that the size of servers will be constrained by service offering. Like any other industry, it seems likely that servers will differentiate for the needs of different user niches. Some examples of how they might differentiate: server parameters (round intervals, VTXO lifetime), uptime, service quality, fees, min/max payments, language support, etc. It would take a really great server to meet the needs of all types of bitcoin user!
Next update, this one is all about the new Bark FFI Swift bindings (ark-bitcoin / bark-ffi · GitLab) that Kumulynja is working on, and what they enable. Arké now has a (very rough) mobile companion that plays together nicely with the desktop app. Take a peek…
As the video shows, I am really looking to create a seamless experience across devices. Magic internet money should feel magical like that. Trick is to not compromise on security, privacy, etc.
Previously, I embedded the bark executable directly in the app, which was technically only possible on MacOS. iOS is more sandboxed, and needs this new approach. Now, the same code can run across both platforms. Outside of bark, there’s of course some platform-specific code for the differences in things like navigation, but the majority is shared.
Swift is super nice to work with cross-platform. And Keychain and CloudKit are amazing for syncing data. Still a big work-in-progress, but I am excited to see what else is possible with this foundation. Let me know what you’d like to see (or things not to do) in that regard.
The next week or two will be less dramatic, and be more about refining what’s there.
Hey Christophe, this looks brilliant! I thought myself about syncing data across platforms and in theory it should provide a brilliant UX for people. One thing to be aware of is you must make sure that devices aren’t using out of date information.
Unlike lightning you shouldn’t face losing funds by using out-of-date data but payments may fail
Funds may be missing when using esplora to sync because we provide BDK with the list of revealed SPK’s to check for transactions. If your mobile app and desktop app get out-of-sync with this particular detail then you may experience onchain funds not being detected.
You need to be careful with pending lightning payments and receives. If you make a lightning payment and it doesn’t initiate immediately you’ll end up with a pending lightning send. This will then be checked every time you sync the offchain wallet and will result in VTXOs being created/stored. Guarding against both platforms trying to proceed a lightning payment may be difficult and hard to debug.
Thanks for the input on that. Getting hands-on, I am realizing that syncing the database is more tricky than I assumed. iCloud does sync files automatically, but not reliably and can’t automatically merge different versions of a SQLite file. Here’s what I came up with so far:
Each app install has its own SQLite file
Each can see the SQLite files from the other apps
Apps regularly check for changes in those other files
If they detect changes, they port them over to their own file
This does require some additions to bark and bark-ffi. What do you make of that approach?
I also added a linked device registry (synced via iCloud) with a heartbeat, meaning that apps can see if there are other installs and when those were last online. Mainly a security feature, but it could also be helpful to navigate syncing.
Initially, my hope was that the server simply keeps track of everything and can be the source of truth. But it doesn’t seem that simple.
A fallback for the time being could be that one app is the authority and responsible for syncing, while the others are in read-only mode (might need an openWalletReadOnly function). Short-term, at this early stage, that might be the way to go.
Happy to hear any tips, as it’s not something I’ve done before.
Initially, my hope was that the server simply keeps track of everything and can be the source of truth. But it doesn’t seem that simple.
In regards to this I would say if you want a central source of truth then that source should be a barkd instance. I know that’s not what you’re trying to implement with this but it’s definitely the easy route.
If you want cross device syncing of the same wallet then I think you’ll ultimately have to implement locking using the filesystem (with maybe a heartbeat?). That said it wouldn’t resolve issues where iCloud doesn’t pull changes immediately
I am not tied to any solution, just want to go with what’s best. If that’s barkd, and iOS can support that, then I’ll switch. Can you tell me more about how that would be a better source of truth in a setup where multiple devices need to access the latest data?
)
