Suheb, co-founder of RTL joins me in this episode to talk about tips on managing your Lightning Node with RTL. We talk:

• How Suheb got into Lightning
• His experience with the Lightning Torch
• Different personas for RTL – Node Operator, Merchant
• Channel Management
• Interface
• What’s coming next with RTL

Suheb and RTL links:

• Twitter: @Suheb__
• RTL: @RTL_app
• RTL Github: RTL Github

Sponsor links:

• Kraken
• Unchained Capital
• CypherWheel by CypherSafe
• GiveBitcoin

Stephan Livera links:

• Show notes and website
• Follow me on twitter @stephanlivera
• Subscribe to the podcast

Podcast Transcript:

Stephan Livera: Suheb, welcome to the show.

Suheb: Hey, Stephan. Thanks, thanks for having me.

Stephan Livera: So, Suheb, I know you have been doing a lot of cool work on RTL and look, I think we’d love to just hear some of your story on how you got into all this.

Suheb: Sure. Great. Thanks for the opportunity to tell my story. So, if you look at RTL as an app, right? In reality it’s actually, in its mission it’s actually pretty simple, right? Just creating a UI layer on top of existing Lightning implementations. So, in the essence, really a simple job, right? But, if you look at the implementation, it turns out to be really complex because we are trying to create a power user experience.

Suheb: It’s a power user experience. Try to expose as much as we can in terms of the functionality of Lightning implementations on the UI, right? So, give a clear user experience, UI focused. So, that, kind of makes it a little bit complicated in terms of all the functions that we have to handle. You know, try to think about what type of user experience to provide on specific functionality. So, that makes it kind of complicated. So, simple mission, complicated in implementation.

Stephan Livera: Yeah. And also, you participated in the Lightning Torch as well. Tell us about some of your early days experiences with Lightning network.

Suheb: Sure. Yeah, that was really an exciting experiment and definitely… I’m actually number 50, or 51 on Lightning Torch. So, definitely that was exciting. Right? So, yeah. And, I actually use RTL, that I was, participating in the Lightning torch. So, yeah, definitely it proves first of all that Lightning works, right? And, being part of that, you know, getting that torch and experiment and being part of the chain was really an exciting, you know, experience in community building, kind of you know, Lightning community building experience. So, that was a great experience for me.

Stephan Livera: Yeah. And maybe, tell us a little bit about why you started RTL, and when it started.

Suheb: Yeah, sure. So, we’ve been developing RTL for more than a year now. So, it started with my first experiment with Lightning kind of. So, you know, I set up my full node just after lnd went on main net. So, lnd went on mainnet in March of 2018 and on April, 2018 I had my full node up and running on Raspberry PI. I actually used Stadicus’, you know…

Stephan Livera: [inaudible 00:02:38] bolt. Yeah.

Suheb: Yeah. Of course. Yeah. So, I used his, his guide to set up my node. So, I had some experience of working on Raspberry PIs, and some Linux experience as well. So, it was pretty easy for me to follow that guidance set of the node. But, once I set up the node, that’s when I realized that, okay, you know, I have this node up and running. Now, I have to open channels. Once I’ve opened channels, I need to see, okay, how are my channels doing, are my channels balanced? Am I routing anything?

Suheb: You know, at any point in time when I need to log in and view the status of my node, there are at least 10, if not ten, five different commands that I have to run to really get a good view of, where my node is, right? What are the fears, what are the channels? There’s so many things that you have to, you can do. And LND, you know, has actually done a very good job in terms of the different API functionality that they have provided, different commands that they have provided. Kind of gives a lot of detailed view.

Suheb: So, it became pretty evident to me, you know, when I started operating the node that I need some sort of a dashboard, right? You know, the moment I log in, there are 10 parameters that I need to see. And, I need a good view of that. Right? So, that became a motivation to build this UI. And, at that time there was no build UI available. And, we wanted the UI to have, you know, an opinion about the type of user it should be focused on. Right? So, my view was that it should be a power user focused tool, especially focused on Lightning node operators, and all they need to see. Right?

Suheb: So, with that kind of a user persona in mind, we started building this tool called Ride the Lightning. So, yeah. And, we’ve been on this journey for more than a year now. We had our first release in October of 2018. And, it’s been 40 plus releases. There are a couple of other things that we have done on the side. So, yeah, that’s kind of the way it started.

Stephan Livera: And, what’s in a name? Why the name, Ride the Lightning?

Suheb: Yeah. I’m not a Metallica fan to begin with. But, interestingly, so before I actually started building this app, I was like reasonably active on Bitcoin, Twitter. And, there is one interesting Twitter account, goes by the handle @MediumSqueeze. And, that handle’s name is Ride the Lightning. So, I was very fascinated by, that Twitter handle. And, he’s kind of, you can call him a maximalist, I think in his views. Right?

Suheb: So, I like his views. I like his tweets. And, I liked, ride the Lightning @MediumSqueeze. I liked it a lot. So, that was one good, you know, that kind of was always there in the back of my mind. Right? That account. I liked that account. And, when we were like thinking about, you know, naming the app, it was, kind of giving you a control over Lightning, right?

Suheb: It is giving you how to manage your Lightning node. So, we thought that, you know, Ride the Lightning is a good kind of a name for this app, which is allowing you to control the power of Lightning, empowering you. So, you are able to ride the Lightning network with, with RTL. So, that’s all you know. Ride the Lightning. But, I hope Metallica fans are not upset with me by using this, for using this name.

