CD207: SETH FOR PRIVACY - RADAR - BITCOIN IN SIGNAL

WEBVTT

NOTE
Transcription provided by Podhome.fm
Created: 07/08/2026 21:22:18
Duration: 3889.319
Channels: 1

1
00:00:31.730 --> 00:00:37.970
Happy Bitcoin Wednesday, freaks. It's your host, Odell, here for another Seal Dispatch,

2
00:00:38.370 --> 00:00:39.650
the show focused

3
00:00:40.050 --> 00:00:43.810
on actual Bitcoin and Freedom Tech discussion.

4
00:00:45.345 --> 00:00:50.145
Got a great show lined up for you freaks. But before we get there real quick, the current

5
00:00:50.545 --> 00:00:51.265
time

6
00:00:51.745 --> 00:00:56.144
is Wednesday, July 8 at nineteen forty UTC.

7
00:00:56.385 --> 00:01:01.370
You guys will be listening to this in a couple hours. Just do a quick cleanup.

8
00:01:01.769 --> 00:01:10.409
No edit. In Bitcoin time, the current block height is nine five seven two one eight. The current price is $62,190,

9
00:01:11.690 --> 00:01:16.765
and the stats per dollar is 1,608

10
00:01:17.165 --> 00:01:25.085
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,

11
00:01:26.240 --> 00:01:30.560
And we keep grinding, we keep grinding freaks as always dispatch,

12
00:01:30.720 --> 00:01:32.080
no Azure sponsors.

13
00:01:32.640 --> 00:01:35.920
I only do shows when I think it'll be interesting to you guys,

14
00:01:36.480 --> 00:01:38.320
not beholden to the

15
00:01:39.315 --> 00:01:44.435
schedule of a sponsor that wants three shows a week or whatnot and fills your feed with noise.

16
00:01:45.555 --> 00:01:50.755
But that means that is supported purely by viewers like you with Bitcoin donations.

17
00:01:51.395 --> 00:01:53.475
All relevant links are still dispatch.com

18
00:01:53.475 --> 00:01:53.875
for that.

19
00:01:55.049 --> 00:01:58.090
Our top two Zaps of last week

20
00:01:58.970 --> 00:01:59.689
were

21
00:02:00.329 --> 00:02:06.649
ride or die freak, Mav twenty one with 10,000 sats. He said great rip. And PGS design

22
00:02:06.970 --> 00:02:10.489
also with 10,000 sats said killing it exclamation point.

23
00:02:11.185 --> 00:02:15.505
Thank you, freaks, for supporting the show. As always, if you can't spare your scarce sats,

24
00:02:15.825 --> 00:02:18.785
I know money's tight right now. I know we're all poor as hell.

25
00:02:19.105 --> 00:02:21.825
Share with your friends and family. Open up your friends app,

26
00:02:22.625 --> 00:02:30.220
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.

27
00:02:31.100 --> 00:02:37.420
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.

28
00:02:39.115 --> 00:02:52.715
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?

29
00:02:53.090 --> 00:02:53.810
Yep.

30
00:02:53.970 --> 00:02:56.770
Yeah. Chief operating officer at CakeWallet.

31
00:02:57.329 --> 00:03:03.170
They got a new app out that is a different company, but similar team called

32
00:03:03.890 --> 00:03:04.770
Radar.

33
00:03:05.329 --> 00:03:06.530
What is Radar?

34
00:03:06.610 --> 00:03:12.095
Indeed. Yeah. So we we have kicked off a completely new thing, shifted focus.

35
00:03:12.255 --> 00:03:14.015
Cake Wallet obviously remains

36
00:03:14.735 --> 00:03:26.719
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

37
00:03:27.359 --> 00:03:29.600
like, the the idea is quite straightforward.

38
00:03:30.159 --> 00:03:32.000
We just always kind of accepted that

39
00:03:32.319 --> 00:03:34.080
when we want to message somebody

40
00:03:34.480 --> 00:03:53.660
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?

41
00:03:54.220 --> 00:03:56.060
I'm not. No. Not.

42
00:03:57.180 --> 00:03:57.820
I've had

43
00:03:59.020 --> 00:04:09.935
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,

44
00:04:10.255 --> 00:04:19.775
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.

45
00:04:20.340 --> 00:04:25.700
So your contacts actually come with you. All your chats come with you. Your account comes with your username, etcetera.

46
00:04:26.020 --> 00:04:33.395
But anybody who joins RADAR as well, you get to send and receive Bitcoin back and forth seamlessly at a tap instant.

47
00:04:33.875 --> 00:04:37.635
It's really kinda stupid simple in execution,

48
00:04:37.795 --> 00:04:43.635
but the the vision and the goal is getting this far far beyond the the regular Bitcoin wallet user.

49
00:04:44.275 --> 00:04:45.955
Okay. So high level,

50
00:04:46.435 --> 00:04:47.075
first of all,

51
00:04:48.180 --> 00:04:50.900
I've been testing radar for a few weeks now.

52
00:04:51.940 --> 00:05:02.340
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.

53
00:05:02.965 --> 00:05:22.870
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

54
00:05:23.030 --> 00:05:26.550
app to to be able to support 90 year old

55
00:05:27.110 --> 00:05:27.750
grandmothers.

56
00:05:28.005 --> 00:05:34.085
That is incredibly rare. Also signal has a 100,000,000 users as far as freedom focused apps go, probably

57
00:05:34.965 --> 00:05:39.685
one of the best adoption stories we've ever seen. So signals also my obviously love Bitcoin.

58
00:05:40.020 --> 00:05:42.180
So this is a combination of the two of those

59
00:05:42.500 --> 00:05:48.820
signal. The app itself is open source. So effectively, what you guys did was you took the open source app and

60
00:05:49.539 --> 00:05:52.740
then you forked it and you added a Bitcoin wallet into it. Correct?

61
00:05:53.544 --> 00:06:03.145
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.

62
00:06:03.705 --> 00:06:04.665
I think they've

63
00:06:04.985 --> 00:06:11.300
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

64
00:06:11.780 --> 00:06:13.140
basically anymore.

65
00:06:13.860 --> 00:06:18.980
But it was their attempt at solving this problem, and they did it in a way that was Monero like privacy,

66
00:06:19.460 --> 00:06:20.580
but did sync

67
00:06:21.455 --> 00:06:24.575
in a way that relied on Intel SGX

68
00:06:24.575 --> 00:06:27.935
to preserve user privacy. It was interesting technologically,

69
00:06:27.935 --> 00:06:41.140
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,

70
00:06:41.540 --> 00:06:44.420
but do it through the intent encrypted signal protocol,

71
00:06:44.740 --> 00:06:51.155
it's all still there. Even if they're not using it, all of the underlying technology that you need to to use

72
00:06:51.155 --> 00:06:54.755
Bitcoin in signal is all there and functional today.

