@ab
3,921 sats stacked
stacking since: #31048
by
for
I'll be demonstrating how to connect a regtest Core Lightning node (via Polar) to the Clams app and show how all of the features work, including BOLT12 Offers.
Event is here if you want to join.
Playing around with a regtest node and Clams is a nice way to get a feel for the app before connecting a mainnet node.
Yes we have used the Bitcoin Design work as a reference for a lot of the designs in Clams. I checked out what you all had for BOLT12 and async payments, but there wasn't a lot there that I could find at the time.
If you all have any feedback, or want to jam on it, let me know! I think there is a lot of improvements that need to be made to get the UX to a level that a person that is not familiar with Lightning can use BOLT12 easily. I am hoping that once it is widely supported, we can collapse the "receive" and BOLT12 payment flows in to one nice flow, but I hope that this is a good start to get people using it and we can go from there.
Hopefully soon. I guess we need all of the implementations to support and then wallets will likely follow. I think LDK and Eclair are actively working on BOLT12 support, so we may see support from Phoenix wallet soon? LND is the big one that will need to support it and someone has built a daemon that you can run along side LND which supports BOLT12 which is cool. So yeah fingers crossed that we can all be using BOLT12 regularly soon!
I have been heads down working on this for the last month or so and I am stoked to get this out! Would love any feedback from CoreLN node runners. There is a lot of new terminology in offers that I did my best to convey, but I expect the UX to evolve over time with feedback. I am also hoping that we can make it more accessible for people that are new to Lightning as I imagine it would be pretty confusing if you are not familiar with BOLT12.
Yeah this looks great for testing relays out. Thanks for sharing.
It's early days, but I am working on a wallet for CLN (Clams). Right now it is designed around making payments from your phone on the go. But the plan is to highlight all of the great features that CLN provides. Bolt12, Bookkeeper accounting dashboard, Liquidity ads dashboard etc.
Yeah I agree it is not as simple as F LND. We are all Bitcoiners here at the end of the day, we are on the same team and we should strive for a collaborative rather than combative environment as we are fighting an uphill battle against the incumbents as it is.
Have you written down anywhere the pain points you ran in to when trying to build a business on CLN? I would personally be interested to understand what you mean and my sense is that the CLN team would value that feedback. Things that come to my mind for enterprise businesses would be the ability to run a cluster of nodes connected to the same DB for failover options, but I believe the Postgres backend looks like a good option there, but admittedly I have not tried that option before. Previously CLN seemed to be better in regards to DB size (reason for zero fee routing node to switch i believe) but my understanding is that LND has made improvements to catch up on this in recent releases. So yeah curious on particularly what you found a show stopper in CLN integration.
I like the idea of Greenlight and have high hopes for it. It is yet another way people can run nodes and I like that there are so many options with different tradeoffs that suit different situations. I am curious in the long run if there will be a power law distribution on how people run nodes. Will it mostly be full mobile nodes, will it be node in a box solutions, will it be cloud nodes or a combination that is reasonably distributed? I look forward the Breez/Greenlight solution as it feels like a great set of tradeoffs for most average users, but let's see!
I guess the project I am working on (Clams) counts as a hobby project as it is not used at any real scale ATM, but I found that all of the CLN Rest API's are easy to use and are reliable. I also have found that the CLN team are all super responsive on their discord and are very generous with their time when I needed help with anything.
I was previously building a project on LND and I think the docs are definitely better, and I had helpful and quick responses from their devs in their Slack as well.
So overall I would say that both implementations currently have a similar dev experience.
I chose to build on CLN as I think they are prioritising better features (Bolt 12, Liquidity Ads, Bookkeeper) and I would like them to have a greater share of the network. Having 90% of the network using one implementation is not good for the network as a whole IMO.
Yeah I agree it would be a lot of work. I was thinking that it could start with support for a few major countries and branch out from there. I bet there would be ways to monetise with premium features like Rotki. It is not exactly an idea I would excited to work on, but feels like something that is super important to get the circular economy happening. I want to get merchants accepting Bitcoin, but I also feel like I need to inform them of the tax burden involved. It would be great if it was recognised as legal tender everywhere instead, maybe the effort is best spent there?
After playing around with it for a bit, it looks solid. I reckon a Bitcoin focused app that is similar to Rotki but also exports tax forms like Koinly does would be killer.
Thanks for the link, I will check it out.
I am curious, how did you go about learning these ranking and web of trust algorithms? Any particular resources you found useful? Very cool.
Mutiny web looks awesome!
Working on Clams, a browser app for controlling your CLN node. Just shipped LNURL Auth, so using that now to login to Stacker.news.
I also printed some of those open source Bitcoin for business flyers so that I can give them out at the local farmers market next week. Hopefully I can get a few vendors onboard so I can start using Clams to pay for my produce each week!
Yeah we have been thinking about publicly sharing credentials for our regtest nodes we have running so that anyone could try out the app first, but I am worried that it could lead to a bad experience if multiple people are using the same two nodes at the same time, but maybe we will give it a try with that caveat and see what happens. I am hoping it will lead to more people running Core LN nodes!
We have put a lot of thought in to making the app as secure as possible, but would definitely like feedback on how it could be more secure. Is there anything in particular about browser apps that you find make them insecure?
The way the app works is that it spins up what can be conceptually thought of as an ultra light node that communicates with your node via the lightning network itself. This means that it uses the lightning transport protocol (NOISE) which is fully end to end encrypted. When the app connects to your node, it actually shows up as a regular peer but with feature bits all set to zeros.
All credentials like your rune and node connection address can be encrypted with a pin, so that they are encrypted when stored in local storage and only decrypted in memory after pin entry.
We also assign the app a persistent public key which means that you can restrict your Rune to only work with this "session" in the app. Simply reset the app and now that rune can no longer be used even if someone else has got access to it as they would need to corresponding private key that only the app had.
You can check out the docs for more detailed info and if you have any other questions, drop them here or in our discord.
Hey mate, thanks for all your work in the Bitcoin and now the Nostr space!
I was wondering what your thoughts on how relays in the Nostr ecosystem will end up monetising their services as this will be needed to be sustainable in the long term?
When I think of setting up a relay, I start to think of the very real resources that will be consumed if Nostr were to take off and it kind of gets tricky as to who to charge for those resources. I know Fiatjaf has built a relay that allows for charging and he believes the market will sort out how to price these resources, but it still seems like a big unanswered question at the moment.
Breaking down the costs of running a relayer:
  • Storage of the data. Could be charged to the person storing the data, but is it a one time charge or ongoing?
  • Serving of the data - maintaining WebSocket connections, network bandwidth. Who pays for this?
I could imagine a client having their own relay and they charge a monthly fee that allows for a certain amount of storage and subscribing to a certain amount of updates per month.
It gets interesting when you consider if an account becomes super popular and has a huge number of different clients connecting and pulling in data for that account. Should the account pay for that network bandwidth and socket connection requirements, or should the subscriber pay for those resources?