Replying to Avatar Aaron

I have been hacking away at a v2 of Clams which involves pretty much completely rewriting the codebase, and I thought that I should try building it in public for anyone that might be interested. The plan is to regularly add posts to this thread showing progress, what problems I am trying to solve, what I am stuck on and any other thoughts I have. Hopefully I can get some good feedback/criticism along the way, but either way, sometimes it is just good to write things down to get them out of my head :).

So for some background I thought I would try and sum up the goals, top level features and people we are building for in v1 of Clams and contrast that with the upcoming v2 aspirations.

CLAMS V1

Goals

Remove barriers to spending Bitcoin on a daily basis by making connecting to a remote node simple and performant, payments on the go easy and make tax time a simple one click export.

Who Are We Building For?

Version 1 of Clams is built for individuals running a personal Core Lightning node and want a clean UI tailored to sending and receiving payments on the go, managing channels, offers and accounting exports. It uses a novel way of connecting to the node which does not require any additional software to be installed alongside the node and rather uses the lightning network (BOLT#1, BOLT#8) itself to connect.

Top Level features

- Progressive Web App, runs on any device with a web browser and can be saved to the home screen for a native app like experience.

- Privacy focused. All data is stored locally. No logging, no Google scripts.

- FOSS.

- Internationalisation built in, but we need to create/commission translations.

- Secure and private connection to the node using the lightning network messaging protocol and the Commando plugin for RPC access, with no additional software required.

- Send and receive payments with a clean and easy to use interface.

- View and manage channels.

- Create and pay/withdraw BOLT12 Offers.

- One click download of CSV files that can be uploaded to tax services like Koinly for simple end of year capital gains/loss calculations.

- LNURL client side support for Pay, Withdraw and Auth protocols

CLAMS V2

Goals

Create a unified Bitcoin app that provides individuals and businesses that are running on a Bitcoin standard all of the tools needed to efficiently manage their finances.

Who Are We Building For?

Bitcoiners. People who are living in the future and are living in a mostly post-fiat world. It could be anyone from an individual running a single node, to a professional routing node runner, to a business that has multiple nodes and cold storage devices for their funds.

Typically most Bitcoiners have their bitcoin and transaction data spread across multiple apps, nodes and cold storage devices. Clams is where all of the data can be synced/imported locally on a device. Once that data is collated in the one place, metadata can be added to enhance it to provide greater insights as well as automated tax and business reporting.

Top Level Features

Not all of these features will be in the initial v2 release, but are definitely ones that we want to implement eventually.

- All of the features that are listed above in v1 will be carried over. Some of those features will also get a bit of a revisit to enhance them further.

- Cross platform app. In addition to the PWA, we are using Tauri to create a native desktop app and down the line native mobile apps. This means that you can use Clams on whichever device and platform you like.

- Connect more than just a Core Lightning node. We will have a more generic "Connections" interface which generalises any kind of Bitcoin connection for syncing data. We currently have plans to support LND, xpub, multisig, Electrum and Esplora (for private xpub data) connections. Further in the future we may implement Coldcard and Jade connections as well as other protocols such as Fedimint and Cashu connections. Basically any kind of transaction related to Bitcoin, we should be able to make a connection interface for Clams. The app itself just interacts with a generic interface for any given connection and just progressively enhances the available features based on what is available to a specific connection.

- One click profit and loss statements for businesses. We have been working with nostr:npub1drlw0wmu9tq37usx4qt3u6u4zj44mrf3zsfa6xhcdyrh3n4wpmgqr4rfg0 to understand what Bitcoin businesses need for automatic data exports for simple accounting and that is part of what prompted a need for a full refactor of the app. We will be also adding an API to our server and a DB with historical Bitcoin prices to facilitate automatic capital gains/loss calculations

- Built in Koinly replacement that is focused only on Bitcoin and will not require sending all of your personal transaction data to a server, but generated from your local enhanced data. This will require generating tax documents for each jurisdiction, so will likely be rolled out one at a time.

- Add metadata to your data to further enhance it's usefulness. This will make one click profit and loss statements, charts showing changes over time for certain types of transactions and a lot more possible. We will have reasonable default metadata out of the box for transactions (think "income", "expense", "transfer") and since the app will have an overview of all of your transactions it can automatically detect transfers. I also find personally that in our house we find ourselves asking "How much did we spend on food in the last 3 months" so that we can effectively adjust our budget to know how much bitcoin we can buy lol. The ability to tag transactions is key to being able to gain these kind of insights.

- Charts that show you totals and data over time allowing you to get a big picture view over your finances. You can customise the charts using your custom metadata to show whatever you like.

- Lightning Address and LNURL Pay codes straight to your node(s). Add your node auth (to create invoices) and connection details and our server will handle all requests to your address and pay codes. You can give details for multiple nodes for fallbacks just in case one of your nodes is down.

- Lightning node uptime monitoring. Our server can regularly attempt to make a peer connection to your node and if it is down, send you a notification via Nostr DM, Email, Text.

- Encrypted data backups to our server as well as a simple export of all data from your device to backup yourself.

- Advanced permissions and device syncing so that you can selectively allow others access to certain parts of your data. An example would be allowing your accountant read only access to updated data so that they can open Clams and export necessary data/documents on a quarterly basis.

- Custom data imports for when automatic syncing connections cannot be created (think custodial apps like WOS).

- Clean UI integrations with node providers like Greenlight and Voltage so that a node can be spun up and automatically connected to from within the app.

- Clean UI integrations with ways to buy and sell Bitcoin from within the app with API's from Azteco, The Bitcoin Company, Bitrefill etc.

- Clean UI integrations with leading LSP providers and Liquidity Ads protocol for getting inbound liquidity.

- Nostr DMs and identity key management that can be derived from your root node keys.

- Professional business invoicing that pays directly to your node(s), cold storage etc.

We plan to monetise the app some time next year so that we can try and create a sustainable business ourselves that brings in sats flow. We will probably follow the Mutiny+ model and make a collection of the above features available for a monthly subscription fee, but will always have a core set of features that are useful and free out of the box. Most likely the features that are included in the paid subscription are the ones that require our server to work which cost resources on our end.

So if you got this far, you may want to follow along and try out the app on a CoreLN regtest node yourself. The latest code is available on the v2 branch here: https://github.com/clams-tech/App/tree/v2

I am going to start adding posts to this thread to catch you all up to where v2 is currently at and then regularly post updates as I go.

DB

So the first major refactor for v2 we needed to do is store data locally in a structured way. In v1 conceptually we thought of the connected Core Lightning node as just an API server. The browser would make requests and then store the result in memory and the UI would react to the in memory observables. For v2 we are conceptually thinking about the connections as a data source that we need to sync our local DB with. We also need to be able to make SQL type queries on the local data to be able to link all of the different data types together, so IndexedDB seemed to be the way to go.

The IndexedDB API is a little gnarly to work with raw and we also ideally wanted to have the DB be reactive so we could map the UI state directly to the DB and have it update in real time. I did some digging and came across Dexie JS (https://dexie.org/). It is a light, performant wrapper around IndexedDB and comes out of the box with "live queries" which return an observable that updates when DB updates affect that specific query. Clams is already built on the killer combo of Svelte and RXJS which play really well together, so adding Dexie was perfect!

So our connection sync strategy is that when the app loads, or the "Sync" button is clicked for a connection, we will initiate the connection, fetch all the required data, update the DB and that will directly drive the UI. We have a `lastSync` timestamp parameter stored, so the goal would be to only fetch data that has been updated since the last timestamp to avoid being bandwidth inefficient and fetching data we already have. I am still working out how we are going to do that for CoreLN (currently the only connection implemented). I am thinking that we might be able to do it with their SQL plugin and use a query that asks for all data with a timestamp after `lastSync`. Otherwise the proposed "wait" API that Rusty has been working on might be able to work nicely as well.

So v2 now has a nice structured DB that is indexed for efficient queries and reactive so that it can drive the UI directly.

Reply to this note

Please Login to reply.

Discussion

Hmmm nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg rendered that Dexie link weirdly since I put it in parenthesis. For those interested:

https://dexie.org