73
00:06:55.314 --> 00:07:12.060
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?

74
00:07:13.980 --> 00:07:21.825
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.

75
00:07:22.545 --> 00:07:25.425
SIGNAL cannot run the Mets. They're they're already

76
00:07:26.065 --> 00:07:27.825
in such a regulatory,

77
00:07:29.380 --> 00:07:36.420
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.

78
00:07:36.900 --> 00:07:39.300
If they then touch any user money,

79
00:07:39.700 --> 00:07:40.980
it becomes a

80
00:07:41.140 --> 00:07:49.215
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?

81
00:07:49.775 --> 00:08:09.300
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.

82
00:08:10.020 --> 00:08:20.065
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

83
00:08:20.305 --> 00:08:23.425
100 plus million monthly active users immediately as well.

84
00:08:24.065 --> 00:08:29.880
Yeah. I mean, I think that would be awesome. I mean, before we jump into the Bitcoin piece

85
00:08:30.120 --> 00:08:33.640
Mhmm. I just wanna be really clear to users, potential users here.

86
00:08:34.200 --> 00:08:36.520
The whole point of radar is

87
00:08:36.839 --> 00:08:47.125
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

88
00:08:47.365 --> 00:09:02.950
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.

89
00:09:03.110 --> 00:09:11.975
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.

90
00:09:12.774 --> 00:09:16.295
When I've been testing it, I've been testing it with a burner number for that reason.

91
00:09:16.615 --> 00:09:20.535
That it's not like I have all my eggs in this one beta

92
00:09:20.850 --> 00:09:24.290
project. I mean, now it's out and released. But at the time, was

93
00:09:24.610 --> 00:09:32.209
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

94
00:09:33.545 --> 00:09:43.945
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.

95
00:09:44.105 --> 00:09:52.990
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.

96
00:09:53.470 --> 00:09:54.270
The answer

97
00:09:54.510 --> 00:10:07.395
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?

98
00:10:07.795 --> 00:10:15.555
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.

99
00:10:16.210 --> 00:10:20.690
Not necessarily more than Simplex or others, but when the target is

100
00:10:22.529 --> 00:10:28.690
the average individual and not the hardcore Bitcoiner as, like, the end goal of who we're reaching with this product,

101
00:10:29.465 --> 00:10:34.265
I think it it needs to be something closer to signal than something like

102
00:10:34.585 --> 00:10:37.065
simplex or something like white noise.

103
00:10:37.385 --> 00:10:43.865
Things that have more hardcore features White noise is not even usable, and there's also no network effect. Yeah. Simplex,

104
00:10:44.560 --> 00:10:56.640
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

105
00:10:57.165 --> 00:11:08.285
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

106
00:11:09.005 --> 00:11:10.605
issue right now, and I know

107
00:11:11.240 --> 00:11:15.320
it's publicly out there, but you guys are obviously gonna make iterative improvements.

108
00:11:15.560 --> 00:11:22.360
Like, the cool part here as opposed to me just pasting a lightning address into a group chat

109
00:11:22.440 --> 00:11:29.985
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

110
00:11:30.705 --> 00:11:33.025
is a bit of confusion in the interface

111
00:11:34.065 --> 00:11:35.585
on which users

112
00:11:35.825 --> 00:11:36.865
are

113
00:11:38.360 --> 00:11:42.520
like, regular signal users versus radar users? Like, obviously,

114
00:11:43.320 --> 00:11:49.080
at the beginning, 99% of my address book or my signal contacts are going to be regular signal users.

115
00:11:49.400 --> 00:11:54.565
Mhmm. How do you think about that UX of who can I pay and who can't I pay?

116
00:11:55.204 --> 00:11:56.404
You know what mean? Yeah. It's a

117
00:11:56.964 --> 00:12:11.330
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

118
00:12:11.330 --> 00:12:12.370
notification.

119
00:12:12.690 --> 00:12:15.570
I because I've tested this out with my other Signal account.

120
00:12:16.770 --> 00:12:32.355
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.

121
00:12:33.200 --> 00:12:40.160
To Radar, obviously, it understands that it is is Lightning. So some work that we're going to do around that is to

122
00:12:40.480 --> 00:12:46.640
to make it clearer, automatically disable it within chats that the other user doesn't actually have doesn't actually have Radar.

123
00:12:47.015 --> 00:12:50.615
And then, like, when you go to the payments tab and you hit send to automatically,

124
00:12:50.935 --> 00:12:51.415
like,

125
00:12:52.055 --> 00:13:21.325
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.

126
00:13:21.965 --> 00:13:25.885
Overwhelming number of users is on a different client. Right? Yeah. Yeah.

127
00:13:26.605 --> 00:13:32.285
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.

128
00:13:34.580 --> 00:13:40.180
Part of why signal has been successful is because they have a very, I would say pragmatic trade off model.

129
00:13:40.980 --> 00:13:47.380
People are upset about phone numbers, but they use it for spam mitigation and network effect because phone numbers are

130
00:13:47.995 --> 00:14:07.480
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.

131
00:14:08.040 --> 00:14:09.560
How are you thinking about

132
00:14:11.320 --> 00:14:21.475
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?

133
00:14:23.395 --> 00:14:25.955
I mean, not ask permission as much as

134
00:14:26.915 --> 00:14:28.195
hope they don't choose to be.

135
00:14:29.730 --> 00:14:44.175
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,

136
00:14:44.175 --> 00:14:51.535
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

137
00:14:51.535 --> 00:14:55.135
block that as long as we're not doing something to happen in terms

138
00:14:55.615 --> 00:14:57.535
of service. They have, but only in

139
00:14:58.029 --> 00:15:05.390
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

140
00:15:05.710 --> 00:15:13.310
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

141
00:15:13.555 --> 00:15:26.275
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.

142
00:15:27.380 --> 00:15:57.385
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

143
00:15:57.930 --> 00:16:15.285
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

144
00:16:15.765 --> 00:16:35.070
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.

145
00:16:35.774 --> 00:16:41.615
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

146
00:16:42.495 --> 00:16:46.894
That makes sense to me. I mean, I do like just the general concept of

147
00:16:48.430 --> 00:16:52.110
building on an open protocol that's maintained by a nonprofit

148
00:16:52.350 --> 00:16:56.110
and then donating a portion of profits back upstream.

149
00:16:56.110 --> 00:17:00.990
It's a very sustainable revenue model for the nonprofit itself and the open protocol itself,

150
00:17:01.435 --> 00:17:03.515
or I guess open protocol itself.

151
00:17:03.595 --> 00:17:04.235
The

152
00:17:05.355 --> 00:17:08.554
Do you feel like that's kind of how this thing should work? Is like Yeah.

153
00:17:09.115 --> 00:17:14.955
The protocol should always be owned by an open source foundation because the protocol has to remain something that's very neutral.