Stephan Livera: No, that’s great. That’s awesome. And, I mean for me personally, I use RTL. Off the top of my head, I have at least three different instances of RTL running. Right? I’ve got it on my myNode. I’ve got it on my nodl, I have it on my BTCPay. It’s used in many different software, let’s call it packages or hardware packages because it’s just such an easy tool to manage your Lightning channels. So, I think we can maybe dive into more detail.

Suheb: There’s one interesting thing I wanted to tell you about Ride Lightning name. I was actually researching that a little bit. So, Ride the Lightning, even the Metallica didn’t come up with this name originally. This name or the phrase, was actually borrowed from a Stephen King novel. So, it’s an interesting [crosstalk 00:07:00].

Stephan Livera: There you go. It’s Okay. When you’re playing at a conference or something, you’ve got to have like obviously Ride the Lightning as your intro song and everything. So…

Suheb: Yeah. Yeah.

Stephan Livera: Yeah. That’s great. So look, let’s jump into some of the high level. What’s it look like when you go into the tool? Typically, users who have, let’s say BTCPayServer or one of these other products like say a nodl, or I think even the new Casa Node will have BTCPayServer, and therefore with that it will also have RTL. So, I think it’s a very common package. So, basically my experience is, you know you have the password, you log in and then it presents you with the home dashboard. What are we seeing on this screen?

Suheb: Yeah, so if you look at the dashboard, originally there is your Lighting balance, your on chain balance. Lightning balance essentially the amount of funds that you have logged into your channels. And, it actually is giving you your incoming side of it, the liquidity on your side. So, that is one view. And, then second is if you have any on chain balance, you get one view of that.

Suheb: You get a view of how many channels are active, inactive, or in pending status. You get a view of if the node is routing, you know, follow up forwarding transactions, then LND has a bit of an API which gives you a view of daily fees collected, weekly fees collected, monthly fees collected. So, I mean, just giving you a view of that. If the node is active, and forwarding transactions, so how much fees you have been collecting.

Suheb: It also gives you a view of your channel balance comparison, you know, local vis-à-vis remote, so that you can actually see how balanced your channels are. And, this is specifically very important for routing node operators, because ideally they want to be routing in both sides, right? They want to be routing both incoming transactions, outgoing transactions. So, they need the channels to be balanced, right? So, that’s an important parameter that you have on the top.

Suheb: And then, a network view, you know, which is giving you a decentralized view of how you’re, depending on the graph that your node has, what is the network view of that nodes graph. And, this is the one API, again, lnd has. So, you get a view of… That kind of give you a, you know, a bird’s eye view of how your node is doing, and how is the network, specifically, a power user would want to know all of this information.

Stephan Livera: Yeah, that’s awesome. And, I think for me, I’ve used RTL quite a lot just to get a quick view on what is my current state of my channels? And, even if you need to fund your LND node, then it has its own little on chain wallet, which is distinct from say, like a Bitcoin wallet, like standard one. Because, LND has its own little on chain wallet and this is that AEZeed one, like the special seed. And so, then you can fund it that way. And then, you can open the channel from your RTL node, or the other way is if you open channels from some other node in the direction of your own node, so that you have the incoming capacity obviously.

Suheb: Right.

Stephan Livera: So, I guess the main things that we’re interested in as a Lightning node operator, and look, if you’re listening to this today, you’re probably a bit more of a power user, right? Because, there are, well, let’s see on my RTL there are, my node sees 6,078 other nodes out there. So, that’s roughly how many there are today. Let’s talk a little bit about what you would use that for. So, let’s say you see the balance, and you see the channels. What are some good tips there that you would use? Like, what would you manage with it?

Suheb: Yeah. So, typically, right? If you’re a routing node operator, I mean again, so there are different personas, right? So, depending on what persona you have. So, and we kind of went back now, we’ll actually get into the RTL, or what’s coming in RTL, you know, from an improvement perspective. And so, then I can talk more about the direction that we are taking.

Suheb: But, given the current persona, which is the routing node operator persona, typically what you will do is, one is discovery. You know, who do I need to connect with once you’ve started the node, right? So, again the functionality of discovery itself is not built into RTL, because it’s not there in LND per se. Although LND has autopilot feature which allows you to, discover and connect with the nodes automatically.

Suheb: But, what you can do is you can also go out on your own and figure out, okay, you know. There are certain lightning stores which are opening up or coming up with, you know, are going to provide option for accepting Lightning payments. So, let me open a channel to them. So, once you find out, okay these are good nodes to connect to on the network. You get their a node pub key information, connect your node to them.

Suheb: So, RTL kind of has this Peer view. You can go to the Peer review, put in the Peer ID, the public key, connect to them. So, the moment you connect with those nodes RTL, you have control on RTL, which will allow you to open the channel with RTL. So, that it is, you don’t have to again go to a second page and, discover where that Peer went.

Suheb: So, you can click under the control on the grid, and same Peer information is populated in the next page, and you can fund whatever amount you want to provide on the channel, and open the channel to that Peer. So, that is one thing, connecting with the Peers, opening a channel to them. Second thing, once you have your channels open, you can influence the fees that you want to collect when you’re forwarding payments, right?

Suheb: So, and there are multiple factors that you can influence when you are adjusting the fees, you can adjust the base amount, and you can adjust the percentage that you want to collect, or the transaction amount. So, there is an edit button on the channel management page. You can adjust the fees per channel, you know, depending on whatever you think is a good, amount to charge for routing the fee.

