CD207: SETH FOR PRIVACY - RADAR - BITCOIN IN SIGNAL
Seth For Privacy joins to chat Radar, a new app that adds Bitcoin payments directly into Signal. We discuss forking Signal while keeping full account and chat compatibility, why they built on Signal’s network instead of Nostr or SimpleX, donating back to Signal Foundation, and how end-to-end encryption keeps payments invisible even to Signal. Then we go deep on the tech: Spark versus Ark trust models, unilateral exit, privacy tradeoffs, Lightning interoperability, seed backups tied to your Signal account, stable balances, on and off ramps, and the goal of bringing Bitcoin to everyday chat users.
Radar: https://radar.chat
Radar on X: https://x.com/RadarChat
Radar on Nostr: https://primal.net/p/nprofile1qqs8638xpknd8muv3ju4sjyc2m47z4s20ssg06z0kr3a7pjs0v7qmlqvu8s4h
Seth on X: https://x.com/sethforprivacy
EPISODE: 207
BLOCK: 957218
PRICE: 1608 sats per dollar
more info on the show: https://citadeldispatch.com
learn more about me: https://odell.xyz
monitor the situation: https://citadelwire.com
ten31: https://ten31.xyz
opensats: https://opensats.org
Happy Bitcoin Wednesday, freaks. It's your host, Odell, here for another Seal Dispatch,
the show focused
on actual Bitcoin and Freedom Tech discussion.
Got a great show lined up for you freaks. But before we get there real quick, the current
time
is Wednesday, July 8 at nineteen forty UTC.
You guys will be listening to this in a couple hours. Just do a quick cleanup.
No edit. In Bitcoin time, the current block height is nine five seven two one eight. The current price is $62,190,
and the stats per dollar is 1,608
stats per dollar. Kind of a weird weird climate there on the Bitcoin price side, but Bitcoin is incredibly interesting. The fundamentals remain bullish as ever,
And we keep grinding, we keep grinding freaks as always dispatch,
no Azure sponsors.
I only do shows when I think it'll be interesting to you guys,
not beholden to the
schedule of a sponsor that wants three shows a week or whatnot and fills your feed with noise.
But that means that is supported purely by viewers like you with Bitcoin donations.
All relevant links are still dispatch.com
for that.
Our top two Zaps of last week
were
ride or die freak, Mav twenty one with 10,000 sats. He said great rip. And PGS design
also with 10,000 sats said killing it exclamation point.
Thank you, freaks, for supporting the show. As always, if you can't spare your scarce sats,
I know money's tight right now. I know we're all poor as hell.
Share with your friends and family. Open up your friends app,
podcast app, search civil dispatch, press the subscribe button. They won't know what hit them. They'll just get pure signal delivered directly into their phone.
And then they'll either hate me or love me. So do that for the show. Thank you, guys. Anyway, freaks, I got a return guest. Good friend here.
Not talking about oh, we are talking about Bitcoin today. We have Seth for privacy here. How's it going, Seth? It is good to be back, man. It's been a been a week. The highs, the lows. It's been good. What's your official title at Cakewallet COO? Chief operating officer?
Yep.
Yeah. Chief operating officer at CakeWallet.
They got a new app out that is a different company, but similar team called
Radar.
What is Radar?
Indeed. Yeah. So we we have kicked off a completely new thing, shifted focus.
Cake Wallet obviously remains
the focus of Cake Wallet and the Cake Wallet team. Leadership team is the same, but the actual team building that will be different. Just initially to get RADAR off the ground, we built it with the the same team that's already been been killing it at Cake Wallet. The radar
like, the the idea is quite straightforward.
We just always kind of accepted that
when we want to message somebody
privately that lives in one place, when we wanna send SATs, when we wanna send Bitcoin, when we're gonna send any amount of money, we have to go outside of that to send it, or we have to rely on some trusted third party. Like, we're using a Facebook Messenger and Facebook Pay or we're using WeChat and WePay or all of these different options that Are you a WeChat user?
I'm not. No. Not.
I've had
I've had the reason to get on there, and I have avoided it like the plague so far. So I'm I'm trying to trying to stay out of it as best I can these days. But, yeah, the the goal is really unifying those things,
bringing the conversations you already have into a world where you can send Bitcoin to those people that you already connect with. So radar is built on top of signals protocol and its network.
So your contacts actually come with you. All your chats come with you. Your account comes with your username, etcetera.
But anybody who joins RADAR as well, you get to send and receive Bitcoin back and forth seamlessly at a tap instant.
It's really kinda stupid simple in execution,
but the the vision and the goal is getting this far far beyond the the regular Bitcoin wallet user.
Okay. So high level,
first of all,
I've been testing radar for a few weeks now.
I love I I mean, look, I love signal. Signal is I run most of my personal and professional life through signal. 99% of my communications is through signal.
It's got really strong privacy and security guarantees, but also has a very good UX. It's relatively easy to use as a freaks know in the past. I often brag about the fact that my 90 year old grandmother uses Signal because she can it's the only way she gets baby photos. So I feel like that's a pretty high bar for a Freedom focused
app to to be able to support 90 year old
grandmothers.
That is incredibly rare. Also signal has a 100,000,000 users as far as freedom focused apps go, probably
one of the best adoption stories we've ever seen. So signals also my obviously love Bitcoin.
So this is a combination of the two of those
signal. The app itself is open source. So effectively, what you guys did was you took the open source app and
then you forked it and you added a Bitcoin wallet into it. Correct?
Yeah. I mean, it's it's really funny because for anybody who remembers that Signal have their own cryptocurrency that they launched, like, six years ago called Yeah.
I think they've
they've backed away from that quite a bit over the years. There's almost like no mention of it. You can't find it anywhere. There's it's not on any exchanges
basically anymore.
But it was their attempt at solving this problem, and they did it in a way that was Monero like privacy,
but did sync
in a way that relied on Intel SGX
to preserve user privacy. It was interesting technologically,
but launching a new cryptocurrency to do it obviously has a lot of drawbacks as well. It basically just never got off the ground. But the nice thing about that is that all of the underlying building blocks, like in the messaging protocol and signal to actually send and receive payments,
but do it through the intent encrypted signal protocol,
it's all still there. Even if they're not using it, all of the underlying technology that you need to to use
Bitcoin in signal is all there and functional today.
So it actually wasn't even as hard as we expected. I I think there had been some proof of this with the whole Bitcoin for signal campaign that happened. Was maybe eighteen months ago, which was more driven around e cash and signal, and that was never gonna happen. But the building blocks were already there. How is that never going to happen?
I'll I'll reply with the same line that I I dropped a meme to Calais, and then he blocked me forever after that, which is who who's he was gonna run the Mets.
SIGNAL cannot run the Mets. They're they're already
in such a regulatory,
like, rock and a hard place all the time, fighting chat control and all of the EU stuff. There's just constant battles that they're fighting.
If they then touch any user money,
it becomes a
a huge nightmare for them from a regulatory perspective. So they don't wanna be the custodian, but who do they trust to be the custodian running an eCachement?
Would they trust a random federation? Are they gonna choose a federation, and they're gonna have some business agreement with them? Like, how exactly would that work? ECache specifically, I don't think they would be open to. Maybe they'd be open to something like Sparker Arc, which would be interesting, and that's kind of the part of the exploration that'll happen now with radar is there's nothing that we've done that they couldn't also do.
And something that could be a fun after effect of radar would be that they just end up doing Bitcoin on signal for all of their users and ruin our unique selling point, but bring Bitcoin to
100 plus million monthly active users immediately as well.
Yeah. I mean, I think that would be awesome. I mean, before we jump into the Bitcoin piece
Mhmm. I just wanna be really clear to users, potential users here.
The whole point of radar is
that is it it's a drop in replacement for signal. You will have all the similar functionality that you already have in signal. It uses the same signal backup process
and network. So that's why it requires a phone number because signal still to this day requires a phone number. And so if you install radar and already have a Signal account and set it up, it replaces your existing Signal instance. It's a complete drop and replacement.
For the record, for what it's worth, because so much of my life revolves around using signal as a tool. And it's such an incredibly important tool for me.
When I've been testing it, I've been testing it with a burner number for that reason.
That it's not like I have all my eggs in this one beta
project. I mean, now it's out and released. But at the time, was
texting me being like, can you test this thing? And I didn't, I didn't want to risk it. So keep that in mind. I know some people
are confused why that is the case. They wish it wasn't that way. But that's the whole point. The whole point. The reason I mean, I saw Seth got some commentary about why didn't he use Noster.
I don't think Noster is a good fit here. I think a better question is why he didn't use simplex or something that is like a more open protocol that doesn't require phone numbers.
The answer
isn't even really worth asking stuff because the answer is that they wanted the 100,000,000 users. The whole point was that you kinda have this drop and replace you have this drop and replacement that automatically gets the network effect. You're not competing against the network effect. Am I correct on that?
Yeah. Pretty much. I mean, there are there are other reasons too, and that I do like a lot of the approaches taken in the signal protocol and signal architecture.
Not necessarily more than Simplex or others, but when the target is
the average individual and not the hardcore Bitcoiner as, like, the end goal of who we're reaching with this product,
I think it it needs to be something closer to signal than something like
simplex or something like white noise.
Things that have more hardcore features White noise is not even usable, and there's also no network effect. Yeah. Simplex,
I think there's there I think there could be some argument to having a simple x client that has a Bitcoin wallet built in. They have many more users than Nostr. Yep. I happen to know their user numbers. And
but, yeah, I still this makes sense to me because, like I said before, I mean, it's a 100,000,000 users. You already have you already have the network. But on that point, by the way, Seth, my biggest
issue right now, and I know
it's publicly out there, but you guys are obviously gonna make iterative improvements.
Like, the cool part here as opposed to me just pasting a lightning address into a group chat
Mhmm. Or a lightning invoice or a Bitcoin address or something is that it's all built into the interface. Like, I can just seamlessly pay. There
is a bit of confusion in the interface
on which users
are
like, regular signal users versus radar users? Like, obviously,
at the beginning, 99% of my address book or my signal contacts are going to be regular signal users.
Mhmm. How do you think about that UX of who can I pay and who can't I pay?
You know what mean? Yeah. It's a
good question. We've definitely been thinking about that. I mean, right now, basically, just if you're in a chat with a regular signal user and you hit the the Bitcoin button that is for payments, it'll just say that that user hasn't activated payments yet. Yeah. But then it asks me to send a payment or, like, activation
notification.
I because I've tested this out with my other Signal account.
And then the other person's getting, like, this weird thing that doesn't do anything. Yeah. That they can actually activate. Yeah. Yeah. That's one of the downsides of under the hood using Signal's approach because it it to other Signal clients, it just looks like a regular payments request that would use MobileCoin.
To Radar, obviously, it understands that it is is Lightning. So some work that we're going to do around that is to
to make it clearer, automatically disable it within chats that the other user doesn't actually have doesn't actually have Radar.
And then, like, when you go to the payments tab and you hit send to automatically,
like,
down select the contacts you can choose to only ones that actually your phone knows you can pay. So ones that you know are using radar and you you have the right payment info that you need to be able to pay them. So I think there's some simple fixes that we can do there. Out of the gate, the goal was really just getting the payments itself nailed down, but that is good call out that we need to make it clear when that person is someone that you can't pay. Because that's that is the downside of importing someone else's network effect is you have users on a different client. So they can't they can't do the same thing to.
Overwhelming number of users is on a different client. Right? Yeah. Yeah.
Okay. Yeah. I wanna keep I wanna go down the signal hole a little bit, and then we'll move into the Bitcoin payments piece.
Part of why signal has been successful is because they have a very, I would say pragmatic trade off model.
People are upset about phone numbers, but they use it for spam mitigation and network effect because phone numbers are
the established network effect that the giants like Telegram and WhatsApp have used to scale to billions. So we already have the phone number piece that just comes with the territory. You got to use it. But the other piece is the apps are open source, but they control the servers. So there's a lot of concern out there. And I think it was my first question to you privately.
How are you thinking about
that basically? I mean, are, you're effective. You didn't have to ask permission for forking the app, but you kind of have to ask permission to continuously connect to their servers. Am I right?
I mean, not ask permission as much as
hope they don't choose to be.
They can block you, I guess, is my question. Right? Yeah. I mean, there's nothing like legally, there's nothing they can do to radar the company. What they can do is they can try to block radar user agents when your app tries to connect to their servers to to get messages,
to get contacts, all of that fun stuff. That is something that they can definitely do. So it's not as much asking permission as much as like they shouldn't
block that as long as we're not doing something to happen in terms
of service. They have, but only in
the long term past, more when Moxie was there, and he was very anti alternate client. And the most popular alt client for the past
at least five years, Molly, has been around and has not had any issues with them so far. I think the main thing they've been sticklers on lately
are like brand usage. So obviously, we've been careful about that to make sure that we're not we're not doing anything that could be misconstrued as like random personation or whatever. But like you said, the the apps are open source. The protocol is open.
It should be something that's usable long term. But that is the one clear downside of Signal's network is it is a centralized infrastructure, and that does give them the benefit if they can cut off bad actors. If they have someone who's built an alternate client that tries to work around spam prevention and is actually doing something malicious that breaks terms of service, it's a good thing that they can block them. Obviously, it's someone just building a client that's doing something they don't like, even if it's not against the terms of service and it's not unethical or wrong, obviously, that would be a different thing. But I'm definitely hopeful that they'll be
open to this. I mean, part of it is we're we've already donated to them and we're planning on ramping up donations as we grow in users and and profitability over the coming months and years. Like, this isn't something where we want to be vampiric and just kinda like sucking the the the lifeblood out of Signal Foundation. Like, we very much understand
how what they've built is the reason that we can build RADAR and make it really useful, and how our users do cost them something. So we wanna obviously continue to make sure that they can they can grow and fund, and hopefully, it should be a rising tide that lifts all boats. But, yeah, there's no there's no way for us to prevent them from blocking radar users if they really wanted to.
And then we'd we'd get to go back to the drawing board, which would be kind of fun because then we could do things our own way. But
That makes sense to me. I mean, I do like just the general concept of
building on an open protocol that's maintained by a nonprofit
and then donating a portion of profits back upstream.
It's a very sustainable revenue model for the nonprofit itself and the open protocol itself,
or I guess open protocol itself.
The
Do you feel like that's kind of how this thing should work? Is like Yeah.
The protocol should always be owned by an open source foundation because the protocol has to remain something that's very neutral.
Yeah.
Or nobody like Bitcoin.
But even when you think about like who's building on Bitcoin or who's helping to maintain Bitcoin, they're almost all funded by open nonprofit
organizations like OpenSats.
Like, they're they're being funded by
not for profit entities. And that's a really good thing when you're doing protocol work that has to be very neutral and has to cater to a broad audience.
But when you're building on top of that, that's when it you really should be giving back in some way. And that's where it's been interesting to see like who is willing to donate as a as a for profit company building around Bitcoin, who's willing to donate back to the OpenSats, to the Brink's, to to all of these,
or who is just building on top of it and benefiting and not willing to give anything back. And I see the same thing. I could see that playing out with this, with Signal.
I could see it playing out with Simplex as well, because I know the foundation for the protocol is going to be nonprofit,
but then for the actual app is going to be for profit, if I understand it correctly. Correct. I think it's a it's a good model because it it says the protocol remains something anyone can use. We're going to build a profitable business around the specific interface that a user uses and compete in that space while remaining open source.
Open source and for profit can go together really, really beautifully. So I think it can be a very good sustainable model that that benefits everyone in the long run. Does that answer one question with Signal is how how will they be
sustainable in the long term if they're purely relying on donations or maybe this backup subscription that they're doing will be profitable, but there hasn't been a clear path towards that and they've been operate operating in the red for a long time now. So it'll be interesting to see.
Do you know
okay. Let's say I import my
my main into radar
and signal bands
the app.
Am I able to gracefully move back or am I just shit out of luck?
No. You'd I mean, you'd definitely be able to move back. Yeah. The nice thing is because we're still completely using the signal network and protocol.
Like, let's say
like, I've been using radar for my primary signal now for
three, four months at at least.
Because I have a personal one that I use for friends and family, a personal signal account, and then I have a public one that I use for business and and everything else.
And so I've always had to have a second signal app, which has kind of been a pain in the butt otherwise on iOS.
So I've usually used Graphene for my public one and then iOS for that.
If I like decide not to use RADAR or I go back to signal, you can just export a backup from RADAR and go back to SIGNAL. The account Even is completely
if the app gets banned. Right? Because they would just be banning the
the actual network connections for that app. But when you went and logged in from the official SIGNAL app, it wouldn't be
filtered at all. I mean, I But I mean, like, chat history and stuff, not Yeah. Chat history. Because that's all that's all local. It's all in an encrypted client side. So, as long as you can export that from the radar app. Because they can't mean, they can't ban the app itself. Like, they Right. They couldn't remove it from your phone. What they could do is make it so that the app can't communicate with signal servers.
But then you could just take it back up, pull that out, import it into signal, and move on. The I mean, the other thing, like, obviously, if that happened,
we would push an app update that simplified the migration process back to signal for users. Like, we would make that graceful. Because again, they're not gonna be able to take down our app from the App Store or
remove it from your phone. So we would make it as seamless as possible if that were to happen. But no, your account can definitely migrate. I mean, case, you've maybe you couldn't recover your chat messages for some weird reason.
But you'd still have the account, and you could still get back into everything. But, yeah, it should it would be quite quite portable and easy to move back and forth, and you already can do that today.
Makes sense.
Okay.
Kind of a tangent. Were talking about
not using the signal branding.
Mhmm. Why radar?
There's not like a crazy story behind the name. We went back and forth on a lot of different options
and
just really wanted something that was, like, memorable,
but optimistic,
easy to say in other languages. It's a palindrome, which is always a win when you're naming something. Same forwards and backwards.
And it it let us do some really fun things with iconography
and,
like, visual design. Like, you'll notice throughout,
obviously, the icon itself. But if you go to the website, radar.chat,
like, you'll see that we use the kind of the radar
sweeping motif,
pings, that kind of thing all throughout. So it's more that it's a fun brand. I mean, similar to cake, like,
cake wallet. Obviously, cake isn't doesn't mean anything for the cake. It's just it's just supposed to be fun, and it was it was created in the days when everything was a weird, like, bread wallet or bake wallet or all these stupid names. And the same is kind of a a an approach we're taking to to radar. We we didn't want it to be this, like,
super crypto anarchist,
dark undertones feeling
app or brand.
We very much wanted it to feel optimistic and like a place where you could just do, like, everyday stuff. It's not just about being a super super shadowy hacker or something. It's something that's for for average people. Because like I said, like, the the vision for this is not that it's just another Bitcoin wallet or that it's not just the hardcore signal client. The vision is that people who just already want to use
signal,
they also want to send and receive money directly in it. And we can make that easier than it would be otherwise by using Bitcoin under the hood. We can make that easier to on ramp and off ramp. We can make that easier to actually send and receive those payments,
and not require them to give up ID or other things like that. But yeah.
I feel like I have to mention. I like the name Radar. I think
it's clean, it's catchy, easy to remember. The domain's easy. Radar.chats,
good domain, the branding school, but someone did
reply to one of my posts about it. And I was like, are you telling me they named it after the technology that enables people to track and locate you?
It's you know, it is what it is. I mean, if if you're a plane or a ship. Yeah. I'm not sure. I'm not sure radar is used to track individual people. Maybe he means stingray or something, but
it's true. I was actually thinking about that. There was a If you're There's another app that
I think he works at Ocean. I'm blanking on his name right now, but he made something called Sonar
and just released it, like,
two or three weeks ago. So we're obviously keeping an eye on it as we're prepping for radar launch. He released it called Sonar. He has a lot of the same, like, visual motifs that we already had lined up. But his is bit chat based. So he built it around bit chat and then used the liquid Oh, it's also a chat. It's also a chat app too. Yeah. Yeah. But it's it's meant more for the Bluetooth mesh plus the the
ability to go over the Internet via Noster.
So, again, a more hardcore use case, but I thought that was funny and, like, the
the fittingness of sonar being something you use underwater
when you're in stealth mode and more like the shadowy side, and it's the thing that's using Noster and BitChat, and then where radar or the thing that's scanning above ground and looking for things up, like looking up is is an interesting
it fit well together even though we were just building in parallel and had had no idea that that was that was coming out.
Fair enough. Okay. Bitcoin.
One of my critiques I I love cake while I think cake while it's great. I've gotten some
I don't know. I love cake wallet. I think it's awesome. My biggest issue,
and I think it's one of the better Bitcoin mobile wallets out there. You guys are always trying to support the latest and greatest tech, particularly on the privacy side, but probably one of the biggest critiques of cake wallet is
that it's got so many different features
that
is quite complicated.
Or maybe complicated is the wrong word, but there's a lot of things going on in Cakewallet. Not only
because you guys support a bunch of shit coins on cake, but also because even on the Bitcoin side, there's a lot of things going on on the Bitcoin side.
I've noticed with radar, you went much simpler
and specifically,
it's just one wallet, one type of wallet, and you chose Spark
as the back end for that with a lightning focus.
Can we like, what is the thought process there? How are you guys thinking about that? Yeah. I mean, a lot a lot of it goes back to the the target user that I mentioned earlier. Like,
we I don't want this to be another wallet. Like, I mean, in building cake wallet, like, we've seen massive growth. I think there's still tons and tons of room for growth, but just kind of game planning out, like, how many people in the world actually want a cryptocurrency wallet,
a Bitcoin wallet that does all of these things and that they're going to use in daily life versus how many people
are already chatting and they want a way to be able to send value easily. And I think there's this
there's this, like, common feeling when you've been in the Bitcoin space for a long time of, like, I gotta, like, jam Bitcoin into everything. You're finally, how am I gonna get Bitcoin out there and
make everything about Bitcoin rather than figuring out, like, where does Bitcoin just solve something regular people need,
and we can kind of Trojan horse it into their lives.
And that's more how I view radar. So I think for radar, like, the long term, I don't
I would be very happy if we got to a place where the majority of our users were not
Bitcoiners in the sense that they weren't necessarily
coming to radar because they're already stacking SATs, so they already have a hardware wallet or whatever.
But rather, they're people who are just there because friends and family are there, and they want that ability to send and receive value. And the fact that they're using Bitcoin under the hood access kind of an orange pill moment for them where they they can wake up to that, and then they realize,
like, this is super cool how easy this is, the accountless nature, like, the fact that I don't have to do anything for this. I don't have to create email address, like, the the simplicity of the actual value transfer here and win them over that way.
That's a lot more of the vision here. So, like, for me, it's not it's not as much about building out the bells and whistles when it comes to what Bitcoin can possibly do in radar. Like, that's
that's why KQuality exists. We can do the more complex stuff, the silent payments, the pay joins, the the fancy things there for the more advanced users.
And radar is more about how do we do the the bare minimum and make it as stupid simple as possible, where it literally is just in a chat, tap the Bitcoin logo, enter an amount, enter a comment if you want, and hit send. And that's all you need to do to send Bitcoin.
And and specifically here, I mean, Cakewallet has hardware wallet support. It was built out with on chain focus. It has silent payments for on chain if you want.
This offers none of that. I mean, it's this is purely Lightning only. Was that a deliberate decision?
Or
Yeah.
Yeah.
It was definitely a deliberate decision. I mean, it's it's kind of the same question that I expected to get a lot more from Monero people
of, like, why not Monero under the hood when looking at this. But it's it's the same as even, like, on chain Bitcoin or more of some of the more complex Bitcoin stuff where
to make this something that's tenable for a regular person,
the user experience has to be,
like, almost
entirely frictionless.
And even on chain Bitcoin,
while it can be simple in how it works,
the timing constraints and other things are they don't feel good when you're using something like a messenger. Now, you could just assume zero conf and
obviously, there are some ways to kind of pretend that
that it's fine.
But the the reason for being Lightning only, like you mentioned, it's using Spark. Normally, it is Spark to Spark payments, but can make Lightning payments internally and externally. Well, for, yeah, deposits and withdrawals or if you're out of Square merchant or something.
Yeah. But I noticed, like, Spark supports
sending and receiving on chain, and I noticed you guys have that disabled. You're just doing Lightning only.
So you you do have the ability to receive on chain. We wanted to keep that for deposits, especially because for those users who are more hardcore, the best trust model in Spark comes and you deposit funds from on chain into Spark. So you can do that. If you go to receive or the add funds, and then you can shoot switch the toggle to on chain. That is possible. Sending yeah. We're only focusing on Lightning. Again, because it like, this isn't
this isn't a wallet. That's not it's not the the goal here
that you would be using this for
lots of external Bitcoin only kind of things.
The goal here is that you need a way to get money in,
and you need a way to send and receive money within the system, and it needs to be very frictionless.
And because Lightning has become the interoperability layer,
all we really need to be to allow those users to interface with anyone else in the Bitcoin space is Lightning. And so that has greatly simplified things where we can use Spark under the hood, which gives us the simplicity,
super fast, super easy, super cheap, and then Lightning whenever we need interoperability.
And then potentially some other things down the line in terms of stable balances. But, yeah, that it I think it needed to be stupid simple in terms of how we approached it, and it was very intentional.
Why did you choose Spark as the back end?
Pretty I mean, pretty much the same reasons as cake. I know we talked about this a bit on on CD before when we chatted last, but
the primary reason is still that the UX on Spark is slightly better than ARC
for the same trust model.
And then the secondary reason is that
stablecoins on Spark, I think, will be a particularly good fit for Radar.
Again, when we're talking normal people, they probably would want a stable balance over a volatile Bitcoin balance, but we want the ability to give the option for both and let people move between the two at a tap as well. So Spark does enable that in a way that
Arcade technically could allow. Second, won't allow right now on the Arc side. Those are the primary two reasons.
I know that there's like, there's always backlash from hardcore Bitcoiners on some of the drawbacks within Spark, but they're almost never compared evenly with the drawbacks on Arc. And so, again, when when doing the the research on this, it seemed like the right fit to continue using Spark, which we're already comfortable with. I think Arc's getting there. I I could see a world where
this could work really well on Arcade maybe in six months or something like that, but we also didn't wanna wait to to launch this until then with the target demographic not being the hardcore Bitcoin user and us being comfortable with the trust trade offs and the trust model of Spark compared to what Arc is today at least.
I mean, I know you
have done a
bigger deep dive on the trade off models of Spark and Arc specifically
in implementing them in product than most people have. I mean, to the point where
I mean, you asked you mentioned the simplex foundation
earlier.
I mean, after I had Evgeny on the founder of simplex, he asked me to be one of the founding board members of the simplex foundation.
And when I was talking to him about potential Bitcoin integration,
I literally sent him your
your write up on the two of them. It's like the
it's the write up to read at least at first when you're first diving in. But
I mean, I'm more
I have a better understanding of the trust model of Spark. Is it really my understanding is that the ARC trust model is
requires
less trust in the operator than Spark. Is that not the case?
It's not the case for the average user. The the complication is because Arc's best case trust model is better than Sparks.
In Arc,
because you have the ability to join around and get finality to get the guarantee that no one else can spend can double spend funds,
It's it looks better on paper,
but the problem is the actual process of joining rounds
is not something that most users, at least in this type of target demographic, a mobile only user who doesn't have an always online server.
It's not something that most of those people are going to do.
I do see this in both the the arcade and the second approaches,
where they're using delegates or Hark signers where they're they're essentially offloading
the VTXO refresh,
but they can't actually get finality for their users.
Because the the process actually joining around just like, I mean, Samurai Wallet,
why didn't they launch Whirlpool on iOS?
Because background
coin join on iOS is essentially impossible. Because of the constraints that Apple applies. Unless you can force a user to open the app regularly,
you can't guarantee any execution time in the background. And so the the hardcore,
like, the the best case security model in ARC will not be something that regular mobile only users can achieve. And so you fall back to the the basic security model, which in ARC is
essentially a one of one trust model because the ARC service provider is the only one who has to do something
to double spend funds. In the Spark
trust model, it's right now, one of three will be more as they add more Spark operators,
where if any of those operators are honest,
your funds cannot be stolen.
Do so is the three operators public?
Yeah. Yeah. It's it's
Lightspark,
FlashNet,
who is David Marcus. His son. Yeah. It's his son. Yeah.
And then Breeze is the third one. So we waited until was the third one. Roy is not related to Marcus's. He is not. No. He's not. Yeah. That was like
that's the biggest thing for me that often gets lost in the shuffle, like, explaining all the technicalities is if you use ARC in the most hardcore way, it is absolutely a better trust model than Spark.
When you're talking mobile only, that trust model is basically never achievable unless we got covenants in Bitcoin.
And because of that, you fall back to the base level security model where,
at least to me, and I haven't seen anybody refute this, Spark's trust model is slightly better, but you also get a better UX because you don't have to worry about VTXO expiry.
You don't have to worry about delegating that refresh off to someone else. It's a much simpler
dev experience at the same time.
And I I can say this as somebody who, like, I was really hardcore about Arc, and specifically, I really wanted us to do Arcade
before I did the deep dive.
Because I, like, ideologically,
I align much more with the with the Arc folks. I love the guys at second. But when you actually dig into what it looks like for a real user,
the trust models are at worst the same. At best, Spark is actually a little bit better for the average mobile only user. I mean, that's from a security point of view. What about from a privacy point of view?
They're both
equally.
The operator still is seeing
all your transactions basically. Right?
Yeah. In theory, both could provide good privacy
even from the operator.
In practice, neither do right now. So right now, both have the same trust assumption, which is basically,
I have good privacy from outside observers as long as the operator does not publish my transaction
details.
But the operator sees your transaction graph. Yeah. Yeah. Because in both Arc and Spark, you're cosigning transactions with the operator. So they they necessarily see all of the transaction details in every transaction that happens within them. Whether or not they choose to publish it is really the only privacy toggle that you have within both systems.
Within Spark now, that's been the default in K Wallet from the day we launched. We obviously weren't gonna launch without disabling that transaction
being shared with the world.
And then
I can't remember where Arcade and Second landed. I believe Second art publishing transaction data, and I believe Arcade are publishing transaction data, but it's just up to up to each of them what they do. So What about so you're trusting the operator with your transaction graph. Are they are they trust is a user trusting
mean, I I it sounds like the implementation is the same. Are there's a user trusting cake or
a radar operate operators with the transaction graph too? Or is it just
the spark operators?
No. And this one of the nice things and, like, why I
kind of like that we're not running the messaging infrastructure or the payments infrastructure is there is no
single party who has insight into
either side.
So, like, Signal, obviously, they would know your phone number, potentially your username.
They don't know anything about your contacts or your messages. Yay. Intent encryption. Spark, the the entity,
would know that there are some transactions happening.
They don't know that they're even related to radar or Signal, and they have no way to tie them to your phone number or to your username or anything like that. So you'll see there's already done some tweets that are like, why would you tie your phone number to your your transaction details? That's just not simply not how this works. Neither signal nor Lightspark can can say this phone number is sending these transactions. They're not in any way tied to that. And because of an encryption in the Signal protocol,
Signal has absolutely zero visibility into this. They don't even know that there's payments happening, much less that they are
payments over Bitcoin and not mobile coin or something else, which is an awesome piece of this is because of the great intent encryption they've built. We can we can build Bitcoin into their system in a way that they still don't get visibility into, which is good for them and good for users.
Awesome. I mean, on that note, saw someone commenting on the differences between the signal privacy policy and the radar policy privacy policy.
How should users think about that?
Yeah. I need to I noticed there were a couple things that weren't
quite correct in our privacy policy, so I need to tweak it a little bit because it's still it it mentioned some things about, like, running your own node and stuff that
were just a a thing that we must have caught in our last review pass. So Like a leftover from Kick Wallet? Yeah.
Yeah. Because, obviously, some of the privacy policy is still the same, but it's not exactly the same. So I do need to clean that up a little bit as well. So I'll be reviewing that. But,
basically, the I mean, the the TLDR for any users at Radar, we don't get any analytics on your usage unless you choose to submit debug logs and send them to our support, which you would be choosing to do that. We don't get any information about your payments,
only the Spark entity and Spark operators have any visibility into that. And we don't get any information about your
messages.
We never see your IP. We never have any visibility into that. That's actually much less exposure than you would have with Cakewallet. Like with Cakewallet, obviously, normally, we're running the the node infrastructure for using Bitcoin on chain or Monero or whatever. So theoretically, we would see your IP, and we could see which transactions are broadcast from which IP address. Obviously, we don't log those or anything like that, but we could have more insight from the KQL perspective. Radar, we have even less there. So, it's very limited. And basically, you should go look at the signal privacy policy if you wanna see more about the messaging stuff and then look at ours to focus more on the payment side.
Makes sense. So
on the payment side, obviously, you have
user to user payments, which has a very clean UX. I think you guys did a really good job with that. There's now there's a Bitcoin wallet tab effectively on the bottom
for you to see your wallet and, like, your transaction history there. For external payments, you give users the ability
to create a lightning address at radar dot cash, which is separate from your signal username. That's a completely different username and namespace.
And then there's a separate backup
scheme, which is effectively a seed,
which presumably
a user could export and import into any other Spark wallet.
I guess my question is,
is that Lightning address
tied to the Signal account or is it tied to
the seed backup?
It's tied to the seed. So if you if you do have like a a custom one that you love, you need to make sure that you back up the seed just in case. One one thing to make clear here is, and I think it's a a really good product decision that people should be aware of is this your seed actually gets backed up to your signal account encrypted.
So signal themselves can't access it. But as long as you can restore your signal account into radar, you get all your funds back. You don't have to have the seed phrase. Oh, that's nice. Which the trust model there just to me makes a ton of sense. If somebody has your Signal account, that also means they have your phone number
access to your phone number, and they know your PIN code. You have bigger problems at that point than the 50,000 sats or whatever that you have in radar. It's a spending wallet. Yeah. It's a spending wallet. And you already have good protections on the Signal account itself.
So you don't normally need to back up your seed phrase. Really, it's just an extra escape hatch just in case in case something gets messed up or
who knows if Signal freaks out and and you delete your app, you would still have the ability to recover funds. It's really just a fail safe. So you can back up that 12 word seed phrase. And like you said, you can import it into any any smart compatible wallet, cake wallet, etcetera. They'd all work. And that's one of the really nice things about these open standards is you're not at all locked into radar. You could leave at any time with that seed phrase and have your funds come with you. But, yeah, for most people, you don't even need to worry about that, but it's it's always there and available, and you'll get a prompt to do it once you receive funds for the first time.
Awesome. Yeah. So is that backup that backup separate from encrypted chat backups?
Yeah. Yeah. It's it's only the payment side.
Obviously, on Yeah. The Go on. The chat backup side, like, we're just doing the normal signal stuff right now. Is that powered by signal? Like, it popped up on my app, like, encrypted
radar chat backups,
which I think is a paid feature on signal regular.
They have a free tier and a paid tier. So just using their free tier? Yeah. So you can do the free tier and keep using that. That's one of the reasons why we wanted to start donating to signal before we even launched because, obviously, if people are using the free tier quite often, then technically, they're costing signal, and we don't we don't want to add any cost burden to signal. We wanna make them more sustainable. You can't do the pro tier in radar because for some reason, they've locked pro tier payments
to their app bundle ID. So if you you can't no alternate client can do the pro What if you pay for pro tier in the regular Signal app and then migrate over? Does it carry over? No?
Nope. Okay. No. It's basically like a license check failure if you try to do that, which is is odd. I don't know why they why they chose that because,
like, very intentionally, all the donations,
links, everything in the app, they go to Signal. Like, we don't want you donating to us. We would love for that pro paid backup plan to continue going to Signal. But the way that they've done it, there's it's a server side lock that you can only do it from the the app bundle ID that that Signal itself has. So that won't work today.
I mean, there's some really simple ways to replace that. Like, we're already doing obviously, you have a private key, you have a recovery key.
You could just do the backups in iCloud Drive and Google Drive. They're encrypted.
It doesn't really matter where they're going, and we can do that for free. And every user who's an Apple or Google user has some storage space, and this requires very little. So quite likely, we'll just do something simple like that and make sure it's encrypted well, obviously, before it's dumped into iCloud Drive or
or Google Drive. But we'll see long term about that. Obviously, we wanna retain compatibility as much as we can with Signal over the long run, while also theoretically making this a little bit more portable, a little less locked down compared to Signals.
Makes sense. I'm kinda pulling us back a tiny bit on the Spark
trade offs because I forgot to bring it up. Grubles, who now works at second,
which is one of the two main ARC implementations,
has been mentioning concerns over Spark's unilateral exit.
This idea that a user, if
can leave the system if without Spark's permission.
Obviously, it's it's not unilateral exit does not there's no flow for it in, I believe, radar or cake wallet. How do you think about that?
Yeah. I mean, it's it's obviously something that we want to have. It hasn't existed in the Spark SDK, and that's the Breeze SDK yet.
So that's the main thing that we've been waiting on.
It does exist as a separate CLI app. So if
if Spark were to suddenly say, like, x user can no longer transact within Spark, you can go to the c a CLI app,
and it will work to let you exit with your funds. The one call out that Google's made, which was a good call out, is that that still relies on you being able to reach the Spark server, one of the Spark operators. You don't have to reach all of them. Specifically, you wouldn't have to, like if
let's say LightSpark and FlashNet were censoring you but not Breeze, you could still use this Breeze Spark operator to recover your leap state. But you you basically, you need the information about your leaves, basically, like the the UTXOs of Spark
to be able to make that unilateral exit.
And those aren't cached locally in in any wallet today. So that's the one dependency that exists right now.
There's already a draft PR that's being worked on around unilateral exit being added into the Breeze SDK, which then would just be immediately available within
Radar and Cake Wallet. It's definitely a shortcoming. Quite honestly, I've been very frustrated that it has taken a lot longer than I was told originally.
And not
not to throw Breeze or Spark under the bus, but that was one thing that I was expecting to be live
by the time that we went live with Lightning and Cake, and we're now four months past that and it's still not live. So obviously, I've been pressuring them behind the scenes to get that in because that is the last big
trust model drawback. Like I said, you still can unilaterally exit today with the CLI tool. But obviously, the best case scenario would be that you can do it directly in the app you're already using. So you need the seed and the CLI tool, and you just import the seed into but so on the leaves piece,
is it impractical to cash this stuff locally? I mean, I I my understanding is it's after every transaction is basically when you would need an update.
Or Yeah. Like, is that no reason to do it right now. When you can unilaterally exit, obviously, you would need to do that. So, that that will be part of the update is that you have all of the leaf states stored locally.
It's not a problem long term. Like, it's not that much storage or anything like that. So, it is practical for a mobile user to be caching Yeah. Stuff. Yeah. For sure. Yeah. For sure. Yeah. It'll it'll be it'll be very possible for mobile. Obviously, the actual unilateral exit will take a long time. I think that's something a lot of people think about is there's
a time lock that's associated with every unilateral exit, and they are relatively costly when it comes to fees. It depends widely based on the size of your leaves, the timing, the depth of the trees. Like, there's a lot of stuff that goes into calculating the cost. But,
yeah, it'll definitely be possible in mobile. And basically, it would just be a one time
emergency I want out button, and then it'll craft all the transactions and broadcast them. But you'll have to wait a while before they would actually be
spendable because of the time locks that are associated with them. Think something like But, two weeks
yeah, if it's an emergency exit, you don't really care. You just wanna get your money back.
That makes sense. I mean, while we're on the topic of trade offs between these different systems, I mean, the other option that a bunch of wallets chose,
bull Bitcoin being one of them, Aqua, MANA, is was is using liquid as the as basically
the back end. Mhmm. What is your opinion on on that?
I mean, to me, both Spark and Arc kind of obsolete liquid.
Liquid is just a it's a pure multi sig custodian.
The only real advantage to liquid is that there is some base privacy,
because you can do confidential amounts and confidential tokens,
which is a nice ad,
but there's not significantly better privacy? I mean, you're the privacy guy.
It would be if anyone actually used it. Well, mean, it's a chicken and egg. Right? I think because of bull Bitcoin, there's probably an Aqua. There's probably more
Bitcoin there's more liquid users than we've ever seen before. I mean, it's a low bar, but more liquid users than we've ever seen before. There are dozens of us. Yeah. I mean, yes, technically. The hard part is you you start to get into the realm of how long can this thing
go on if it does
gain very broad adoption.
Because when you do mix privacy with custody, you're kind of
the ultimate in the crosshairs of every regulator in the world.
So I would be concerned long term what that would look like for liquid. Now, obviously, the nice thing about them having a very large federation
is that it would be very, like, practically difficult to shut them down if they were to actually fight back and try not to be shut down. But there are also businesses that are the federation members, and if the countries where they're a business, pressure them. They're not gonna I I don't think they destroy their business for your
your liquid Bitcoin.
Yeah.
I mean, I
I love the privacy it brings. It to me, it just has it's like a better version of eCash
in terms of custody. We're like, it's a better custody model. It's more like Fediments, has reasonably good privacy.
But
I think that Spark and Arc can take clear meaningful steps to become similarly private.
And so I think that's much more interesting
because if we can bring the better trust models of Spark and Arc with good privacy,
I think that'd be a better world. Arc, obviously, you can do a lot of the Bitcoin privacy stuff that already exists on chain within Arc. It's like you could have very large coin join rounds that are every minute or whatever.
Within Arc, can do some blinded
blinded credential stuff within ARC.
Spark, you can do blind signing, which would give complete
privacy from the operator, which would be massive. Do you think that's gonna happen?
I hope so.
There's been some signs that Spark is going to continue implementing more privacy into their solution. Blind signing obviously is
so complete that I I
would guess it probably wouldn't happen in Lightspark's Spark entity,
but it would raise the question of will someone start another Spark entity that does blind signing?
Technologically, it's quite possible. And if someone did start that,
it would be an interesting competitive
edge for them of providing the the the private alternative with all of the same trust model benefits of Spark. I would doubt that that will come to LightSpark, Spark and C unfortunately, but I'm hopeful.
I presume you'd be open to
moving
either to different Spark operators or potentially even Arc
Yeah. For radar users and Cakewallet users, like,
the given improvements or whatnot.
For sure. Yeah. And one of the really nice things about all these is,
like, let's say, let's say Spark goes nuts or Arc becomes like the a perfect privacy protocol gets built on top of Arc and
is usable.
They all speak lightning, so actually transitioning users between them would be quite trivial. You just you just make a lightning balance, sweep the balance out of Spark and move on with your life. You wouldn't have to do anything super complex. You're not talking swapping cryptocurrencies
or something like this. So
I I am definitely open to that. And something I've I've always been open to is, let's just we'll use the best technology at the moment. Right now, think that's Spark. Tomorrow, it could be Arc. We'll see. And in this case, specifically with radar, I think it has a little bit of a different balance than something like Cake Wallet. Cake Wallet, obviously, we're building for a little bit more hardcore user who's a little bit shifted more that way, whereas Radar, I I more want it to be something that's very achievable
for the average person who's not as, like, super hardcore self custody, but still give them self custody. And that's where I think Spark fits really well right now as well. But, yeah, we'll definitely see where it plays out.
Makes sense.
You mentioned earlier
USD tokens.
I think you call them stable balances. Is that the plan? Is the plan to make this Bitcoin
and USD tokens,
and that's that on the wallet side and payment side?
Yeah. I mean, definitely no other, like, cryptocurrencies planned. I
don't think there would be any reason to add other cryptocurrencies or other chains.
The only reason we would do stablecoins, and it is something that that I think we will do, is again, just for that user who is not a hardcore bitcoiner, but just wants a stable balance, to be able to offer that and offer the ability to swap between the two at a tap really quickly for almost no fees
is really nice.
And they still have self custody over the keys. Obviously, stablecoins introduce other trust assumptions where depending on the stablecoin, they can be frozen.
They often are.
Yeah. They often are. So there there are caveats with that, and obviously, we would inform users of that.
The the benefit there for most people who we envision using radar long term to make it feel much more like a
a regular
payments app rather
than this hardcore Bitcoin thing,
I think is an ideal crossover. So that is the vision that it will be either Bitcoin denominated or
stable balance, and you can choose what you wanna do, and it'll be all of your balance in one or the other. Again, not trying to be a wallet where you're like, you're choosing how much of each you have or anything like that. If you want that come that kind of option, you wouldn't have both.
You wouldn't have both in the same wallet.
So you would you would be able to choose, but you couldn't have both at the same time.
Your balance would be either entirely in stable coins or entirely in Bitcoin. Why?
Simplicity.
But is that how most people interact with their daily lives? I mean, least right now, it's like they have dollars and Bitcoin.
Yes. But they're also two very disparate things.
Like, when you're thinking through a product and you're thinking how is a user going to
gonna see this and decide which one they want to use at the given time. Like, why would a user keep some of their balance in radar and stablecoins and not all of it or some of it in Bitcoin and not all of it rather than just all or nothing. Again, thinking this outside of the lens of this isn't your your wallet. Like, if you're a Bitcoiner,
you're gonna have another wallet. You're gonna have something like Cakewallet lets you use Stablecoins and Bitcoin and Monero or whatever. Radar is specifically how do I wanna handle the money I'm using for payments within radar? Not how do I wanna handle my whole checking account or situation, if I sent if I'm
Bitcoin
and I send a payment to someone whose dollars,
it would just automatically
on the fly just do the swap.
They receive dollars and vice versa. They send me dollars, I'd receive Bitcoin. Yep. Yeah. But just because it's converted on the fly. There's a essentially an AMM like swap
on Spark called FlashNet
That does the conversion.
That was that's David's son's company. Mhmm. Yeah. So so USD tokens are live on Spark right now?
Yeah. Yeah. There's already they've they've been live for quite a while. There's one called USDB, is the primary one right now, and it it works well. Obviously, the adoption compared to like USDT or something is
But
in in this specific scenario where the goal is not paying any other crypto user,
it's paying other radar users, it doesn't really matter as much the actual reach of that stablecoin. All that matters obviously is the security,
like it needs to be properly backed and and run well, and this one's backed by a huge stablecoin company called Braille. Mhmm. Braille with an r?
Yeah. Yeah. B r a l e.
0, with a b?
Yeah. Yeah. Rail. Sorry. Yeah. Oh, like how blind people read? But not spelled that way. Got it.
Fair enough.
Okay.
So what what about have have you I mean,
in USD token land,
like, king is a tether on Tron, and maybe the king in the Western world among big tech folks is like USDC on base.
Yeah, obviously,
I think. Right. It's really great. It's like that. What is it? The meme where it's like, we can solve the standards problem by creating a new standard.
The
obviously your average user who's using these that your average dollar user,
which if you want to talk about network effects is obviously
the
largest network effect of of currencies right now is probably interacting
with either Tron on Tether or USDC on base.
How do you think about that flow? Are you going to give them
an ad
a deposit and withdrawal flow that goes to those chains?
Or
are they can only get out with Bitcoin? Or how does that look?
Yeah. I have definitely thought about that. The plan is to do it similar to how we do Anypay and Cake Wallet,
where
again, like, I I want to be wary because I don't want Radar to become a fully featured wallet app. It doesn't need to be that, and it it will inevitably tend to be
over engineered and bloated if we do that. So trying to keep it very limited in scope. So using one provider,
the goal is to allow you to add funds from any stablecoin
into it, and it will automatically be converted into Bitcoin on Spark and
send to any stable coin on any chain.
Got Again, not trying to do everything.
Keep it very straightforward. You won't get like a million swap providers like you do on cake or whatever. Yeah. No. Obviously, on Cake, we want users to have max optionality.
That's a very different target audience.
In RADAR, it needs to be very simple and very clean. So, that that will be the approach. And the nice thing is like that's very possible with Spark. There's already good swap providers that can do all of that natively on Spark. So that will be the long term plan because, like,
the I I less of a need for the sending. Like, I don't think there's gonna be that much of a use case for sending out of radar
like it's a wallet app. But adding funds, I could definitely see it. If you're already a crypto user at all, I want to be able to onboard you even if you don't have Bitcoin Lightning. Because, I mean, honestly, let's be honest. The people the number of people who have stable coins in a crypto wallet versus the number of people who have Bitcoin in a Lightning wallet is Is there gonna be like different.
Apple Pay to add funds? Or Yeah.
Yeah. For sure. For sure. Yeah. Again Is is that the main monetization
scheme for Radar as a company? Is the
the the
swaps in and out, basically?
Yeah. The initial the initial idea is the the on and off ramping. Obviously, one's straightforward.
These swaps between currencies,
the swaps between Bitcoin and stable coins as people go back and forth,
taking a small a small cut of the fees there. That's the plan at this point. There's some other stuff we're exploring around stable coins that could be
a good long term sustainability play, but that's still too early in discovery to kinda talk more details about it. But,
yeah, those are the the straightforward ones, and specifically the swapping crypto ones is the one that's been really effective for cake and would be fitting here for the tier one audience, but more long term when we're talking people who are not hardcore Bitcoiners, it's gonna be more of the on and off ramping, just topping up your balance and taking a small cut of that will
be the the game plan.
And it's not transaction fee. Are you gonna take a cut of transaction fees between users?
No. No. No. The only fee there is just the base Spark fee, which is two sets.
Is that hard coded?
It is. Yeah. Don't ask me why it's two sets. It's very interesting. What's double double one set? It
is. So just every Spark transaction is a two set fee regardless of amount? Yeah.
Fascinating.
There were fee lists for a while, just like Arcade and Second R, but they're all gonna have fees at some point, obviously. So, yeah, it's just a flat a flat two set fee. Obviously, if you're making a Lightning payment, then you also have whatever the routing fee is.
And who runs that node?
Does Spark run that node?
The the lighting service provider side? Yeah. Yeah. Light Spark runs it.
And is that always gonna do you have any is that the plan? Like, is it just always gonna be Light Spark as the sole LSP of the main Spark?
No. The plan is to have more. I've been talking to them about it because, like, I specifically,
I would love Bolts to be another provider there. They're already doing a fantastic job on the the Arcade side. And the liquid side. And the liquid side. I just I love their team. All the liquid wallets, basically,
their dependency is Bolt's They
live or die by Bolt's. Yeah. So that that is definitely
it's going to happen. The Spark guys have been keeping it limited initially while they just get everything really stable,
but I think we're getting to that point. I was just talking to them in Vegas actually about that, and they feel very close to being able to to start onboarding more LSPs,
as well as more Spark operators to keep growing that that decentralization
side of things.
Technically,
anyone can be an LSP. It would just be who who are the default available providers within the SDK. But anyone who anyone can join Spark. It's an open permissionless network. So anyone could do it today, but obviously, it'd be easier if you were actually a default provider in in the SDKs that were available. So, mean, they take Spark sets and then send out payments on Lightning. Yeah. Yeah. And it's it's all atomic swaps. So anyone could
do that and it is that
the swap part of it is trustless as well, which is a really nice piece of that. That's possible within Spark and within Arc.
It's interesting with Spark because a lot of the companies that I've seen, projects I've seen that have implemented it, part of the reason they implemented it is because they kind of wanted to wipe their hands of any kind of agency over users.
There hasn't really been that much demand for,
my company is implementing Spark, can I run the LS? Can I run the lightning node? Because like, part of the advantage of it is,
like, David Marcus deals with your regulatory concerns and all of your technical concerns. It's like, he just handles all
the hard just don't have to worry about it. Yeah.
For sure. For sure.
Okay. Awesome.
Seth, I think this is a great conversation to the freaks at home.
You're not seeing any videos, so you're not aware that Seth
has a debilitating sickness that he's recovering from. So he's been a real trooper. We were supposed to originally record yesterday, and it got pushed to today, but he's visibly sick right now. Seth, do you have is there anything we didn't cover that you'd like to
mention to the freaks before we wrap here?
No. I think those are the biggest things. Just go check out radar. Chat at radar chat on x and Noster. Just at radar on Noster even though Noster's weird. So you'll need the in pub, and I'm not gonna read that out to you. But we are we are on Noster as well. No. I think that's the primary thing. Honestly, just love people to to give it a try. The best the best user experience is using it instead of signal, like moving your account into radar from signal. Like I said, that's how I've been doing it for months, and now
now thousands of people are using it. It's been a productive lunch day. Launched twenty four hours, I guess, now. But, yeah, give it a try. It's pretty badass once you get the chance to actually just send sats in a chat and not think about it. It's smooth. So we're excited to grow from here. Only getting started.
Thanks for the combo. Thanks for putting up with my my stuffy voice. I'm sorry to all the listeners dealing with this very high quality
stuffy voice. So Love it. Well, thank you for joining us. Thank you for building Radar and Cake. I absolutely love it. Freaks,
thank you to all who support the show. As always, all the relevant links are cieldispatch.com.
It's available on every podcast app. You can search ciel dispatch in your favorite podcast app. Share with friends and family.
I have a great show lined up for next week. It's going to be no good node, who's one of my favorite Bitcoin artists. He just released a portfolio book that I have in front of me. It's fantastic. So that'll be a fun conversation. He actually is the one who made my background art and my album art and everything like that. I love his style. I think it's fucking fantastic.
And then I have some great shows lined up after that, so
stay tuned for that. Love you all. Stay on the Stack Sets. Peace.