154
00:17:15.820 --> 00:17:16.460
Yeah.

155
00:17:16.860 --> 00:17:18.220
Or nobody like Bitcoin.

156
00:17:18.540 --> 00:17:25.740
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

157
00:17:25.740 --> 00:17:27.580
organizations like OpenSats.

158
00:17:27.580 --> 00:17:29.500
Like, they're they're being funded by

159
00:17:29.980 --> 00:17:38.005
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.

160
00:17:38.645 --> 00:17:53.100
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,

161
00:17:53.500 --> 00:18:00.860
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.

162
00:18:01.435 --> 00:18:06.395
I could see it playing out with Simplex as well, because I know the foundation for the protocol is going to be nonprofit,

163
00:18:06.395 --> 00:18:23.289
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.

164
00:18:23.450 --> 00:18:34.625
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

165
00:18:35.185 --> 00:18:48.570
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.

166
00:18:50.890 --> 00:18:51.850
Do you know

167
00:18:53.690 --> 00:18:55.690
okay. Let's say I import my

168
00:18:56.330 --> 00:18:58.730
my main into radar

169
00:18:58.810 --> 00:19:00.570
and signal bands

170
00:19:00.970 --> 00:19:01.530
the app.

171
00:19:02.465 --> 00:19:06.465
Am I able to gracefully move back or am I just shit out of luck?

172
00:19:06.785 --> 00:19:13.345
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.

173
00:19:13.825 --> 00:19:14.865
Like, let's say

174
00:19:15.330 --> 00:19:19.570
like, I've been using radar for my primary signal now for

175
00:19:20.850 --> 00:19:22.849
three, four months at at least.

176
00:19:23.250 --> 00:19:30.370
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.

177
00:19:31.295 --> 00:19:36.254
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.

178
00:19:36.335 --> 00:19:40.815
So I've usually used Graphene for my public one and then iOS for that.

179
00:19:41.775 --> 00:19:49.870
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

180
00:19:51.070 --> 00:19:54.509
if the app gets banned. Right? Because they would just be banning the

181
00:19:54.750 --> 00:20:00.430
the actual network connections for that app. But when you went and logged in from the official SIGNAL app, it wouldn't be

182
00:20:01.375 --> 00:20:20.470
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.

183
00:20:20.790 --> 00:20:27.910
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,

184
00:20:28.835 --> 00:20:38.434
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

185
00:20:38.675 --> 00:20:48.529
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.

186
00:20:48.770 --> 00:20:56.290
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.

187
00:20:57.115 --> 00:20:57.914
Makes sense.

188
00:20:58.235 --> 00:20:59.034
Okay.

189
00:20:59.434 --> 00:21:01.274
Kind of a tangent. Were talking about

190
00:21:01.674 --> 00:21:03.835
not using the signal branding.

191
00:21:04.235 --> 00:21:05.755
Mhmm. Why radar?

192
00:21:09.460 --> 00:21:14.820
There's not like a crazy story behind the name. We went back and forth on a lot of different options

193
00:21:14.820 --> 00:21:15.540
and

194
00:21:16.180 --> 00:21:18.820
just really wanted something that was, like, memorable,

195
00:21:18.900 --> 00:21:20.340
but optimistic,

196
00:21:20.340 --> 00:21:26.835
easy to say in other languages. It's a palindrome, which is always a win when you're naming something. Same forwards and backwards.

197
00:21:27.635 --> 00:21:31.075
And it it let us do some really fun things with iconography

198
00:21:31.075 --> 00:21:31.794
and,

199
00:21:32.115 --> 00:21:34.515
like, visual design. Like, you'll notice throughout,

200
00:21:35.075 --> 00:21:38.435
obviously, the icon itself. But if you go to the website, radar.chat,

201
00:21:38.435 --> 00:21:41.555
like, you'll see that we use the kind of the radar

202
00:21:40.690 --> 00:21:41.890
sweeping motif,

203
00:21:41.970 --> 00:21:46.850
pings, that kind of thing all throughout. So it's more that it's a fun brand. I mean, similar to cake, like,

204
00:21:47.490 --> 00:22:04.595
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,

205
00:22:05.570 --> 00:22:07.330
super crypto anarchist,

206
00:22:07.330 --> 00:22:09.250
dark undertones feeling

207
00:22:09.410 --> 00:22:10.610
app or brand.

208
00:22:10.930 --> 00:22:32.295
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

209
00:22:32.800 --> 00:22:33.600
signal,

210
00:22:34.080 --> 00:22:44.480
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,

211
00:22:45.045 --> 00:22:48.965
and not require them to give up ID or other things like that. But yeah.

212
00:22:49.685 --> 00:22:53.365
I feel like I have to mention. I like the name Radar. I think

213
00:22:53.845 --> 00:22:58.510
it's clean, it's catchy, easy to remember. The domain's easy. Radar.chats,

214
00:22:58.510 --> 00:23:01.390
good domain, the branding school, but someone did

215
00:23:02.270 --> 00:23:09.870
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?

216
00:23:13.005 --> 00:23:23.085
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

217
00:23:24.540 --> 00:23:28.620
it's true. I was actually thinking about that. There was a If you're There's another app that

218
00:23:29.100 --> 00:23:33.740
I think he works at Ocean. I'm blanking on his name right now, but he made something called Sonar

219
00:23:33.980 --> 00:23:35.580
and just released it, like,

220
00:23:35.980 --> 00:23:56.220
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

221
00:23:56.220 --> 00:23:59.020
ability to go over the Internet via Noster.

222
00:23:59.260 --> 00:24:03.100
So, again, a more hardcore use case, but I thought that was funny and, like, the

223
00:24:03.500 --> 00:24:07.255
the fittingness of sonar being something you use underwater

224
00:24:07.255 --> 00:24:20.295
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

225
00:24:20.760 --> 00:24:25.799
it fit well together even though we were just building in parallel and had had no idea that that was that was coming out.

226
00:24:26.280 --> 00:24:28.360
Fair enough. Okay. Bitcoin.

227
00:24:28.600 --> 00:24:33.080
One of my critiques I I love cake while I think cake while it's great. I've gotten some

228
00:24:35.765 --> 00:24:39.845
I don't know. I love cake wallet. I think it's awesome. My biggest issue,

229
00:24:39.925 --> 00:24:51.605
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

230
00:24:51.910 --> 00:24:54.710
that it's got so many different features

231
00:24:55.110 --> 00:24:55.990
that

232
00:24:55.990 --> 00:24:57.350
is quite complicated.

233
00:24:58.470 --> 00:25:03.110
Or maybe complicated is the wrong word, but there's a lot of things going on in Cakewallet. Not only

234
00:25:03.955 --> 00:25:12.115
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.

235
00:25:12.355 --> 00:25:15.155
I've noticed with radar, you went much simpler