Suheb: And, you can also apply the same policy for all your channels at once. So, you need not manage per channel tweaking. You can, you know, make sure that all of your channels are kind of following the same policy also. So, these are some of the controls available to connect with the Peers, and manage fee policies, so that you’ll collect optimal fee on the routing traffic that is going through your node.

Stephan Livera: That’s great. So, as an example, you might know about a submarine swap service, or you might know about a popular store, let’s say the Blockstream store. And, you might think, okay, people will want to pay in the direction of that store. And so, it’s advantageous for me, the Lightning node operator, to open a channel in the direction of that store, or that service. And then, theoretically that means people will want to route money through you.

Stephan Livera: And so then, as part of that you will amend the fee on your channels to try to account for your cost as well, because obviously you’re paying a chain fee, there is some risk associated, et cetera. And so, then, rather than leaving channel fees as the default at whatever it is, like one milli msat per, you know, million or whatever that number is, you can adjust that. And then, hopefully over time, those numbers start to reflect real liquidity, and real costs as the network grows up so to speak.

Suheb: Yeah. So, typically if, you know, a big operator is or, an eCommerce player is going to open up, you know, abilities to accept Lightning payments, they would want liquidity providers to connect with them. Right? But, what they would encourage us, people opening big channels, fat channels, right, to them so that they don’t have to manage a lot of channels because each channel management also adds overhead, right?

Suheb: So, if you’re a professional Lightning node operator, you can open, you know, commit big funds, or chunks to your, to those eCommerce operators. Then, what you can do is, you can say that, okay, I’ve got channels with these eCommerce operators, now you can open small channels from my node, all right? So that, you can route the payments to me. So, for instance, if Amazon starts accepting Lightning, let’s say, it will not allow you to open small amount of channels to them. Right? I would not… Like, I would guess that they would not allow this.

Suheb: So, it’ll allow people to open big channels only. So, if you’re a professional operator, you can open big channels. And then, people can open a small amount of channels, a small quantity channels rather, with you. So, then you become the routing hub through which the traffic can flow. So, and that’s kind of… That is, the whole play that, you know, just opening channels on the one side is not going to help. You need people coming into you, which you can forward the payments to the eCommerce operator.

Stephan Livera: Right. And also, hopefully recently… Okay. So, recently Bitfinex came out with Lightning as well. So, that’s another example of a person who you might want to open a channel in that direction, and then other people, same way would want to open a channel with you, and then they can transact with Bitfinex.

Suheb: Yeah, so Bitfinex for instance had a capacity of a minimum amount of 4 million sats. Right? Or, Yall’s for instance that, you know, open a channel, minimum 5 million sacks. Don’t open less than that. Now, you know, if you’re an operator, a routing node operator, you can open, but then you can keep your incoming capacity as unlimited less, so that you know, people can open small amounts, small quantity channels with you. Then, you become like, a hub for routing.

Stephan Livera: And, let’s talk about fees then. So, can you tell us a little bit about the fee reports?

Suheb: Yeah. So, at this time, fee reporting is pretty basic in RTL. So, there are two ways to see the fee report. One is on the dashboard itself, you’ll see there’s a simple API available from LND, which gives you a breakup of daily, monthly, weekly, a fee that is getting collected. There is another view called forwarding history in RTL, where you can actually see your individual transactions, like whatever is going through your node. And, for each transaction, what is the fee that you’re collecting.

Suheb: So, that is another view that you get. There’s a third view called routing Peers. Routing Peers actually is not giving you a fee view, but it is actually giving you a summarized view, or a more of a, analytical insight into what is the traffic for incoming nodes, and what is the traffic to outgoing nodes, so that you can actually clearly see, you know, where is the traffic coming from, and where am I routing it to. So, which are my active kind of, my partners.

Suheb: And, you can actually optimize your fee policy for those partners. And, the partners which are not active, you can make the fee, expensive may be for them, because they are using your liquidity, you know, lesser. So, there are multiple ways to play with it, but we are actually thinking of giving even more insightful, you know, interfaces for a fee, specifically, giving you a more fine grained view of, or, you know, a timely trend of, how your daily monthly fee collection is actually changing over a period of time. So that, you get more insights into how you’re collecting fees et cetera.

Stephan Livera: The routing Peers view also shows the events, so it’s showing events, and then the amount, and then obviously the alias of that person. So, for example, if you’re connected with the Zap node, or the Breez node, or the OpenNode node, and then, it shows, you say for example one event and, you know, 500,000 sets. And, it’s showing, okay, that’s how much got routed through to that person. And then, you can start playing off that and saying, “okay, well, there’ve been…” You know, a lot of people want to route in this direction. Okay, maybe it’s a highly demanded route. Maybe I can start charging, or whatever. Then, it sort of starts, I guess that’s where it starts to kick off in terms of Lightning network. I mean, right now it’s still early days, but it’s…

Suheb: You can open more channels for instance, right? You can see that you know, your capacity is getting depleted, or there’s enough traffic for me to sustain multiple channels for this node. So, you can do that also.

Stephan Livera: Right. Yeah.

Suheb: Then you can interpret that information, and make it more useful.

Stephan Livera: And, I think that is actually a point of difference between LND and C-lightning right now. Because my understanding is, with LND, you can do multiple channels with the same party. But, I understand with c-lightning you can only do one. Is that correct?