236
00:25:15.395 --> 00:25:16.355
and specifically,

237
00:25:17.429 --> 00:25:22.070
it's just one wallet, one type of wallet, and you chose Spark

238
00:25:22.309 --> 00:25:25.829
as the back end for that with a lightning focus.

239
00:25:25.830 --> 00:25:34.514
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,

240
00:25:35.075 --> 00:25:48.209
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,

241
00:25:48.289 --> 00:25:53.729
a Bitcoin wallet that does all of these things and that they're going to use in daily life versus how many people

242
00:25:54.529 --> 00:25:59.889
are already chatting and they want a way to be able to send value easily. And I think there's this

243
00:26:01.755 --> 00:26:09.914
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

244
00:26:10.075 --> 00:26:15.929
make everything about Bitcoin rather than figuring out, like, where does Bitcoin just solve something regular people need,

245
00:26:16.170 --> 00:26:18.970
and we can kind of Trojan horse it into their lives.

246
00:26:19.290 --> 00:26:23.210
And that's more how I view radar. So I think for radar, like, the long term, I don't

247
00:26:25.290 --> 00:26:30.325
I would be very happy if we got to a place where the majority of our users were not

248
00:26:30.885 --> 00:26:33.445
Bitcoiners in the sense that they weren't necessarily

249
00:26:33.765 --> 00:26:38.325
coming to radar because they're already stacking SATs, so they already have a hardware wallet or whatever.

250
00:26:38.725 --> 00:26:51.799
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,

251
00:26:52.280 --> 00:27:04.145
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.

252
00:27:04.625 --> 00:27:12.850
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

253
00:27:13.010 --> 00:27:21.250
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.

254
00:27:21.855 --> 00:27:35.535
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.

255
00:27:36.140 --> 00:27:44.940
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.

256
00:27:45.980 --> 00:27:52.044
This offers none of that. I mean, it's this is purely Lightning only. Was that a deliberate decision?

257
00:27:52.125 --> 00:27:52.284
Or

258
00:27:53.245 --> 00:27:53.884
Yeah.

259
00:27:54.125 --> 00:27:54.924
Yeah.

260
00:27:55.164 --> 00:27:59.965
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

261
00:28:00.445 --> 00:28:09.399
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

262
00:28:10.200 --> 00:28:12.919
to make this something that's tenable for a regular person,

263
00:28:13.400 --> 00:28:15.080
the user experience has to be,

264
00:28:15.800 --> 00:28:16.520
like, almost

265
00:28:16.934 --> 00:28:18.294
entirely frictionless.

266
00:28:18.455 --> 00:28:20.134
And even on chain Bitcoin,

267
00:28:20.774 --> 00:28:23.734
while it can be simple in how it works,

268
00:28:24.534 --> 00:28:31.975
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

269
00:28:32.390 --> 00:28:34.950
obviously, there are some ways to kind of pretend that

270
00:28:35.270 --> 00:28:36.390
that it's fine.

271
00:28:37.270 --> 00:28:50.965
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.

272
00:28:51.205 --> 00:28:53.605
Yeah. But I noticed, like, Spark supports

273
00:28:53.685 --> 00:28:58.485
sending and receiving on chain, and I noticed you guys have that disabled. You're just doing Lightning only.

274
00:28:59.140 --> 00:29:20.754
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

275
00:29:21.475 --> 00:29:25.075
this isn't a wallet. That's not it's not the the goal here

276
00:29:25.395 --> 00:29:27.395
that you would be using this for

277
00:29:27.889 --> 00:29:31.169
lots of external Bitcoin only kind of things.

278
00:29:31.490 --> 00:29:34.049
The goal here is that you need a way to get money in,

279
00:29:34.529 --> 00:29:38.369
and you need a way to send and receive money within the system, and it needs to be very frictionless.

280
00:29:38.529 --> 00:29:41.090
And because Lightning has become the interoperability layer,

281
00:29:41.554 --> 00:29:51.715
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,

282
00:29:52.115 --> 00:29:56.515
super fast, super easy, super cheap, and then Lightning whenever we need interoperability.

283
00:29:57.450 --> 00:30:08.889
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.

284
00:30:10.169 --> 00:30:12.730
Why did you choose Spark as the back end?

285
00:30:15.585 --> 00:30:21.985
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

286
00:30:23.425 --> 00:30:27.905
the primary reason is still that the UX on Spark is slightly better than ARC

287
00:30:28.540 --> 00:30:30.059
for the same trust model.

288
00:30:30.380 --> 00:30:32.700
And then the secondary reason is that

289
00:30:33.420 --> 00:30:37.260
stablecoins on Spark, I think, will be a particularly good fit for Radar.

290
00:30:37.580 --> 00:30:52.275
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

291
00:30:52.835 --> 00:30:59.909
Arcade technically could allow. Second, won't allow right now on the Arc side. Those are the primary two reasons.

292
00:31:00.470 --> 00:31:18.885
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

293
00:31:19.765 --> 00:31:35.800
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.

294
00:31:36.360 --> 00:31:38.120
I mean, I know you

295
00:31:38.360 --> 00:31:40.280
have done a

296
00:31:41.245 --> 00:31:46.684
bigger deep dive on the trade off models of Spark and Arc specifically

297
00:31:46.684 --> 00:31:51.565
in implementing them in product than most people have. I mean, to the point where

298
00:31:52.524 --> 00:31:56.044
I mean, you asked you mentioned the simplex foundation

299
00:31:56.580 --> 00:31:57.379
earlier.

300
00:31:57.380 --> 00:32:05.539
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.

301
00:32:06.100 --> 00:32:09.220
And when I was talking to him about potential Bitcoin integration,

302
00:32:09.460 --> 00:32:11.779
I literally sent him your

303
00:32:12.635 --> 00:32:15.354
your write up on the two of them. It's like the

304
00:32:15.674 --> 00:32:19.834
it's the write up to read at least at first when you're first diving in. But

305
00:32:20.715 --> 00:32:22.075
I mean, I'm more

306
00:32:22.394 --> 00:32:30.200
I have a better understanding of the trust model of Spark. Is it really my understanding is that the ARC trust model is

307
00:32:30.360 --> 00:32:31.160
requires

308
00:32:31.160 --> 00:32:34.440
less trust in the operator than Spark. Is that not the case?

309
00:32:34.919 --> 00:32:42.015
It's not the case for the average user. The the complication is because Arc's best case trust model is better than Sparks.

310
00:32:42.175 --> 00:32:43.054
In Arc,

311
00:32:43.295 --> 00:32:49.775
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,

312
00:32:51.010 --> 00:32:53.249
It's it looks better on paper,

313
00:32:53.490 --> 00:32:56.450
but the problem is the actual process of joining rounds

314
00:32:56.770 --> 00:33:03.730
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.

315
00:33:04.804 --> 00:33:07.205
It's not something that most of those people are going to do.

316
00:33:07.525 --> 00:33:11.205
I do see this in both the the arcade and the second approaches,

317
00:33:11.285 --> 00:33:16.565
where they're using delegates or Hark signers where they're they're essentially offloading

318
00:33:16.565 --> 00:33:18.085
the VTXO refresh,

319
00:33:19.060 --> 00:33:21.620
but they can't actually get finality for their users.

320
00:33:22.180 --> 00:33:26.100
Because the the process actually joining around just like, I mean, Samurai Wallet,

321
00:33:26.260 --> 00:33:28.820
why didn't they launch Whirlpool on iOS?

322
00:33:29.460 --> 00:33:30.900
Because background

323
00:33:30.980 --> 00:33:38.485
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,

324
00:33:38.805 --> 00:33:42.965
you can't guarantee any execution time in the background. And so the the hardcore,

325
00:33:42.965 --> 00:33:53.479
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

326
00:33:54.360 --> 00:33:59.960
essentially a one of one trust model because the ARC service provider is the only one who has to do something

327
00:34:00.279 --> 00:34:03.480
to double spend funds. In the Spark

328
00:34:03.635 --> 00:34:08.675
trust model, it's right now, one of three will be more as they add more Spark operators,

329
00:34:09.155 --> 00:34:12.435
where if any of those operators are honest,

330
00:34:12.915 --> 00:34:14.355
your funds cannot be stolen.

331
00:34:14.515 --> 00:34:16.435
Do so is the three operators public?

332
00:34:17.140 --> 00:34:19.060
Yeah. Yeah. It's it's

333
00:34:19.060 --> 00:34:20.020
Lightspark,

334
00:34:20.020 --> 00:34:20.820
FlashNet,

335
00:34:20.820 --> 00:34:23.940
who is David Marcus. His son. Yeah. It's his son. Yeah.

336
00:34:24.260 --> 00:34:34.035
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

337
00:34:34.835 --> 00:34:44.035
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.

338
00:34:44.720 --> 00:34:50.240
When you're talking mobile only, that trust model is basically never achievable unless we got covenants in Bitcoin.

339
00:34:50.880 --> 00:34:54.400
And because of that, you fall back to the base level security model where,

340
00:34:55.119 --> 00:35:04.005
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.

341
00:35:04.005 --> 00:35:09.285
You don't have to worry about delegating that refresh off to someone else. It's a much simpler

342
00:35:09.685 --> 00:35:11.525
dev experience at the same time.

343
00:35:12.270 --> 00:35:19.230
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

344
00:35:19.310 --> 00:35:21.390
before I did the deep dive.

345
00:35:21.870 --> 00:35:23.950
Because I, like, ideologically,

346
00:35:23.950 --> 00:35:31.265
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,

347
00:35:31.585 --> 00:35:41.505
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?

348
00:35:44.140 --> 00:35:45.100
They're both

349
00:35:45.340 --> 00:35:46.140
equally.

350
00:35:46.700 --> 00:35:48.940
The operator still is seeing

351
00:35:49.660 --> 00:35:51.820
all your transactions basically. Right?

352
00:35:52.380 --> 00:35:55.820
Yeah. In theory, both could provide good privacy

353
00:35:55.900 --> 00:35:57.100
even from the operator.

354
00:35:57.775 --> 00:36:01.935
In practice, neither do right now. So right now, both have the same trust assumption, which is basically,

355
00:36:02.495 --> 00:36:08.415
I have good privacy from outside observers as long as the operator does not publish my transaction

356
00:36:08.415 --> 00:36:09.295
details.

357
00:36:09.455 --> 00:36:26.410
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.

358
00:36:26.994 --> 00:36:33.475
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

359
00:36:34.035 --> 00:36:35.395
being shared with the world.

360
00:36:36.035 --> 00:36:36.755
And then

361
00:36:37.474 --> 00:36:54.410
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

362
00:36:54.965 --> 00:36:59.125
mean, I I it sounds like the implementation is the same. Are there's a user trusting cake or

363
00:36:59.685 --> 00:37:04.565
a radar operate operators with the transaction graph too? Or is it just

364
00:37:04.885 --> 00:37:06.165
the spark operators?

365
00:37:06.325 --> 00:37:08.805
No. And this one of the nice things and, like, why I

366
00:37:09.400 --> 00:37:15.720
kind of like that we're not running the messaging infrastructure or the payments infrastructure is there is no

367
00:37:15.960 --> 00:37:18.200
single party who has insight into

368
00:37:18.440 --> 00:37:19.400
either side.

369
00:37:19.560 --> 00:37:23.645
So, like, Signal, obviously, they would know your phone number, potentially your username.

370
00:37:23.805 --> 00:37:29.245
They don't know anything about your contacts or your messages. Yay. Intent encryption. Spark, the the entity,

371
00:37:29.885 --> 00:37:32.365
would know that there are some transactions happening.

372
00:37:32.685 --> 00:37:55.565
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,

373
00:37:55.885 --> 00:38:00.765
Signal has absolutely zero visibility into this. They don't even know that there's payments happening, much less that they are

374
00:38:01.190 --> 00:38:15.510
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.

375
00:38:16.925 --> 00:38:26.285
Awesome. I mean, on that note, saw someone commenting on the differences between the signal privacy policy and the radar policy privacy policy.

376
00:38:26.685 --> 00:38:28.125
How should users think about that?

377
00:38:29.790 --> 00:38:32.910
Yeah. I need to I noticed there were a couple things that weren't

378
00:38:34.430 --> 00:38:40.350
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

379
00:38:40.510 --> 00:38:46.195
were just a a thing that we must have caught in our last review pass. So Like a leftover from Kick Wallet? Yeah.

380
00:38:46.275 --> 00:38:55.075
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,

381
00:38:55.635 --> 00:39:08.410
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,

382
00:39:08.650 --> 00:39:14.415
only the Spark entity and Spark operators have any visibility into that. And we don't get any information about your

383
00:39:14.894 --> 00:39:15.695
messages.

384
00:39:16.174 --> 00:39:46.625
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.

385
00:39:46.945 --> 00:39:48.225
Makes sense. So

386
00:39:50.305 --> 00:39:52.945
on the payment side, obviously, you have

387
00:39:53.670 --> 00:40:02.390
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

388
00:40:02.790 --> 00:40:10.045
for you to see your wallet and, like, your transaction history there. For external payments, you give users the ability

389
00:40:10.525 --> 00:40:19.085
to create a lightning address at radar dot cash, which is separate from your signal username. That's a completely different username and namespace.

390
00:40:19.325 --> 00:40:21.405
And then there's a separate backup

391
00:40:21.940 --> 00:40:24.260
scheme, which is effectively a seed,

392
00:40:24.500 --> 00:40:25.620
which presumably