Suheb: That’s right. Yeah.

Stephan Livera: Right.

Suheb: With c-lightning, you can open only one channel.

Stephan Livera: Right. So, I guess if you’re a c-lightning user, you might need to close down the channel and reopen a fat one if you wanted to resize it.

Suheb: Yes, that’s right. That’s one option.

Stephan Livera: Yeah. So, let’s talk about channel backups now. So, say there’s a channel backup window. And, this is for the LND, SCB known as Static Channel Backups. Can you tell us a little bit about that?

Suheb: Yeah, sure. So, Static Channel Backups is actually a functionality which LND provided for making backups of your channels, so that in case your node gets corrupted, and does not boot up, there is a way for you to recover the funds which had been locked in the channels, right? And so, you know, when you start up your node, LND actually creates a default backup file also next [inaudible 00:21:06]. So, but given that they have provided set of APIs, we also provided an interface where you can actually do a channel level backup if you want, or you can do an all channel backup.

Suheb: Also, whenever you perform any channel activity, right? So, for instance, if you open new channels, or if you close down existing channels, RTL automatically takes up the backup also, right? So, RTL is kind of automating that all channel backup is always fresh whenever you are changing your channel states. Right? You can also specify the part where your backup file will be stored in the RTL.conf File, insert in the configuration file, you can store where you want to, maybe, you can configure where you want to store your backup file.

Suheb: So, yes, so RTL will continue to take the backups wherever you’re configured. The important thing is that you should create redundancy of the backup file, store that backup file somewhere elsewhere away from the node also, which ideally, there’s no way at this point to manage, but at least make sure that you have a written copy of that file, so that in case you have to recover, you have the back file that you can use to recover the balances which were logged in your channels.

Stephan Livera: Right. For me, I periodically just pull a copy off of the device itself, and keep it on another device. Right? So, for example, myNode one, and my nodl one, I keep those elsewhere just in case, obviously something would happen to it, then I’ve still got at least a static channel backup for them. And, I understand there was also some people who unfortunately got caught out, because they took a Static Channel Backup while the channel was unconfirmed. Right? Whereas I understand it’s best to do it once the channel has confirmed.

Stephan Livera: As in, so, I guess let me just walk that through just for listeners who are not as familiar. So, when you open the channel with somebody, it’s still pending open until that on chain transaction has confirmed on the Bitcoin blockchain. Right? So, every Bitcoin Lightning channel open and close, is itself a valid Bitcoin transaction, and you need to wait for that to confirm and then do the channel backup.

Stephan Livera: So, let’s talk a little bit around channel management now. So, I think we were touching on some of this before, but I think part of the, maybe what’s a little bit harder right now is rebalancing your channels. So, we have both what is known as a local balance, and a remote balance. So, again, just to make sure our listeners can follow along, think of it like you’ve got an abacus. And, you have set number of beads on either side of that abacus. And, I think generally speaking, most of the more professional routing node operators are trying to keep it roughly 50, 50, not exactly, but just something in that range.

Stephan Livera: If it becomes too unbalanced, let’s say you’ve got 90% of the beads on your side, and only 10% on the other side, then that’s not really great from a routing perspective. Now, there are, I guess different approaches in terms of rebalancing. There is what’s known as circular rebalancing, and there’s scripts and so on. And then, there’s like the loop type services. Can you just outline some of your thoughts on that?

Suheb: So, first of all, why do we need to balance, right? I think we should touch upon that. So, if your channels are, you know, lopsided or in one direction, there’s only… The payments that can only come in that direction where you have the liquidity, right? It cannot go in the other direction. Right? So, that is kind of a fundamental, you know, payment philosophy, or payment, you know, algorithm basically, in lightning.

Suheb: Now, we need to, especially the routing node operators ideally want to route in both the directions, you know. That’s why it’s important for them to balance. They don’t want to lose, because in each transaction that they are routing, they’re making a little bit of fees, or revenue. So, they want to maximize traffic, but it does not matter which direction the traffic is in. What is important is the traffic is flowing, all right? So, that is why it is important to have a balanced channel strategy so that you’re always optimizing for maximum volume of traffic. So, that is the reason why we want to do it.

Suheb: Yeah, there are multiple ways to do it. One is self routing. Where you can actually give routing hints, and route the transaction in such a way that payment comes back to you in the other direction, via giving routing hints. Right? That’s one way to do it. But, RTL at this point, we are actually, we don’t have any channel balancing, strategy right now. We are actually looking to add Loop In and Loop Out as the solutions for channel balancing. We are not really looking to add any scripts per se, which do a self routing. Because, not all of those scripts are, they don’t always 100% balance the channels. Right? So, it’s very difficult to explain to the users how, why the channels will not balance even if, you know, even if you’ve executed the script.

Suheb: So, that’s why we have decided to steer clear at this point, you know, unless we have something stable, well tested scripts out there, which can be included via Java script. That was another challenge. We have decided not to include those independent routing scripts for self-balancing. Loop In, Loop Out, are good, LND supported tools which can be used for channel balancing. Then, depending on which side you want your liquidity, both the solutions are available for the users to, you know, make use of and balance their channels.

Stephan Livera: Yep. So I’ll just point out here for listeners who want more detail, check out my recent episode with Alex Bosworth from Lightning labs. We talk a little bit about Loop, but Suheb, from your point of view, can you just talk through, what are some of the use case, the typical uses there for a Loop In, or for a Loop Out?