393
00:40:25.780 --> 00:40:30.420
a user could export and import into any other Spark wallet.

394
00:40:32.260 --> 00:40:34.260
I guess my question is,

395
00:40:34.500 --> 00:40:36.020
is that Lightning address

396
00:40:36.345 --> 00:40:39.625
tied to the Signal account or is it tied to

397
00:40:39.945 --> 00:40:41.145
the seed backup?

398
00:40:41.545 --> 00:41:01.540
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.

399
00:41:01.540 --> 00:41:16.295
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

400
00:41:17.255 --> 00:41:29.930
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.

401
00:41:30.755 --> 00:41:37.875
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

402
00:41:38.355 --> 00:42:08.345
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.

403
00:42:12.309 --> 00:42:17.670
Awesome. Yeah. So is that backup that backup separate from encrypted chat backups?

404
00:42:18.230 --> 00:42:20.870
Yeah. Yeah. It's it's only the payment side.

405
00:42:21.270 --> 00:42:30.645
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

406
00:42:30.965 --> 00:42:32.645
radar chat backups,

407
00:42:33.205 --> 00:42:36.085
which I think is a paid feature on signal regular.

408
00:42:36.325 --> 00:43:01.475
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

409
00:43:02.275 --> 00:43:13.690
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?

410
00:43:13.930 --> 00:43:21.130
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,

411
00:43:21.530 --> 00:43:23.690
like, very intentionally, all the donations,

412
00:43:23.770 --> 00:43:39.724
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.

413
00:43:40.640 --> 00:43:46.880
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.

414
00:43:47.280 --> 00:43:51.440
You could just do the backups in iCloud Drive and Google Drive. They're encrypted.

415
00:43:51.680 --> 00:44:05.985
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

416
00:44:06.305 --> 00:44:19.230
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.

417
00:44:20.934 --> 00:44:25.255
Makes sense. I'm kinda pulling us back a tiny bit on the Spark

418
00:44:25.494 --> 00:44:30.375
trade offs because I forgot to bring it up. Grubles, who now works at second,

419
00:44:30.535 --> 00:44:33.174
which is one of the two main ARC implementations,

420
00:44:33.480 --> 00:44:37.720
has been mentioning concerns over Spark's unilateral exit.

421
00:44:38.440 --> 00:44:40.680
This idea that a user, if

422
00:44:41.560 --> 00:44:44.680
can leave the system if without Spark's permission.

423
00:44:45.975 --> 00:44:54.215
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?

424
00:44:55.175 --> 00:45:02.810
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.

425
00:45:03.050 --> 00:45:04.970
So that's the main thing that we've been waiting on.

426
00:45:05.290 --> 00:45:08.890
It does exist as a separate CLI app. So if

427
00:45:09.450 --> 00:45:16.415
if Spark were to suddenly say, like, x user can no longer transact within Spark, you can go to the c a CLI app,

428
00:45:16.735 --> 00:45:29.695
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

429
00:45:30.400 --> 00:45:44.640
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

430
00:45:45.125 --> 00:45:47.285
to be able to make that unilateral exit.

431
00:45:47.605 --> 00:45:52.405
And those aren't cached locally in in any wallet today. So that's the one dependency that exists right now.

432
00:45:52.805 --> 00:46:01.045
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

433
00:46:01.260 --> 00:46:10.460
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.

434
00:46:10.620 --> 00:46:11.340
And not

435
00:46:11.580 --> 00:46:17.345
not to throw Breeze or Spark under the bus, but that was one thing that I was expecting to be live

436
00:46:18.385 --> 00:46:28.785
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

437
00:46:29.150 --> 00:46:43.470
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,

438
00:46:44.255 --> 00:46:52.335
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.

439
00:46:53.135 --> 00:47:03.430
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.

440
00:47:03.510 --> 00:47:20.224
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

441
00:47:20.385 --> 00:47:34.030
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,

442
00:47:34.910 --> 00:47:38.190
yeah, it'll definitely be possible in mobile. And basically, it would just be a one time

443
00:47:39.405 --> 00:47:46.525
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

444
00:47:47.165 --> 00:47:50.765
spendable because of the time locks that are associated with them. Think something like But, two weeks

445
00:47:51.645 --> 00:47:54.765
yeah, if it's an emergency exit, you don't really care. You just wanna get your money back.

446
00:47:55.700 --> 00:48:03.619
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,

447
00:48:03.700 --> 00:48:09.619
bull Bitcoin being one of them, Aqua, MANA, is was is using liquid as the as basically

448
00:48:10.365 --> 00:48:14.445
the back end. Mhmm. What is your opinion on on that?

449
00:48:17.165 --> 00:48:21.485
I mean, to me, both Spark and Arc kind of obsolete liquid.

450
00:48:22.140 --> 00:48:25.900
Liquid is just a it's a pure multi sig custodian.

451
00:48:25.900 --> 00:48:30.140
The only real advantage to liquid is that there is some base privacy,

452
00:48:30.380 --> 00:48:33.099
because you can do confidential amounts and confidential tokens,

453
00:48:33.660 --> 00:48:35.115
which is a nice ad,

454
00:48:35.115 --> 00:48:38.955
but there's not significantly better privacy? I mean, you're the privacy guy.

455
00:48:40.315 --> 00:48:48.635
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

456
00:48:49.539 --> 00:49:03.220
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

457
00:49:03.725 --> 00:49:05.405
go on if it does

458
00:49:05.645 --> 00:49:07.565
gain very broad adoption.

459
00:49:08.205 --> 00:49:11.885
Because when you do mix privacy with custody, you're kind of

460
00:49:12.365 --> 00:49:15.805
the ultimate in the crosshairs of every regulator in the world.

461
00:49:17.100 --> 00:49:24.700
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

462
00:49:25.100 --> 00:49:40.545
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

463
00:49:40.945 --> 00:49:42.385
your liquid Bitcoin.

464
00:49:42.705 --> 00:49:43.105
Yeah.

465
00:49:44.065 --> 00:49:44.465
I mean, I

466
00:49:45.700 --> 00:49:50.260
I love the privacy it brings. It to me, it just has it's like a better version of eCash

467
00:49:50.260 --> 00:49:55.380
in terms of custody. We're like, it's a better custody model. It's more like Fediments, has reasonably good privacy.

468
00:49:55.860 --> 00:49:56.340
But

469
00:49:56.934 --> 00:50:03.255
I think that Spark and Arc can take clear meaningful steps to become similarly private.

470
00:50:03.575 --> 00:50:05.815
And so I think that's much more interesting

471
00:50:06.055 --> 00:50:10.990
because if we can bring the better trust models of Spark and Arc with good privacy,

472
00:50:11.070 --> 00:50:21.470
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.

473
00:50:21.790 --> 00:50:23.710
Within Arc, can do some blinded