Suheb: Sure, definitely. So, Loop Out, let me start with Loop Out, right? So, Loop Out is basically, let’s say you’re a merchant, right? And, you are receiving a lot of volume of transactions, right? So, which means that the channels might get lopsided on your direction, you’ll get all your liquidity on your side. So, while it’s a good thing that you’re getting so much traffic that you know, have your balance moved on that side, but the problem that it creates is you cannot accept any more transactions until you have the balance move to the other side. Right?

Suheb: So, how do we solve that problem? So, Loop Out is one solution to that. Where, what you can do is you can… So, there’ll be two legs to complete a Loop Out transaction. You will make a Lightning payment, which will shift the balance from your incoming inside to your outgoing side. And, in lieu of that payment that you did, you will get an an equal on chain balance, right? So, whatever amount that you paid, there’ll be a little bit of, service fees detected, or swap fee deducted, and you’ll get the equivalent amount on your on chain wallet.

Suheb: So, you will have your channels balanced, and you’ll get equivalent on chain balance. You’ll be able to kind of like, withdraw the funds to your on chain wallet, and get your channels balanced. So, again to explain that there are two steps. One is you pay a Lightning invoice, and you get on chain output to your wallet.

Stephan Livera: Awesome. And, now the other way around, Loop In?

Suheb: Yeah, so Loop In is basically, you know, you want to get the balance on your side, so that you can make the payment, right? But so, without having to close the channel, open a new channel, right? So, what you will need to do is, you will make a on chain payment, and in lieu, you will get an invoice paid so that you get the balance on whatever on chain payments you made, minus the service fee, and you get the invoice paid so that you get the balance on your side. So, both Loop In and Loop Out have two legs, one is the on chain leg, and another is the off chain leg. In Loop In, you’re making an on chain payment, and getting a Lightning payment back.

Stephan Livera: And so, let’s talk a little bit about the fees associated for that. So, typically there are different services. I know Alex Bosworth has submarineswaps.org. And, you know, Lightning Labs will do that as a service as well. How do you think about using that in terms of the comparison of doing that, versus closing down a channel and opening a new one?

Suheb: Yeah. So, in terms of the cost, I think it is definitely much more efficient to do a loop transaction that you are paying a little bit of, you know, swap fee. But, closing and opening new channels will definitely be expensive than executing a loop transaction. So, typically in the loop transactions you have an on chain fee component, and you have an off chain fee component. And, overall if you look at the total cost, compared to opening and closing a channel, you know, doing the loop transaction is, you know, order of magnitude more, you know, less expensive.

Stephan Livera: That’s great. And, in terms of other liquidity providers. So, I know on the network there is LNBIG for example, and you can go to that LNBIG website and you can actually request an incoming channel or you can… Another one is Bitrefill Thor channels where they do that as a service. So, how do you think about using those, is that something the routing node operator might think about, or perhaps this is more relevant for a merchant?

Suheb: Yeah, it’s more of a… That’s right. And, what you have directly pointed out that that’s a tool for merchants, right? If you’re setting up your shop to accept Lightning payments, how do you get inbound liquidity? That’s your first problem, right? I need liquidity to be able to accept payments, or to be able to receive payments rather. So, these players solve that problem. And, I foresee a lot of players, as Lightning gains more prominence, Bitcoin overall gains more prominence, more adoption. I see more and more players kind of getting into that space of providing liquidity for merchants.

Suheb: Loop In, Loop Out or rather Loop Out provides a non-custodial way to gain the same type of capacity. But, the professional node operators like Bitrefill for instance, offer more reliability, you know, in the channels, and by providing services like Thor. So, and that’s actually, I believe that’s a segment which will develop as Bitcoin and Lightning adoption increases overall. So, I think there is, it makes sense to have this type of service in the market.

Stephan Livera: So, I think then there are two main profiles that you’re building for, and that are mostly relevant for people using Lightning today. And, that’s basically node operators. And, then secondly, it’s merchants. And, so typically for those merchants, I guess, it’d be good to just talk through from their point of view, they may not necessarily be very Bitcoin, or Lightning savvy. They may be more like somebody who just wants to set up, and take Lightning payments, but maybe they want to self manage, right? So, maybe they buy a nodl or they, they pay and get a VPS hosted BTCPayServer, and they’re taking payments with that.

Stephan Livera: And, I guess typically speaking, the typical things they want to know is, how much balance have they got? Can they receive a payment, have they got the liquidity for that? And then, can they withdraw the money to a safer place, take it on chain or even to fiat if they can. And, typically they might not want to close the channels to get the money out. And, I guess we’ve touched on some of those, but would you say that’s basically a good summary of the typical merchant pathways, or the things that they want to achieve?

Suheb: Yes. So, you know, once we initially started out with having only a routing node operator persona in mind, but with the BTCPayServer integration, another persona which became relevant for us was merchant node operator. I don’t know whether actually calling a merchant node operator really is the right term, but you know, merchants operating Lightning nodes rather, to accept Lightning payments. And now, their needs are different. Right? So merchants are typically, we would not expect merchants to be, very Lightning or Bitcoin savvy.

Suheb: So, what information we need to provide for that persona so that, you know, when they log into RTL, they don’t see things like, routing fee, or you know, balance channel, right? What does that mean? Right? So, this kind of thing or even network graphs, right? They are not interested to look at network graph. Like what does that mean to them?