474
00:50:23.985 --> 00:50:26.065
blinded credential stuff within ARC.

475
00:50:26.225 --> 00:50:29.425
Spark, you can do blind signing, which would give complete

476
00:50:29.985 --> 00:50:33.825
privacy from the operator, which would be massive. Do you think that's gonna happen?

477
00:50:37.185 --> 00:50:38.305
I hope so.

478
00:50:38.799 --> 00:50:46.000
There's been some signs that Spark is going to continue implementing more privacy into their solution. Blind signing obviously is

479
00:50:47.039 --> 00:50:49.040
so complete that I I

480
00:50:49.440 --> 00:50:52.400
would guess it probably wouldn't happen in Lightspark's Spark entity,

481
00:50:53.055 --> 00:50:57.295
but it would raise the question of will someone start another Spark entity that does blind signing?

482
00:50:57.695 --> 00:51:00.655
Technologically, it's quite possible. And if someone did start that,

483
00:51:00.974 --> 00:51:02.895
it would be an interesting competitive

484
00:51:03.055 --> 00:51:14.080
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.

485
00:51:14.400 --> 00:51:16.960
I presume you'd be open to

486
00:51:18.640 --> 00:51:19.120
moving

487
00:51:19.704 --> 00:51:23.865
either to different Spark operators or potentially even Arc

488
00:51:24.345 --> 00:51:27.305
Yeah. For radar users and Cakewallet users, like,

489
00:51:27.865 --> 00:51:30.345
the given improvements or whatnot.

490
00:51:30.665 --> 00:51:33.385
For sure. Yeah. And one of the really nice things about all these is,

491
00:51:34.310 --> 00:51:41.270
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

492
00:51:41.990 --> 00:51:42.950
is usable.

493
00:51:44.550 --> 00:51:56.875
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

494
00:51:56.875 --> 00:51:58.235
or something like this. So

495
00:51:59.035 --> 00:52:23.185
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

496
00:52:23.665 --> 00:52:33.450
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.

497
00:52:34.730 --> 00:52:35.609
Makes sense.

498
00:52:37.609 --> 00:52:38.970
You mentioned earlier

499
00:52:41.495 --> 00:52:42.855
USD tokens.

500
00:52:42.855 --> 00:52:48.775
I think you call them stable balances. Is that the plan? Is the plan to make this Bitcoin

501
00:52:49.175 --> 00:52:51.255
and USD tokens,

502
00:52:51.255 --> 00:52:53.895
and that's that on the wallet side and payment side?

503
00:52:55.110 --> 00:52:58.630
Yeah. I mean, definitely no other, like, cryptocurrencies planned. I

504
00:52:59.910 --> 00:53:03.990
don't think there would be any reason to add other cryptocurrencies or other chains.

505
00:53:05.430 --> 00:53:21.335
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

506
00:53:22.135 --> 00:53:23.095
is really nice.

507
00:53:24.030 --> 00:53:31.070
And they still have self custody over the keys. Obviously, stablecoins introduce other trust assumptions where depending on the stablecoin, they can be frozen.

508
00:53:32.270 --> 00:53:33.390
They often are.

509
00:53:33.790 --> 00:53:38.510
Yeah. They often are. So there there are caveats with that, and obviously, we would inform users of that.

510
00:53:39.444 --> 00:53:45.605
The the benefit there for most people who we envision using radar long term to make it feel much more like a

511
00:53:46.325 --> 00:53:47.525
a regular

512
00:53:47.684 --> 00:53:49.445
payments app rather

513
00:53:49.525 --> 00:53:51.204
than this hardcore Bitcoin thing,

514
00:53:52.200 --> 00:53:57.640
I think is an ideal crossover. So that is the vision that it will be either Bitcoin denominated or

515
00:53:57.960 --> 00:54:10.204
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.

516
00:54:10.765 --> 00:54:12.845
You wouldn't have both in the same wallet.

517
00:54:13.404 --> 00:54:17.405
So you would you would be able to choose, but you couldn't have both at the same time.

518
00:54:17.724 --> 00:54:21.565
Your balance would be either entirely in stable coins or entirely in Bitcoin. Why?

519
00:54:23.079 --> 00:54:23.960
Simplicity.

520
00:54:25.160 --> 00:54:31.720
But is that how most people interact with their daily lives? I mean, least right now, it's like they have dollars and Bitcoin.

521
00:54:33.320 --> 00:54:35.960
Yes. But they're also two very disparate things.

522
00:54:36.575 --> 00:54:40.655
Like, when you're thinking through a product and you're thinking how is a user going to

523
00:54:40.975 --> 00:54:58.910
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,

524
00:54:59.070 --> 00:55:14.075
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

525
00:55:14.555 --> 00:55:15.355
Bitcoin

526
00:55:15.595 --> 00:55:18.395
and I send a payment to someone whose dollars,

527
00:55:18.750 --> 00:55:20.270
it would just automatically

528
00:55:20.830 --> 00:55:22.830
on the fly just do the swap.

529
00:55:23.070 --> 00:55:31.550
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

530
00:55:31.790 --> 00:55:33.550
on Spark called FlashNet

531
00:55:33.975 --> 00:55:35.255
That does the conversion.

532
00:55:35.495 --> 00:55:42.055
That was that's David's son's company. Mhmm. Yeah. So so USD tokens are live on Spark right now?

533
00:55:42.455 --> 00:55:51.330
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

534
00:55:51.650 --> 00:55:52.050
But

535
00:55:53.250 --> 00:55:58.770
in in this specific scenario where the goal is not paying any other crypto user,

536
00:55:59.170 --> 00:56:06.125
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,

537
00:56:06.125 --> 00:56:13.725
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?

538
00:56:14.285 --> 00:56:16.445
Yeah. Yeah. B r a l e.

539
00:56:17.180 --> 00:56:18.460
0, with a b?

540
00:56:19.020 --> 00:56:25.580
Yeah. Yeah. Rail. Sorry. Yeah. Oh, like how blind people read? But not spelled that way. Got it.

541
00:56:29.184 --> 00:56:29.984
Fair enough.

542
00:56:31.105 --> 00:56:32.305
Okay.

543
00:56:32.305 --> 00:56:35.345
So what what about have have you I mean,

544
00:56:36.065 --> 00:56:37.984
in USD token land,

545
00:56:38.145 --> 00:56:47.530
like, king is a tether on Tron, and maybe the king in the Western world among big tech folks is like USDC on base.

546
00:56:48.170 --> 00:56:49.450
Yeah, obviously,

547
00:56:49.530 --> 00:56:57.210
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.

548
00:56:57.850 --> 00:56:58.090
The

549
00:56:58.914 --> 00:57:03.234
obviously your average user who's using these that your average dollar user,

550
00:57:03.795 --> 00:57:06.195
which if you want to talk about network effects is obviously

551
00:57:06.355 --> 00:57:06.994
the

552
00:57:07.234 --> 00:57:12.194
largest network effect of of currencies right now is probably interacting

553
00:57:12.194 --> 00:57:15.280
with either Tron on Tether or USDC on base.

554
00:57:15.599 --> 00:57:18.480
How do you think about that flow? Are you going to give them

555
00:57:18.880 --> 00:57:19.760
an ad

556
00:57:20.160 --> 00:57:23.920
a deposit and withdrawal flow that goes to those chains?

557
00:57:23.920 --> 00:57:24.480
Or

558
00:57:24.800 --> 00:57:27.680
are they can only get out with Bitcoin? Or how does that look?

559
00:57:29.235 --> 00:57:34.835
Yeah. I have definitely thought about that. The plan is to do it similar to how we do Anypay and Cake Wallet,

560
00:57:34.995 --> 00:57:35.475
where

561
00:57:37.555 --> 00:57:46.090
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

562
00:57:46.650 --> 00:57:53.210
over engineered and bloated if we do that. So trying to keep it very limited in scope. So using one provider,

563
00:57:53.530 --> 00:57:59.450
the goal is to allow you to add funds from any stablecoin

564
00:57:58.965 --> 00:58:02.245
into it, and it will automatically be converted into Bitcoin on Spark and

565
00:58:02.645 --> 00:58:05.205
send to any stable coin on any chain.

566
00:58:05.765 --> 00:58:08.245
Got Again, not trying to do everything.

567
00:58:08.645 --> 00:58:17.340
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.

568
00:58:17.340 --> 00:58:19.100
That's a very different target audience.

569
00:58:19.500 --> 00:58:32.365
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,

570
00:58:33.005 --> 00:58:39.485
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

571
00:58:40.040 --> 00:58:58.485
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.

572
00:58:58.645 --> 00:59:02.245
Apple Pay to add funds? Or Yeah.

573
00:59:03.445 --> 00:59:07.840
Yeah. For sure. For sure. Yeah. Again Is is that the main monetization

574
00:59:07.840 --> 00:59:11.280
scheme for Radar as a company? Is the

575
00:59:11.840 --> 00:59:12.960
the the

576
00:59:13.440 --> 00:59:15.120
swaps in and out, basically?

577
00:59:16.480 --> 00:59:22.035
Yeah. The initial the initial idea is the the on and off ramping. Obviously, one's straightforward.

578
00:59:22.115 --> 00:59:23.955
These swaps between currencies,

579
00:59:23.955 --> 00:59:27.315
the swaps between Bitcoin and stable coins as people go back and forth,

580
00:59:27.795 --> 00:59:35.234
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

581
00:59:36.280 --> 00:59:42.440
a good long term sustainability play, but that's still too early in discovery to kinda talk more details about it. But,

582
00:59:43.559 --> 00:59:59.465
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

583
00:59:59.625 --> 01:00:01.130
be the the game plan.

584
01:00:01.770 --> 01:00:06.250
And it's not transaction fee. Are you gonna take a cut of transaction fees between users?

585
01:00:06.650 --> 01:00:10.810
No. No. No. The only fee there is just the base Spark fee, which is two sets.

586
01:00:11.610 --> 01:00:12.730
Is that hard coded?

587
01:00:13.724 --> 01:00:19.964
It is. Yeah. Don't ask me why it's two sets. It's very interesting. What's double double one set? It

588
01:00:20.204 --> 01:00:24.525
is. So just every Spark transaction is a two set fee regardless of amount? Yeah.

589
01:00:25.340 --> 01:00:26.220
Fascinating.

590
01:00:26.220 --> 01:00:37.260
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.

591
01:00:37.925 --> 01:00:39.525
And who runs that node?

592
01:00:40.005 --> 01:00:41.765
Does Spark run that node?

593
01:00:42.244 --> 01:00:46.645
The the lighting service provider side? Yeah. Yeah. Light Spark runs it.

594
01:00:47.685 --> 01:00:57.610
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?

595
01:00:57.770 --> 01:01:01.450
No. The plan is to have more. I've been talking to them about it because, like, I specifically,

596
01:01:01.450 --> 01:01:12.365
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,

597
01:01:12.365 --> 01:01:13.965
their dependency is Bolt's They

598
01:01:14.365 --> 01:01:16.924
live or die by Bolt's. Yeah. So that that is definitely

599
01:01:17.885 --> 01:01:24.190
it's going to happen. The Spark guys have been keeping it limited initially while they just get everything really stable,

600
01:01:24.349 --> 01:01:32.670
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,

601
01:01:32.990 --> 01:01:36.925
as well as more Spark operators to keep growing that that decentralization

602
01:01:36.925 --> 01:01:37.805
side of things.

603
01:01:38.444 --> 01:01:39.325
Technically,

604
01:01:39.325 --> 01:02:04.155
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

605
01:02:04.235 --> 01:02:05.755
do that and it is that

606
01:02:05.995 --> 01:02:12.075
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.

607
01:02:12.475 --> 01:02:24.530
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.

608
01:02:24.849 --> 01:02:27.490
There hasn't really been that much demand for,

609
01:02:28.849 --> 01:02:35.295
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,

610
01:02:35.535 --> 01:02:41.615
like, David Marcus deals with your regulatory concerns and all of your technical concerns. It's like, he just handles all

611
01:02:41.695 --> 01:02:44.080
the hard just don't have to worry about it. Yeah.

612
01:02:44.240 --> 01:02:45.520
For sure. For sure.

613
01:02:45.920 --> 01:02:46.960
Okay. Awesome.

614
01:02:47.280 --> 01:02:50.880
Seth, I think this is a great conversation to the freaks at home.

615
01:02:51.440 --> 01:02:54.560
You're not seeing any videos, so you're not aware that Seth

616
01:02:54.960 --> 01:03:08.135
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

617
01:03:08.615 --> 01:03:10.455
mention to the freaks before we wrap here?

618
01:03:11.410 --> 01:03:35.895
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

619
01:03:36.295 --> 01:03:51.830
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.

620
01:03:52.805 --> 01:03:59.205
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

621
01:03:59.765 --> 01:04:07.285
stuffy voice. So Love it. Well, thank you for joining us. Thank you for building Radar and Cake. I absolutely love it. Freaks,

622
01:04:08.090 --> 01:04:13.770
thank you to all who support the show. As always, all the relevant links are cieldispatch.com.

623
01:04:14.410 --> 01:04:20.970
It's available on every podcast app. You can search ciel dispatch in your favorite podcast app. Share with friends and family.

624
01:04:21.744 --> 01:04:40.200
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.

625
01:04:40.200 --> 01:04:42.599
And then I have some great shows lined up after that, so

626
01:04:43.000 --> 01:04:47.400
stay tuned for that. Love you all. Stay on the Stack Sets. Peace.