Suheb: So, basically we have to create a different type of view, at least the dashboard should have a different view of information for them, right? Which is relevant for them. And, when I was kind of researching this persona a little bit, and you know, a shout out to Pavlenex for giving us a lot of input on that, from BTCPayServer. So, and, BTCPayServer folks kind of deal with the merchant node operators, you know, day in, day out. So, they have the best insights of what kind of typical information they would want to see.

Suheb: And, it kind of breaks down into very simple things. One is, how much they can receive, and how much they can send out. What is their Lightning balance, what is their on chain balance, right? How can they generate invoice, how can they make payments? It’s as simple as that. So, we have taken those elements. And, in our new RTL design, which we’re currently working on, we are going to create a dashboard, merchant focused persona. And, the dashboard will have a different view than what you have currently in RTL.

Suheb: And, it can give them a view of, what are the incoming channels, what are their outgoing channels, right? Keep them separate, give them a separate view, don’t mix them, so that, it becomes confusing for them. And, make it very clear to them how much they can receive, what can be the maximum amount they can receive, how much they can send out, what is the maximum amount they can send out.

Suheb: And then, once we have created those views, we can add additional features like Loop Out, right? If they are lacking liquidity in certain channels, we can give them controls like Loop Out, so they can do channel specific operations. So, you know, that gives a very, merchant focused dashboard and control, which makes it specifically easier for them to, you know, do their operations in Lightning.

Stephan Livera: Yeah. It still can be a little tricky in these early days because sometimes there might be a merchant who just starts up, and maybe if they’re more well known on Bitcoin Twitter, there’ll be all these people yelling at them saying, “Yeah, take Lightning! Take Lightning!” And, it’s sort of like, well, it’s not that simple here. Like, yeah, it’s easy for you to like, if you’re an individual to send Lightning, yeah, that’s easy. But like, when you’re a merchant and you’ve got to set up to take the channels, it’s not a simple task. It takes a bit of work, and there’s a lot of management involved with that, wouldn’t you say?

Suheb: Yeah, definitely. I agree with that. There’s a lot of education involved. And, it becomes a challenge from onboarding perspective. Right? You know, I open up a dashboard, all this information, I don’t know how I’m, you know, what does all mean? Who do I go and talk to? And, especially in a decentralized application, there’s no owner, there is no marketing department, there’s no education department, right? Everybody is in charge of their own knowledge, and understanding and operationally, it becomes overwhelming, right? You know, to put it mildly.

Suheb: But, basically, yeah. So, that is the objective. That is a problem rather. And, the objective is to kind of give them a simple a tool as possible, make it as intuitive as possible, so that they can, have their own control and learn it easily. And, that’s another thing that we actually got as a feedback, that, people expect tools like RTL to be also educative, right? And, not just operative. You know, when I’m taking on certain things I want to understand what these actions mean. You know, what does channel balance mean? So, that’s what we are trying to kind of, that type of feedback we are trying to build into the new UX design, so that it becomes a descriptive, educative as well, and not just stay as a technical tool.

Stephan Livera: Yeah. And, RTL as we’ve mentioned through this conversation has been packaged in with a lot of different software and hardware. What has been your view and experience with having RTL packaged in?

Suheb: Yeah, that was a great experience first of all, right? So, when we started out the collaboration, we initially started off with a RaspiBlitz. That was the first collaboration. And, most of these projects are also kind of, they were starting at the same time as we were starting. So, that was actually a good thing for us as well. Right? They were also kind of hunting for UI solutions because, when you are packaging a plug and play node, you can give them all the hardware and everything together. But, if you don’t have a good UI solution, now it is kind of half-baked only, right? It becomes very difficult to educate things that are about, okay, you’ve got your node ready, now go to this LND site, and there are 20 APIs, learn them first. Right? very difficult, you know, from a user onboarding perspective.

Suheb: So, if you have a good UI solution, even if it is basic, but it gives you an interface to start operating, that’s a good leg up for any node operator. So, or rather, a node solution provider. So, RaspiBlitz, was the first. So, and interesting thing is each node solution provider we collaborated with, there were requirements, there were insights, there were requests which came, which helped us make RTL a better solution. Right? So, when we start operated or rather, you know, worked with RaspiBlitz, you know, rootzoll came up with the requirement that you should provide the authentication mechanism.

Suheb: So, we added the authentication mechanisim. When we started working with nodl, you know, ketominer was always full of ideas, right? He is really talented and full of ideas. So, he said that, “Okay, why don’t you have a solution to handle multiple nodes to one UI.” So, we added that functionality. With BTCPayServer we had to dockerize the solution, right? So, whatever integration, whatever collaboration we did, we ended up handling their requirements, making other RTL solution all the more richer. And, of course it’s been a living experience working through all these talented people in the space. It was really rewarding experience also.

Stephan Livera: That’s great. And, on the topic of collaboration, we have, there’s a GitHub, for RTL, there is a Telegram chat, there’s obviously the Twitter presence. What’s been your experience there? What are the main ways that RTL contributors collaborate?

Suheb: Yeah, so typically we get a lot of requests on Twitter also. You know, initially when we didn’t set up the Telegram chat we were, I was getting a lot of DMs, people struggling with the setups, et cetera. So, I was kind of troubleshooting over Twitter’s DMs, or rather GitHub issues also. So, a lot of feedback came in. A lot of new requests came in, a lot of GitHub also, which we were consistently handling, developing, improving our RTL over a period of time.

Suheb: On Twitter, actually we got a lot of boosts from Pierre. Pierre, a good friend, who helped us, spread the word. And, that was really helpful for us to get distribution, we don’t have a big presence, we have a small presence on Twitter. But, Pierre kind of helped us get the initial boost, so that we reached out to a larger audience to, at least let them know about the solution.

Suheb: And, the intention was also to contribute to, do our part in helping Bitcoin and Lightning’s adoption improve. So, whatever we could do, that our skillsets, we’ve been to the table, can we put that to a use and, provide a solution which people can use. And, my initial thought was that if we develop a tool like RTL, the idea was to enable full node solution provider. And, we can kind of set up their business and package this UI together, and have a business ready to sell nodes for instance. Right?

Suheb: That was the idea. And, you know, has more and more solution providers integrated RTL, we got a lot of feedback from them. And, I kind of work, you know, get a lot of feedback from ketominer, get a lot of feedback, rootzoll, Pierre, you know, BTCPayServer is very demanding. So, you know, all this feedback kind of helps us make RTL a better tool.

Stephan Livera: Yeah. And, RTL started mostly as an LND, or LND only solution. And, I understand recently you’re looking now at c-lightning. Can you tell us a little bit with your interaction on that?

Suheb: Yeah, sure. So, yeah. So, basically we wanted… So given that initially, you know, Lightning, we have some sort of an experienced pattern on how to typically operate a node, right? So, now you have a standardized kind of UI of RTL. So, we were thinking that can we extend the same functionality on c-lightning also. Why just restrict it to LND? The initial roadblock for us there was that c-lightning didn’t have a good REST API interface, right? So, that we could, integrate a web application with c-lightning.

Suheb: So, that was a gap. I initially hunted for a solution. If somebody was working on a REST interface or c-lightning, I could reuse that, but I couldn’t find a good reliable solution for that. So, what happened was we ended up writing our own REST interface to c-lightning, which was also a good learning experience for us. And then, what we did was we kind of created a modularized version. So, we created a separate REST interface, and then integrated RTL on that interface.

Suheb: Now, that interface can, in stand alone, can be used by other apps also. So, if you’re a web app developer, or Lightning developer, and you want to develop applications on top of c-lightning, you can use c-lightning REST the solution to write web apps. So, not just RTL but any other web application can use that tool to, write web apps on c-lightning. Yeah, but that was the experience. Now, c-lightning is… BTCPayServer also provides an option of c-lightning to its users. So, you know, once BTCPayServer integrates RTL c-lightning version, then, you know, the c-lightning operators also have the c-lightning option available.

Stephan Livera: Yeah, that’s really cool to see. And, it’s really, a lot of things are improving very rapidly. So, I guess my next question then is more about Lightning more generally. So, especially in the early days, it was very much seen as reckless. Surely, it’s becoming less reckless over time. Though it’s still reckless right now. In your view, Suheb, when is Lightning no longer reckless?

Suheb: That’s a difficult question to answer. But, what I would rather touch upon that then is that, you know, what are the different developments that I’m looking forward to? Right? And, you know, as those developments mature, we can say the Lightning is becoming less and less reckless. And, there’s a lot of happening in the space. Typically, you can say that, and I read it somewhere that you know, Lightning is maturing in dog years, right? So, it is like really maturing very fast, right? In six to 10 months you see so many improvements, so much happening on the protocol. So, it’s evolving at a very rapid pace. So, one area that I’m definitely interested in is in AMP, you know our Atomic Multipath Payments, which creates packetized payment type, you know, protocol improvement.

Suheb: And, you can divvy up your large transactions divided into smaller payment packets, routed across different parts, and then, you know, bring it all together at the end. Improves privacy of the protocol, improves reliability of payments. That’s definitely one area where I’m pretty interested to see. You know, what’s happening, and how soon it can be brought to protocol. Then Sphinx Send is another important area, right? Where with you don’t, sort of create experiences that you, if you want to accept a payment, you have to generate an invoice, somebody pays their invoice. And, you know the kind of, it’s a little manual hand off process. With Sphinx Send you can make, push payments possible, that’s an amazing improvement, and it’ll improve the usability of the protocol.

Suheb: Splicing is another improvement which I’m very interested in, which will actually help improve fungibility between off chain and on chain, funds. It’ll add the ability for you to balance your channels without having to close existing channels. That will be another option for you to balance channels basically. And so, basically that’s another area we’re very interested to see what’s going to happen. Trampoline payments, is an improvement which is I think very critical for Lightning scaling. So, if you look at the way Lightning nodes currently are operated. So, each node is maintaining its own graph. It is building its own graph, and maintaining its own network graph. So, whenever I need to route a payment, my node has a view of the network. It looks at that network view, creates a network path for the payment to go.

Suheb: Now, as the size of the network increases, the size of the graph that each node needs to hold increases. And so, Trampoline payment is one solution on how you can scale your routing capability without having to completely have a view of a complete network. Right? So, that’s another area of improvement, which is very interesting to look forward to. And, it’s an important scaling solution also for Lightning. Watchtowers is another area where I’m very keen to see improvements, and it will help address security risks and, dishonest behavior, which is very critical for people to kind of have trust and, Lightning’s trustless solution. So, these are some of the high level Lightning focus areas, which I’m very keen on and kind of watching a bit closely. Once we have development on these areas, and once these ideas considerably mature, then we can say that, you know, I think it’s maybe less reckless.

Stephan Livera: Very nice. Yeah, I think there’s a lot coming there. So, Multi Part Payment, or AMP as well. I’ve got an episode coming very soon on that. So, watch out for that one with Sphinx Send. I think the Lightning guys are calling that Key Send now as well. So, that’s that one. There was a bit of chatter around that at the Lightning Conference. And, yeah, you mentioned a good one around Splicing. And, I think it’s interesting as well to think about Splicing versus looping out and in. So, you can think of, I was chatting with some of the guys and they were saying, Splicing is sort of like a spot injection of more, more capital. Whereas looping, is more like changing the balance inside that channel.

Suheb: Yeah.

Stephan Livera: And so, that’s an interesting thing to think about from a node operators perspective, where you have to think about, “Okay, do I actually want to resize this whole channel to be bigger, or do I want to instead vary the amount that’s already in there, and just keep that the same?” And, I think maybe another thing that might be interesting as well is reliability scoring, and, you know, Bos scoring as well.

Stephan Livera: So, that’s this idea of, you know, the longer you’ve had that channel, are you a more reliable channel partner? Do you have good uptime? And then, that also may influence who people set up a channel with, and where they try to route through, because there’s a better chance of the payment being successful if you’ve got good uptime. Whereas let’s say some guy, he’s like, his node is offline, 50% of the time, you don’t want to send the payment through him.

Suheb: Yeah. So, forward thinking a little bit, right? Routing node management is going to be a lot more automated than the manual. Right? And, parameters like Bos scores help us move in that direction. Right? So, typically if I’m operating a routing node, if i was a professional routing node operator, I’ll not be operating one node, right? I’ll be operating multiple nodes for instance, right? And, you cannot be looking at that node all the time to monitor all the parameters. What you need is some sort of a tracking mechanism, which provide your signals for manual intervention.

Suheb: You don’t need to watch things all the time, right? So, your channels are getting out of balance. So, create a signal or alert for a user to come and take an action, or suggest even, you know, go in further and suggest some action that you can do, Splicing, or you can do a Loop Out, right, whatever, right? So, these are the options available. So, the user can just make those financial decisions rather than, technically worrying about how do I do these operations, right?

Suheb: So, that is the kind of evolution that you will see in routing node operation. Routing node operation has to become much more automated than it is right now. We are just at this point picking up knowledge and information. All of this has to be encoded in algorithms which will automate, all your routing node operations.

Stephan Livera: So, I guess maybe just summarize your thinking in terms of what’s coming next with RTL. What should people look out for next? I think particularly as you mentioned those two dashboard, or those views that are coming for the merchant view, and the routing node operator view.

Suheb: Yeah, so basically at this point, we are focusing on completely enhanced, or improving the UX. So, initially what you have as RTL right now, is a product of a product manager, and a developer working together, without providing or giving it a lot of UX thought. The idea just, we just put our thoughts together, created a diagram, and started coding this application. So, we could get a minimum viable product. Now, we’ve got a reasonable traction with that product. And now, we are kind of bringing in more of a UX discipline, where we are now, you know, agonizing over each, and every small feature thinking whether the user needs to see this information. You know, whether these controls are meaningful here.

Suheb: So, we are kind of revising the complete UI. So, you’ll see a completely different user experience on RTL, and hopefully a better one with, you know, we have actually now we are collaborating with a person named Diego Sergio who is a UX expert, and who wanted to collaborate with us, on the UX side of things and he’s a UX expert. So, that’s one big area. So, you will see hopefully by the end of this year, a new release where we have a different persona based UX, where the dashboard will be different depending on the persona that the user has, or the user chooses. And, also the detailed screen, the detail pages will have a different UX than what you have right now. So, that’s one thing that we are working on.

Suheb: Second thing out of that will come as a Loop In and Loop Out integration. We are, LND is also very keen on having a UI solution in place. So, that is something that’ll be coming after the UX improvement. After that, we want to actually focus on node monitoring. Right? Like, what I said about automation, it’s something that I’m very keen on that, you know, whole routing node operation has to become more, and more automated. So, what are the tools available, what type of, you know, functionality we can provide, what type of alerting mechanism we can provide, so that we can kind of move in that direction where the user needs to do less manual work, and can get more alerts so that they can take intelligent decisions.

Stephan Livera: Yeah. Oh, one other thing just came to my mind now, mobile app? Have you thought about that or is it more just like have the web user interface work, on a mobile device?

Suheb: So, at this point, not an app per se, but yes, all the RTL interfaces will be responsive, so that if you’re opening the same app in a mobile interface, it will adjust to the resolution and give you a more optimized user experience, the same web experience basically.

Stephan Livera: Great. That’s awesome. Look, I think they’re the main points I had to ask from you. Maybe just tell the listeners where they can keep up and follow you online.

Suheb: Sure. So, there are two ways. One is you can find me on Twitter, my handle is @Suheb__ two underscores, and then, if you want to follow just the RTL development, you can follow us at @RTL_app. So, that’s another handle that you can use to find out any developments related to RTL. Happy to answer any questions.

Stephan Livera: That’s awesome. And, look, yeah, I’ve really enjoyed chatting with you and, yeah, it’s really exciting to see all the stuff that you’re doing really. I like using RTL myself, so it’s a great pleasure to chat with you. Thanks for joining me.

Suheb: Sure. Thanks a lot, Stephan, thanks for this opportunity. Thank you.