CD206: ERIC SIRION, JOSCHA, AND HERMANN - FEDIMINT IN THE WILD

WEBVTT

NOTE
Transcription provided by Podhome.fm
Created: 06/30/2026 18:21:34
Duration: 4312.869
Channels: 1

1
00:00:31.510 --> 00:00:37.750
Happy Bitcoin Tuesday, freaks. It's your host, Odell, here for another Citadel Dispatch.

2
00:00:37.910 --> 00:00:40.390
The show focused on actionable

3
00:00:40.710 --> 00:00:43.270
freedom tech and Bitcoin discussion.

4
00:00:44.204 --> 00:00:45.565
I know it's been

5
00:00:46.125 --> 00:00:49.245
a few weeks since our last show. As you guys know,

6
00:00:49.885 --> 00:00:55.324
Dispatch is audience funded and supported by viewers like you. We have no ads or sponsors.

7
00:00:56.364 --> 00:00:58.844
So I only really like shipping when

8
00:00:59.090 --> 00:01:11.729
we have interesting conversation. I don't wanna waste your guys' time. I don't have to, like, promise the sponsors, you know, three episodes a week. But we have a great show lined up today. I got a great show lined up for next week. I know vibes out there might be a little bit bearish right now.

9
00:01:12.495 --> 00:01:15.135
Today is Tuesday, June 30.

10
00:01:16.015 --> 00:01:18.015
The current time

11
00:01:18.095 --> 00:01:20.495
is sixteen hundred UTC.

12
00:01:20.495 --> 00:01:24.255
You'll be listening to this in a couple hours. I just immediately

13
00:01:24.255 --> 00:01:28.470
post it. Current block height is nine five six zero eight seven.

14
00:01:29.189 --> 00:01:32.229
Bitcoin price is $58,300.

15
00:01:32.790 --> 00:01:34.470
Sats per USD

16
00:01:34.470 --> 00:01:35.189
is

17
00:01:35.509 --> 00:01:37.909
1,714.

18
00:01:38.854 --> 00:01:40.454
Largest zap from

19
00:01:40.455 --> 00:01:43.415
last episode. We had Jason from Tondo on

20
00:01:43.895 --> 00:01:45.975
spending Bitcoin anywhere in Kenya

21
00:01:46.295 --> 00:01:49.255
was 10,000 sets from PGS

22
00:01:49.255 --> 00:01:50.055
design.

23
00:01:50.854 --> 00:01:52.854
You can support the show or

24
00:01:53.470 --> 00:01:55.870
all the relevant links are at citaldispatch.com.

25
00:01:55.870 --> 00:01:59.390
Share with your friends and family. Search cital dispatch in your favorite podcast app.

26
00:02:00.030 --> 00:02:02.350
I know people I know money's tight right now.

27
00:02:02.910 --> 00:02:04.430
So if you can't spare the stats,

28
00:02:05.085 --> 00:02:11.405
Single best thing you can do to support the show is share it with friends and family. Open up their phone, search civil dispatch in their podcast app, click subscribe.

29
00:02:11.965 --> 00:02:21.060
They won't know what hit them. Next thing they know, they'll just have back to back episodes about Bitcoin in Africa. And they'll be wondering what their nephew did on their phone when they weren't looking.

30
00:02:21.540 --> 00:02:27.700
So thank you freaks for continuing to support the show. Anyway, I kind of gave you a teaser. Today, we're talking about Fetamin.

31
00:02:28.420 --> 00:02:29.380
Specifically,

32
00:02:29.380 --> 00:02:34.645
we've talked about Fetamin many times on the show, the open source project that allows anyone

33
00:02:34.645 --> 00:02:46.485
to create a multisig federation to make it easier to use Bitcoin in a freedom oriented way. In the past, we've had more technical conversations about the open source protocol

34
00:02:46.670 --> 00:02:53.950
and the wallets that are being built out on top of it. But today, we're gonna actually be talking about it being used in practice in South Africa.

35
00:02:55.470 --> 00:02:59.390
I have three guests to join us here. We have Eric Sirion,

36
00:02:59.709 --> 00:03:01.150
who is

37
00:03:02.075 --> 00:03:04.795
the the creator, the man behind

38
00:03:05.115 --> 00:03:07.275
the original Federment spec.

39
00:03:07.595 --> 00:03:08.875
How's it going, Eric?

40
00:03:09.675 --> 00:03:18.340
Great. Thank you. Great to be back on the show. I think it has been quite a while that I've actually been here myself.

41
00:03:18.740 --> 00:03:20.500
Must have been at least two years.

42
00:03:20.819 --> 00:03:23.860
We had you, like, right in the beginning. Right? Yeah. Exactly.

43
00:03:24.260 --> 00:03:28.740
And then in the meantime, some other contributors joined on some great shows.

44
00:03:29.905 --> 00:03:33.985
Yeah. But feels great to be back, and thanks for having us.

45
00:03:34.944 --> 00:03:39.185
Love it. I should have asked you how to pronounce your name ahead of time, but we have Joshua.

46
00:03:39.185 --> 00:03:42.670
Is that how I pronounce your name? Yeah. Yeah. That's about right.

47
00:03:43.550 --> 00:03:50.030
He's a contributor he's a contributor to Fediment and has been instrumental. My understanding, you've been instrumental in

48
00:03:50.430 --> 00:04:00.765
the iRow integration. That makes it much easier to run these Guardians in a I would say, Joshua is the mastermind behind Fatemin as it is today. Like, I got it started,

49
00:04:00.925 --> 00:04:05.644
but Joshua brought it to the point where it could actually be rolled out and deployed in the wild.

50
00:04:06.730 --> 00:04:07.530
Yeah.

51
00:04:08.410 --> 00:04:12.490
Legendary. Done a lot of Welcome to the show. Lot of cool stuff. Well, thanks.

52
00:04:14.010 --> 00:04:15.210
And then we have,

53
00:04:15.690 --> 00:04:18.650
on the topic of mispronouncing names, we have Erman here

54
00:04:19.095 --> 00:04:22.695
from Bitcoin Acaci, return guest and good friend. How's it going, sir?

55
00:04:23.495 --> 00:04:30.375
Yeah. It's going awesome, man. Yeah. We had we had the name conversation last time, but you you pronounced it really well, man. Don't don't stress about it.

56
00:04:31.250 --> 00:04:37.730
I'm working on it. I'm working on it. So you guys are running a federation in the wild in South Africa now?

57
00:04:38.450 --> 00:04:47.250
Yeah. Yeah. We're doing we we've been running it for a couple of in in fact, it's the second one. The first federation we set up was a test federation, but

58
00:04:47.035 --> 00:04:49.195
second one we set up is actually being

59
00:04:49.995 --> 00:04:58.155
used. I mean, I've been using it on almost a daily basis and it's just, it works insanely well. I still can't believe it. Every time I make a transaction,

60
00:04:58.990 --> 00:05:01.470
It's hard to believe that it just runs.

61
00:05:04.110 --> 00:05:07.470
Kinda love that. Yeah, go ahead. I've actually been using that one too,

62
00:05:07.710 --> 00:05:08.830
because sometimes,

63
00:05:08.990 --> 00:05:10.830
like some other federations,

64
00:05:10.830 --> 00:05:13.550
I might not have good connectivity to them or whatever,

65
00:05:13.710 --> 00:05:15.310
but

66
00:05:14.615 --> 00:05:15.975
surprisingly enough,

67
00:05:16.135 --> 00:05:17.575
the one in South Africa,

68
00:05:17.735 --> 00:05:18.775
it nearly

69
00:05:19.095 --> 00:05:22.295
always works. And it's just amazing to see it.

70
00:05:22.615 --> 00:05:25.735
Like the one that's being just run at home, it's super reliable.

71
00:05:26.870 --> 00:05:27.750
Yeah.

72
00:05:29.430 --> 00:05:31.990
Yeah, so the one in South Africa, the

73
00:05:32.310 --> 00:05:39.350
new one that we're running now, it's a five out of seven Garion Federation, so two of them can go down and I think that definitely improves

74
00:05:39.590 --> 00:05:40.710
reliability.

75
00:05:40.790 --> 00:05:42.150
So far it already seems

76
00:05:42.845 --> 00:05:48.525
much more reliable than the three out of four one we have been we've been running before that just to test.

77
00:05:49.965 --> 00:05:50.525
Yeah.

78
00:05:51.245 --> 00:05:54.685
So, that the largest is that the largest federation

79
00:05:54.765 --> 00:05:55.645
in the wild?

80
00:05:57.620 --> 00:05:59.940
I think largest that we know of.

81
00:06:00.340 --> 00:06:06.740
A few first things that come together here, yeah, first five out of seven that runs exclusively on Start Nines.

82
00:06:07.620 --> 00:06:08.500
That's so cool.

83
00:06:09.955 --> 00:06:13.315
And, oh, yeah, first 5.07 to run on iROL.

84
00:06:14.275 --> 00:06:14.835
Yeah.

85
00:06:15.395 --> 00:06:17.075
Yeah. So let's so,

86
00:06:17.555 --> 00:06:19.875
mean, that's been a big thing, right, is

87
00:06:20.355 --> 00:06:29.800
in the early days of Fediment first, you had to run them on you had to run them on VPSs. You had to run them on cloud servers, and there was also a DNS requirement.

88
00:06:29.960 --> 00:06:31.960
And a couple of the early test ones,

89
00:06:33.960 --> 00:06:38.920
you know, it it became a kind of a mess. And mostly because of DNS requirement,

90
00:06:38.920 --> 00:06:39.320
but also

91
00:06:40.175 --> 00:06:50.175
due to the complexity of of running it on a cloud server. IRO in the iRO integration, correct me if I'm wrong, it kind of tries to mitigate both of those friction points. Right?

92
00:06:50.815 --> 00:06:51.775
Exactly.

93
00:06:52.095 --> 00:06:52.895
Exactly.

94
00:06:52.975 --> 00:06:53.295
Yeah.

95
00:06:53.880 --> 00:07:05.320
It makes it much easier to set it up because you don't have to touch networking at all. It makes it much more secure because everything is end to end encrypted with static public keys now. So you don't rely on like

96
00:07:05.960 --> 00:07:06.440
external

97
00:07:07.225 --> 00:07:20.105
providers to encrypt. It makes it much easier to like port and move the machine around because the public key just follows you and you can now run it basically on every, on any box that has internet. It's just going to find a connection.

98
00:07:20.990 --> 00:07:23.470
Yeah. So I can just like have my like,

99
00:07:24.350 --> 00:07:27.710
start nine running a Guardian in my pickup truck,

100
00:07:28.669 --> 00:07:34.284
and I can just like drive around with Starlink and then I don't have to worry about anything. Yes,

101
00:07:34.284 --> 00:07:39.645
exactly. So the IRA library in the background, it's actually very advanced networking.

102
00:07:39.645 --> 00:07:45.565
So it's gonna, it's gonna use all network interfaces that are available to it. So wifi,

103
00:07:45.565 --> 00:07:46.365
mobile,

104
00:07:46.444 --> 00:07:53.400
etcetera. And it will like switch between them and load balance over them automatically to always give you the strongest,

105
00:07:54.040 --> 00:07:56.040
strongest possible connection. So

106
00:07:56.920 --> 00:07:59.000
we have set up federations

107
00:07:59.000 --> 00:08:00.200
where

108
00:08:01.175 --> 00:08:03.495
Eric was on a mobile

109
00:08:04.215 --> 00:08:04.935
network

110
00:08:05.254 --> 00:08:08.135
in a lobby in Nairobi, I think, and that also

111
00:08:08.455 --> 00:08:20.010
works just the Yeah. Think it was across like three different continents. I was Yeah. In the hotel in Nairobi where on the Starlink, I think in South Africa, actually. And then another

112
00:08:20.730 --> 00:08:27.370
guy was in The US on, like, I think both a Starlink and some other connection. And it just worked perfectly fine.

113
00:08:28.495 --> 00:08:36.895
Yeah. That's really cool. And I mean, specifically, I guess and that's an interesting point you made. So you have the larger federation. You have five zero seven instead of 304.

114
00:08:36.895 --> 00:08:39.295
With the with the three zero four, if

115
00:08:40.220 --> 00:08:49.820
two people went down, if two of the guardians lost self reception or whatever, the whole thing just ground to a stop, like you didn't lose your money. But anyone who's using

116
00:08:49.980 --> 00:08:52.940
a wallet connected to that federation just couldn't send or receive.

117
00:08:53.865 --> 00:09:00.345
And so five zero seven, it means three people would have to disconnect for three guardians would have to disconnect

118
00:09:00.505 --> 00:09:02.345
for the users not to

119
00:09:02.665 --> 00:09:11.390
have access. Does that add additional complexity? Is there concern there? Know, you have like more? I mean, just more people. Like, if you have more people that you have to

120
00:09:11.790 --> 00:09:15.710
coordinate things with, usually, that adds some element of complexity.

121
00:09:17.070 --> 00:09:25.345
Yeah. And I would say this is probably the main one main reason why federations aren't larger right now, like just the coordination complexity.

122
00:09:25.345 --> 00:09:31.985
And but I think over the long run, we will be seeing it pushed towards larger and larger federations

123
00:09:31.985 --> 00:09:35.105
just because it brings way better reliability

124
00:09:35.105 --> 00:09:36.865
and safety for users.

125
00:09:37.185 --> 00:09:39.370
But I think it's a good segue to

126
00:09:40.090 --> 00:09:46.970
ask Herman and Jascha, what was your experience in setting up the federation? You had to coordinate

127
00:09:47.530 --> 00:09:48.170
seven people.

128
00:09:49.865 --> 00:09:56.584
I didn't do much. Think I was like tech I was there's tech support, but they figured it out by themselves.

129
00:09:58.985 --> 00:10:00.985
Mean, it I I was

130
00:10:01.385 --> 00:10:06.660
I I think I mentioned this before, but I I was very surprised by how straightforward it was.

131
00:10:07.540 --> 00:10:09.940
There's there's at least three people

132
00:10:10.980 --> 00:10:12.260
on the federation,

133
00:10:12.900 --> 00:10:16.660
whose three guardians in the federation that like me are,

134
00:10:18.045 --> 00:10:24.685
not technical at all. We like to experience pain. So we figure things out if we have to,

135
00:10:25.165 --> 00:10:27.485
but it's as close as you're gonna get to

136
00:10:28.125 --> 00:10:33.245
I mean, I was talking to people in Nairobi this weekend. I was in Kenya and I was trying to describe

137
00:10:34.420 --> 00:10:40.980
how easy it is to set up, and literally anyone could do it. It is a bit of a coordination effort, so you gotta get people together

138
00:10:41.380 --> 00:10:42.660
to go through that.

139
00:10:43.139 --> 00:10:45.699
But it's relatively easy in terms of

140
00:10:47.165 --> 00:10:59.005
figuring it out. It's really, really quite straightforward. And I think it's also interesting that, I mean, we've got relatively unreliable internet here, and I've been surprised by how well it runs. I was expecting

141
00:10:59.990 --> 00:11:08.070
to have issues with making transactions on a regular basis, like at least a couple of transactions maybe not work, but I've not had a single

142
00:11:08.790 --> 00:11:10.390
Lightning transaction fail.

143
00:11:10.710 --> 00:11:13.270
Every single transaction I've made has gone through

144
00:11:14.144 --> 00:11:15.585
without a glitch. And

145
00:11:16.065 --> 00:11:20.225
we have some people that are not using fiber internet. I think there's

146
00:11:20.785 --> 00:11:23.265
three or four guardians that are not on fiber.

147
00:11:23.904 --> 00:11:25.425
They're on some kind of wireless.

148
00:11:26.579 --> 00:11:30.100
Yeah. Either on mobile or wireless

149
00:11:30.500 --> 00:11:31.300
internet.

150
00:11:32.180 --> 00:11:33.300
So it's

151
00:11:33.620 --> 00:11:35.540
not a reliable connection and

152
00:11:35.620 --> 00:11:37.860
still somehow it just works.

153
00:11:38.654 --> 00:11:42.894
That's wild. So what does that look like? And I mean, and just to confirm, like,

154
00:11:43.615 --> 00:12:04.030
like, Arman's video is is the worst quality out of all of ours on this call right now. He clearly has he clearly has shit Internet over there. So, like, what what is it What does it look like in practice for this setup? Can you just like walk through what that setup flow looks to the to to a guardian to someone who is is gonna potentially set up guardians?

155
00:12:04.670 --> 00:12:07.630
I mean, at the moment, I think the hardest part was actually

156
00:12:07.964 --> 00:12:13.485
having to sideload the Federment application on the Start9. There's

157
00:12:13.485 --> 00:12:15.725
no one click install button yet. But

158
00:12:16.285 --> 00:12:19.404
other than that, it was a click through process. You

159
00:12:20.120 --> 00:12:29.640
you you sideload know, the the obviously, you've gotta you've gotta install the the Bitcoin node, and then you've gotta sync that, which can be a little bit of a pain point if you have shitty internet.

160
00:12:30.200 --> 00:12:38.185
But I don't think that took longer than a week. In the worst case, I did it in a couple of days. And then once that's done, you sideload the

161
00:12:38.745 --> 00:12:40.425
fediment package. And then

162
00:12:40.665 --> 00:12:41.225
you

163
00:12:41.705 --> 00:12:42.905
have to pick a time

164
00:12:43.305 --> 00:12:44.265
where all

165
00:12:44.585 --> 00:12:48.680
seven guardians are kind of online and able to exchange

166
00:12:49.160 --> 00:12:52.440
their guardian codes, and you add that to your

167
00:12:53.560 --> 00:12:58.519
Federmen user interface, and that's pretty much it. I mean, how do you the

168
00:12:59.319 --> 00:13:02.095
codes are what? Copy and paste through like a chat or Copy

169
00:13:02.495 --> 00:13:07.615
paste into a chat. Yeah. You've got a I mean, we did we

170
00:13:07.615 --> 00:13:10.495
used signal to exchange those codes and

171
00:13:11.215 --> 00:13:20.350
that was about it. Other than sideloading the Fetiman package, the most complicated part was not to get confused whose code belongs to who. I mean, that's about as complex

172
00:13:20.830 --> 00:13:23.630
as it is. So it really is at a point where

173
00:13:24.190 --> 00:13:26.430
just about anyone can do it. I mean,

174
00:13:27.070 --> 00:13:32.665
I think the most challenging part is maybe not even the internet connectivity, but keeping

175
00:13:33.065 --> 00:13:37.065
the thing powered on because we've got power cuts as well from time to time. And so

176
00:13:37.465 --> 00:13:38.505
you'd

177
00:13:38.505 --> 00:13:41.305
have to factor that in to get some sort of a UPS

178
00:13:42.250 --> 00:13:42.890
As battery

179
00:13:44.330 --> 00:13:46.650
long as three of the seven as long as

180
00:13:47.290 --> 00:13:47.850
five

181
00:13:48.250 --> 00:13:54.089
of the seven have power, you're good. Yeah. As three of the seven, I would have to lose power and not have battery backup

182
00:13:54.705 --> 00:13:56.065
for it to go on I

183
00:13:56.945 --> 00:14:01.665
would say that's actually like the biggest selling point because, like, Fedement

184
00:14:01.745 --> 00:14:10.380
takes on all the complexity of providing a very reliable service, like something where you'd otherwise be paying big cloud providers like Google or AWS,

185
00:14:10.380 --> 00:14:12.940
like big bucks to have high availability.

186
00:14:13.180 --> 00:14:14.860
It's built into the protocol.

187
00:14:15.020 --> 00:14:17.580
So it can actually run on less reliable hardware.

188
00:14:17.899 --> 00:14:23.845
Like, all the notes in a box or or notes running at home, they are not high availability fundamentally.

189
00:14:24.805 --> 00:14:26.405
But if you still want to keep,

190
00:14:26.885 --> 00:14:35.205
like, significant amounts of money on there, they need some way of ensuring the high availability, and that's exactly what Credit Union gives you. And also one happy news,

191
00:14:35.840 --> 00:14:38.800
like you were a very early adopter in South Africa,

192
00:14:39.120 --> 00:14:44.560
so you had to sideload. But by now, like the version that you're running, it's all in the community store

193
00:14:44.800 --> 00:14:55.095
on Stat 9. And so it's not as cumbersome anymore. I think You literally just pressed down the cutting edge app store. Exactly. Yeah. Like, it just recently did that and

194
00:14:55.415 --> 00:15:06.295
it works perfectly. Yeah. I wanted to clarify that as well. It's like the only reason he sideloaded is because we didn't wanna wait two or three weeks after the release for it to hit the

195
00:15:06.730 --> 00:15:11.210
registry. Everyone else would just like download it from there, and then it should be fine right away.

196
00:15:12.170 --> 00:15:13.690
Yeah, by the way, I

197
00:15:15.290 --> 00:15:18.090
know it can be a mental burden, but I do think it's,

198
00:15:18.330 --> 00:15:23.765
I like how they made sideloading on Star nine a First Class Citizen, especially with the vibe coding stuff.

199
00:15:24.325 --> 00:15:27.285
Like, you can just have your clanker, like, make shit and then just

200
00:15:27.765 --> 00:15:31.205
pop it onto your start nine, which is pretty cool. The other piece

201
00:15:31.525 --> 00:15:32.325
there

202
00:15:32.805 --> 00:15:38.630
so it sounds like it's relatively easy to set up, which is awesome. I always I mean, Eric knows from the very beginning,

203
00:15:38.870 --> 00:15:42.790
I thought the success of this project ride or died on ease

204
00:15:42.790 --> 00:15:46.390
of self hosting guardians, right, particularly since

205
00:15:46.790 --> 00:15:53.365
it might become like a regulatory sensitive type of situation and you want like a thousand flowers to bloom. You wanna see

206
00:15:53.845 --> 00:15:56.645
more options, not less for end users.

207
00:15:56.965 --> 00:16:03.045
The other pain point historically has been backups. Right? I mean, I when

208
00:16:03.770 --> 00:16:06.650
when we've seen issues with past Fediments,

209
00:16:07.770 --> 00:16:22.935
my understanding was at least a quorum of them, you know, if, and if it's three or four or five or seven, they needed to have their backups if, if something bad happened and they needed to recover the funds. How do the backups work in the Start9 setup? Like, is, is it complicated?

210
00:16:23.095 --> 00:16:24.935
Like, what does that situation look like?

211
00:16:25.655 --> 00:16:30.215
Well, you can use a, like regular integrated Start9 backups

212
00:16:30.295 --> 00:16:38.210
or the, the payment backup that you make through our UI. In both cases, the backups are static.

213
00:16:38.210 --> 00:16:40.450
So you do them once at the beginning,

214
00:16:41.090 --> 00:16:43.090
you put them on an USB stick

215
00:16:43.845 --> 00:16:46.885
or similar, and yeah, then you're done.

216
00:16:47.285 --> 00:16:49.925
Am I right? Just a file really Am bunch of private

217
00:16:50.885 --> 00:16:57.685
I right that you wouldn't, you don't need all seven backups to restore? You would just need five of seven in this situation or do you need all seven? Yes,

218
00:16:58.540 --> 00:17:04.059
of course. And in the worst case, to get your funds out, you would need five out of seven,

219
00:17:04.460 --> 00:17:09.980
five out of seven backups, but of course we recommend to back up every single Guardian once in case

220
00:17:10.300 --> 00:17:12.940
something happens to the machine, for example, like,

221
00:17:13.625 --> 00:17:14.585
you know,

222
00:17:14.745 --> 00:17:22.105
we run on like less reliable hardware, maybe even used hardware to keep the costs down, and so you always would want to make a backup.

223
00:17:22.425 --> 00:17:30.799
And that for us in the first federation actually came in very handy when one of the Guardians mistakenly

224
00:17:31.040 --> 00:17:35.760
completely deleted his Guardian and uninstalled it in an effort to upgrade.

225
00:17:36.880 --> 00:17:40.560
And so we had lost one out of the four Guardians and the system was still running,

226
00:17:41.585 --> 00:17:44.865
but that's of course not a great position to be in long term,

227
00:17:45.105 --> 00:17:45.585
but

228
00:17:45.985 --> 00:17:46.705
yeah,

229
00:17:47.185 --> 00:17:51.424
rest assured, he still had his Start9 backup and he recovered from that

230
00:17:51.825 --> 00:17:52.705
without a problem.

231
00:17:54.080 --> 00:18:06.400
Yeah. And the interesting thing about backups, I think the usual case or the more common case is that, like, one or two guardians are maybe affected by some hardware failure, outage, whatever, and then

232
00:18:06.775 --> 00:18:13.174
they can actually recover by asking the other guardians for, like, all the history that happened to restore their database,

233
00:18:13.575 --> 00:18:19.335
and the system just comes back to full operational capacity. That's what Yasha just described.

234
00:18:19.820 --> 00:18:25.019
Like, the worst case of, okay, everyone loses their their database,

235
00:18:25.100 --> 00:18:25.580
and

236
00:18:26.220 --> 00:18:30.139
then they have five of seven backups that gets you the money back, of course.

237
00:18:30.620 --> 00:18:34.380
But, that's not the thing that we're usually optimizing for.

238
00:18:34.934 --> 00:18:39.815
Like, the the goal is, I would say, continue continuity of service.

239
00:18:39.975 --> 00:18:43.014
Like So what does that look like? So so

240
00:18:43.095 --> 00:18:47.575
let's walk through the process. There's five zero seven Guardians running

241
00:18:48.550 --> 00:18:50.390
the South African Federation.

242
00:18:50.390 --> 00:18:53.750
You know, one of them has a power surge go through their house or whatever.

243
00:18:54.630 --> 00:18:56.309
The box gets fried.

244
00:18:56.790 --> 00:18:58.950
They set up a new start nine box.

245
00:18:59.030 --> 00:19:00.870
They installed the Federation app.

246
00:19:01.735 --> 00:19:02.294
How do they

247
00:19:03.095 --> 00:19:08.774
Federation right now is still live. Like, people are sending lightning transactions and Bitcoin transactions and whatnot.

248
00:19:09.255 --> 00:19:17.174
How how does that restore process work where they have the other six are still online and and that seventh person is trying to get back up to speed?

249
00:19:17.900 --> 00:19:21.820
So once they have, you know, their new guardian

250
00:19:22.220 --> 00:19:25.899
up and running and they see our UI instead of,

251
00:19:26.140 --> 00:19:31.500
you know, like they would click the restore button. So the first thing you see, it's basically set up or restore.

252
00:19:32.164 --> 00:19:33.524
They click restore,

253
00:19:33.605 --> 00:19:34.644
they get a

254
00:19:34.965 --> 00:19:36.244
field to upload,

255
00:19:36.645 --> 00:19:38.164
upload the backup file,

256
00:19:38.485 --> 00:19:41.684
they plug in their USB stick, they select it in the browser,

257
00:19:41.845 --> 00:19:44.004
they upload the file, they confirm,

258
00:19:44.885 --> 00:19:47.765
and then thirty seconds later, they are online again.

259
00:19:48.280 --> 00:19:53.480
What if they don't have their backup file? Are they, can they still restore from the Guardians like Eric said or?

260
00:19:54.440 --> 00:19:57.880
Well, they restore the payment history from

261
00:19:58.120 --> 00:20:12.895
the other Guardians but of course they need the backup file. The backup file is just a collection of private keys. They are gone, you can't really participate Right. In this That makes sense. The system at all. Like, if you lose your private keys, we really can't help you. So then you have to create a whole new federation in that situation.

262
00:20:13.135 --> 00:20:13.695
Right?

263
00:20:14.175 --> 00:20:20.310
Yeah. So, I mean, in practice, let's say you have like a five out of seven and one of the guardians completely

264
00:20:20.310 --> 00:20:35.445
loses their backup and their machine at the same time and they can't recover, then you could consider like, okay, are we going to keep running what is now effectively like a five out of six and say, well, we still have like one false tolerance and, you know, we're good to go for a while,

265
00:20:36.085 --> 00:20:42.725
or are we really gonna set up a new federation already and then, you know, move the users over in time. Grainsfully,

266
00:20:42.725 --> 00:20:43.845
yeah. Yeah, we

267
00:20:44.485 --> 00:20:47.285
support that quite well, so you can go into the Guardian UI

268
00:20:47.880 --> 00:20:50.760
and you can configure like a shutdown date

269
00:20:51.240 --> 00:20:53.800
and a successor federation,

270
00:20:53.800 --> 00:20:55.000
and then the,

271
00:20:55.320 --> 00:21:01.080
then the users, they're gonna see a message like, Hey, this federation is gonna shut down on like July 31.

272
00:21:01.585 --> 00:21:11.345
Please migrate your funds. Here's a successor federation, and they press one button and they join the new federation. That's how we So they migrate would literally get a notification in the app?

273
00:21:11.665 --> 00:21:12.385
Yeah, course.

274
00:21:13.679 --> 00:21:20.959
No, no, no, of course not. No, they get it like displayed in the app and it's a one click join basically to the follow-up federation.

275
00:21:21.200 --> 00:21:25.120
We use that to migrate from our three out of four test federation

276
00:21:26.015 --> 00:21:29.374
to like the new five out of seven. That's how we did it.

277
00:21:31.774 --> 00:21:35.934
It was very cool to see some of the people that was on the previous federation

278
00:21:36.414 --> 00:21:38.414
that I hadn't seen in a couple of months

279
00:21:39.049 --> 00:21:40.649
when I saw them recently

280
00:21:41.289 --> 00:21:43.210
and try to get them onto the new one.

281
00:21:44.090 --> 00:21:45.769
It was cool to see how

282
00:21:46.490 --> 00:21:47.529
easy that

283
00:21:48.650 --> 00:21:49.850
kind of flow was.

284
00:21:50.250 --> 00:21:52.009
Because I wasn't sure how that

285
00:21:52.409 --> 00:21:54.010
was gonna work, but it's cool

286
00:21:54.735 --> 00:22:05.134
that you can that you can do that from the Guardian side and just sort of migrate everybody over from one federation to the next. It seemed quite easy from the from the user's perspective.

287
00:22:08.255 --> 00:22:11.150
Which so, I mean, there's a couple different

288
00:22:12.190 --> 00:22:18.270
Federment, like, user facing apps. Are most of your users using the they're mostly using the Feti app?

289
00:22:19.390 --> 00:22:21.230
At the moment, we're using Conduit.

290
00:22:22.030 --> 00:22:22.830
Conduit.

291
00:22:23.305 --> 00:22:27.385
Yeah. That's a new wallet that I developed, like specifically

292
00:22:27.385 --> 00:22:34.585
for South Africa. It's been in the app stores for like a couple of months and yeah, we needed a new wallet for like some technical reasons

293
00:22:35.460 --> 00:22:37.299
and also to go for,

294
00:22:39.299 --> 00:22:45.219
you know, like a like a simpler UI. So Conduit is focused on being just a Fetiman wallet, nothing else,

295
00:22:45.700 --> 00:22:51.544
and it has some features specifically for South Africa. So it does support the money backtrack QR codes. Oh, awesome. You

296
00:22:52.825 --> 00:23:09.399
can use it to, you know, pay Zappa QR codes and so forth. I've been in I've been in South Africa myself for like three months over the winter and was living in in Bitcoin Witzen most of the time where I developed the wallet while I was living on it every day.

297
00:23:09.799 --> 00:23:14.039
So, I can say that the first Federation that we run, the three out of four one actually also

298
00:23:14.200 --> 00:23:15.559
was quite reliable.

299
00:23:15.799 --> 00:23:18.519
I didn't hadn't had a failed payments,

300
00:23:18.600 --> 00:23:20.520
failed payment living on it in three months.

301
00:23:22.715 --> 00:23:23.674
That's awesome. And

302
00:23:24.395 --> 00:23:26.955
later I came to join you there actually

303
00:23:27.595 --> 00:23:28.154
stayed

304
00:23:28.395 --> 00:23:30.154
together there for a bit. It's actually

305
00:23:31.434 --> 00:23:36.250
really amazing how well you can live on Bitcoin in South Africa and was

306
00:23:36.570 --> 00:23:41.529
a great trip. Like, I first stayed at Witsund too, like, Joshua, and then later

307
00:23:41.770 --> 00:23:43.690
I went to Mussel Bay and

308
00:23:43.930 --> 00:23:46.330
spent some time at the Kazi and in both places.

309
00:23:47.585 --> 00:23:49.904
Like, if you figure out, like, the tricks,

310
00:23:50.305 --> 00:23:52.385
like, for example, Money Badger and,

311
00:23:53.185 --> 00:23:58.865
like, know where your local Bitcoin accepting shops are, then I would say you can probably 90%

312
00:23:58.865 --> 00:24:02.305
live on Bitcoin. And it's just I mean, Badger is insane.

313
00:24:02.779 --> 00:24:08.459
Like, the amount of stores that you can you can spend Bitcoin at with Money Badger

314
00:24:09.179 --> 00:24:10.700
blows my American mind.

315
00:24:12.700 --> 00:24:14.779
I mean, And maybe Jack will get to there.

316
00:24:16.005 --> 00:24:16.645
Yeah.

317
00:24:17.285 --> 00:24:29.285
The only reason I still have a bank account is when I travel and I apply for visas, proof of funds does not count if I submit the Bitcoin wallet screenshot. I've gotta show proof of funds in a bank account. If it wasn't if it wasn't for that,

318
00:24:30.200 --> 00:24:32.279
I probably wouldn't need a bank account.

319
00:24:32.760 --> 00:24:36.279
And I mean, Kenya is the same. I mean, you can

320
00:24:36.680 --> 00:24:42.920
I didn't take any foreign currency? I was in Kenya for a week. I didn't take any foreign currency with me, I didn't exchange anything at the airport.

321
00:24:44.115 --> 00:24:55.794
I landed in the country with a Bitcoin wallet on my phone, and I left the country with a Bitcoin wallet on my phone, and I never touched the local shillings. I did bring one or two back from my kids for souvenirs, but other than that, I didn't

322
00:24:56.675 --> 00:24:58.275
really need them. So

323
00:24:59.410 --> 00:25:06.450
both both South Africa and and and Kenya, I think you can pretty much get around anywhere with with with with a Lightning Wallet.

324
00:25:07.330 --> 00:25:08.370
That's awesome.

325
00:25:09.810 --> 00:25:10.530
So, I mean,

326
00:25:11.434 --> 00:25:12.955
we're we were talking about,

327
00:25:14.315 --> 00:25:31.309
like, one person. If if one of the guardians makes a mistake, you know, deletes their back doesn't have a backup or, I mean, god forbid, like, their house catches on fire or something and their box is down and their backup's gone, then you're essentially operating a five of six.

328
00:25:31.790 --> 00:25:34.350
Obviously, my my brain goes, okay.

329
00:25:34.670 --> 00:25:36.110
You got seven people.

330
00:25:37.390 --> 00:25:40.990
The chances that one of them is a dumbass at some point

331
00:25:41.725 --> 00:25:51.004
is probably not that low. Like, I like, mistakes happen. You know? People are living their lives. Everything's going great. You're, like, fourteen months in and

332
00:25:51.565 --> 00:25:57.820
someone messes up something. Now now all of a sudden, you're out of five of six. So are there any technical limitations on

333
00:25:58.460 --> 00:26:00.460
size of these things? Like, it be

334
00:26:01.100 --> 00:26:07.500
could it be a six six of 11 or something? I don't know. Like, is have what what are your thoughts on that?

335
00:26:08.845 --> 00:26:11.804
Well, I think it would be an eight out of 11.

336
00:26:12.525 --> 00:26:19.725
Okay. But that's technically completely possible, yeah. So the next Federation sites we would recommend would be seven out of 10

337
00:26:20.380 --> 00:26:26.220
because the moment you go from nine to 10 guardians, you gain one more guardian that you can lose.

338
00:26:26.860 --> 00:26:27.499
So

339
00:26:27.820 --> 00:26:30.940
we recommend basically the sizes like four,

340
00:26:31.179 --> 00:26:31.500
seven,

341
00:26:32.075 --> 00:26:32.794
10,

342
00:26:33.355 --> 00:26:35.755
and the next one I think would be

343
00:26:36.395 --> 00:26:37.514
13 then,

344
00:26:38.075 --> 00:26:39.755
so like a 10 out of 13.

345
00:26:39.995 --> 00:26:42.875
But right now it seems like five out of seven is the sweet spot.

346
00:26:43.195 --> 00:26:52.759
Maybe in the future we're gonna set up seven out of 10. Does it make performance worse, the larger it is, because, like, they're all communicating with each other all the time, signing things?

347
00:26:54.279 --> 00:26:55.080
No.

348
00:26:55.399 --> 00:27:08.675
It doesn't. Yeah. So latency doesn't change. Like, your transactions are still fast. Like, what might happen is that you consume a little bit more bandwidth, but it's very minimal. So Yeah. I wouldn't worry about it. Yeah. And the maximum that

349
00:27:10.755 --> 00:27:13.315
Yeah. That was part of my first

350
00:27:12.929 --> 00:27:18.609
first project that I did when I rewrote the consensus like way back in the day of 2023,

351
00:27:19.730 --> 00:27:23.330
that was one of the benefits that fell out that you basically

352
00:27:23.330 --> 00:27:25.970
have constant latency with the number

353
00:27:26.794 --> 00:27:33.595
of guardians. Yeah. It goes slightly up if you run, let's say, 20 guardians, but it's like negligible.

354
00:27:34.155 --> 00:27:35.355
Yeah. Yeah. And,

355
00:27:36.075 --> 00:27:39.515
like, we could actually run federations up to size of 20.

356
00:27:40.159 --> 00:27:42.720
Right now, the main limitation is

357
00:27:42.880 --> 00:27:44.320
the multisigs,

358
00:27:44.799 --> 00:27:48.320
like the standard rules around multisigs, I think forbid

359
00:27:49.039 --> 00:27:50.399
anything larger than

360
00:27:51.200 --> 00:27:52.159
20. What would it be?

361
00:27:53.135 --> 00:27:56.255
Because these are native on chain multisig transactions

362
00:27:56.255 --> 00:27:57.455
that are back in the Yeah.

363
00:27:58.735 --> 00:27:59.615
But

364
00:28:01.135 --> 00:28:17.019
we haven't run any or haven't seen any live federation of that size. So we did do some test federations that were that large and just played around with that. But Yeah. And they perform well, but at some point, it's hard to coordinate. So there are some ideas around

365
00:28:17.500 --> 00:28:19.259
just automating coordination,

366
00:28:19.419 --> 00:28:20.924
but that's

367
00:28:21.485 --> 00:28:23.404
something more in the research phase Also, right

368
00:28:24.525 --> 00:28:29.404
the the larger federations, they need to grow over time. You know, you need to, like, grow the social structure.

369
00:28:29.645 --> 00:28:37.480
So you could imagine that you have a two five out of seven federations in the same region that have largely the same users, and eventually,

370
00:28:37.640 --> 00:28:42.919
you know, maybe they have lost some of their machines or some of the guardians wanna switch out.

371
00:28:43.160 --> 00:28:45.559
They could join together and form,

372
00:28:45.640 --> 00:28:46.360
like, now,

373
00:28:47.615 --> 00:28:57.695
like a, I think it would be like a 10 out of 13 federation, for example, and both of them would then like, they could run these like on the same start nines,

374
00:28:58.335 --> 00:29:09.040
they would then just set shutdown dates in the old federation, set the new larger one as a successor, and then the users would like join the new federation. And they could run them at the same time on the same the same starting nodes during the

375
00:29:09.440 --> 00:29:10.160
transition?

376
00:29:11.040 --> 00:29:15.040
Yeah, that would be possible. We would have to ship a second package for that technically,

377
00:29:15.585 --> 00:29:16.465
but yeah.

378
00:29:17.105 --> 00:29:27.664
And then Like a feature request. Be able to run multiple instances of the same package at the same time. That would be so amazing. Yeah. Oh, on start not like a feature request for a start OS. Yeah.

379
00:29:28.330 --> 00:29:29.530
Yes. Yeah.

380
00:29:30.490 --> 00:29:42.090
Keep being very deliberate about the threshold, like the specific MMN. Does that, is that a personal preference or is that actually a technical, is there a technical reason behind that? There's a technical reason for it. So,

381
00:29:43.105 --> 00:29:49.585
at the lowest level, we use something which is called a Byzantine fault tolerant algorithm to establish consensus,

382
00:29:49.825 --> 00:29:53.585
and there is actually a technical result on the, like,

383
00:29:54.304 --> 00:29:59.329
lowest threshold that you can achieve there. And three out of four, five out of seven,

384
00:29:59.730 --> 00:30:01.329
seven out of 10,

385
00:30:02.129 --> 00:30:06.929
and then the next one would actually, yeah, it would be a 10 out of 14, actually, I think. Nine.

386
00:30:08.184 --> 00:30:09.464
Not 10 out of 14?

387
00:30:11.625 --> 00:30:15.065
Anyway, one side goes up by two, the other by three.

388
00:30:15.384 --> 00:30:24.729
Yeah. That's Yeah. That's right. Yeah. Those are, the the lowest thresholds that you can achieve. Yeah. If we would choose them if we could choose them freely,

389
00:30:24.970 --> 00:30:29.450
we would maybe go for something a little bit lower. So like a four out of seven maybe,

390
00:30:30.250 --> 00:30:31.529
but we can't.

391
00:30:31.770 --> 00:30:35.370
Five out of seven is like the lowest threshold that is technically achievable.

392
00:30:35.835 --> 00:30:45.595
Yeah. So the problem there is that like while you could still access your on chain funds, there's no guarantee anymore that the federation could agree on which transactions

393
00:30:45.595 --> 00:30:46.955
were actually confirmed

394
00:30:47.195 --> 00:30:55.110
or like what should happen. So it doesn't give you much benefit that, okay, you can still access your on chain funds. It actually just adds more

395
00:30:55.510 --> 00:30:57.590
risk for users that someone

396
00:30:57.670 --> 00:30:59.029
could try to steal.

397
00:30:59.830 --> 00:31:00.950
So that's why we don't do that.

398
00:31:01.665 --> 00:31:05.185
Got it. That makes sense. So then, I mean, there are

399
00:31:05.825 --> 00:31:06.785
they're obviously

400
00:31:07.665 --> 00:31:09.825
it often gets compared in the same

401
00:31:10.785 --> 00:31:16.145
in the same conversations, and there's but there's obviously multiple differences between cashew

402
00:31:16.145 --> 00:31:17.410
and Fediment.

403
00:31:17.810 --> 00:31:27.810
But one of the big ones that I think a lot of people don't realize is that Fediment is native on chain. Right? So this is a is effectively like a multi multi sig on chain wallet.

404
00:31:28.745 --> 00:31:30.184
So then as a result,

405
00:31:31.465 --> 00:31:36.105
someone's gotta run the lightning node. I assume most of the transactions that are happening

406
00:31:36.585 --> 00:31:40.985
in Erman's federation is lightning transactions or a lot of them are.

407
00:31:41.990 --> 00:31:44.229
How is that how is that being handled?

408
00:31:46.070 --> 00:31:54.309
So the Fetiman project itself runs the gateway right now, and that's the one that we use to, like, bootstrap new federations.

409
00:31:54.775 --> 00:31:58.294
Yeah. And is it the gateway for multiple federations?

410
00:31:58.695 --> 00:32:01.174
Yeah. Come again. Sorry.

411
00:32:01.655 --> 00:32:07.895
Go on. Yeah. Just to explain, like, the gateway is a service or a piece of software that connects a Lightning node to federation

412
00:32:07.895 --> 00:32:10.020
just for anyone present

413
00:32:10.020 --> 00:32:17.220
Right. Back into Federation into DeepLeap. Which is separate. It's separate of the Federation. Right? It's like a it's a service provider of Federations

414
00:32:17.220 --> 00:32:19.940
that provides It is licensing a service provider. Yeah.

415
00:32:20.340 --> 00:32:21.060
Yeah.

416
00:32:21.540 --> 00:32:22.820
So we we

417
00:32:23.140 --> 00:32:24.340
we split

418
00:32:24.835 --> 00:32:26.035
the servers

419
00:32:26.115 --> 00:32:27.395
from the custody.

420
00:32:27.875 --> 00:32:29.075
So federations

421
00:32:29.075 --> 00:32:41.330
are guardians. They are easy to run. You set them up once. Everything beyond that is completely automated. You just keep internet and power to the box, and then you're fine. Guardians are more involved because you do run a lightning node,

422
00:32:41.890 --> 00:32:44.050
so it's like a continuous effort,

423
00:32:44.370 --> 00:32:47.890
and we split that and then you have an M of N relationship,

424
00:32:48.370 --> 00:32:55.044
so you can connect multiple gateways to a federation and you can connect multiple federations to the same gateway.

425
00:32:55.684 --> 00:33:01.764
So, what we effectively do is initially when you have one federation, we bootstrap them with our gateway,

426
00:33:02.325 --> 00:33:13.690
and when they reach a critical mass volume to warrant their own gateway, they can migrate over, or maybe you have multiple federations in the same region that together

427
00:33:14.010 --> 00:33:18.330
reach that mass, and then they can spin up their own gateway

428
00:33:18.570 --> 00:33:19.930
and connect it to all of that,

429
00:33:20.655 --> 00:33:25.935
all of them initially you could be running then their gateway side by side to ours, the guardians,

430
00:33:25.935 --> 00:33:26.415
the

431
00:33:27.375 --> 00:33:28.895
apps would use them,

432
00:33:29.855 --> 00:33:40.059
then like randomly basically load balance across them. If one of them goes offline, you immediately fall back to the other, So there's a nice fault tolerance there if you have multiple gateways connected to a federation,

433
00:33:40.380 --> 00:33:42.700
and eventually we would just disconnect

434
00:33:42.700 --> 00:33:45.019
our gateway, and then they are completely

435
00:33:45.980 --> 00:33:48.299
separate from us. And this is invisible If to the

436
00:33:48.940 --> 00:33:50.975
there's there's multiple gateways,

437
00:33:50.975 --> 00:33:53.695
they're just making a Lightning transaction. It's just working.

438
00:33:54.095 --> 00:33:56.654
Exactly. Yeah. So actually I

439
00:33:57.135 --> 00:34:01.695
actually had a question from somebody on that, and I wasn't sure if I answered it correctly. But the question

440
00:34:02.290 --> 00:34:05.730
question someone asked me was, okay, if the Guardians are

441
00:34:05.970 --> 00:34:08.050
very easy to run, which they are,

442
00:34:08.450 --> 00:34:11.650
but the Lightning Gateway is more technical and

443
00:34:13.330 --> 00:34:16.130
likelihood of there's something going wrong with the Guardian is pretty low,

444
00:34:16.825 --> 00:34:21.545
but the likelihood of something going wrong with the Lightning Gateway is a little higher.

445
00:34:21.865 --> 00:34:23.865
If the Lightning Gateway goes down,

446
00:34:24.825 --> 00:34:28.825
you're not necessarily disabled in the federation. You could still transact

447
00:34:29.225 --> 00:34:32.425
amongst the people within the federation, obviously with eCash,

448
00:34:33.119 --> 00:34:36.000
and you can still get in and out of federation

449
00:34:36.079 --> 00:34:41.520
on chain. It's just the lightning element. That was my answer, but I wasn't a 100% sure about that.

450
00:34:42.000 --> 00:34:43.119
No, it's right.

451
00:34:43.519 --> 00:34:44.080
Yeah.

452
00:34:44.559 --> 00:34:46.240
ECash and on chain still works fine.

453
00:34:47.035 --> 00:34:48.795
And on the uptime question,

454
00:34:49.275 --> 00:34:50.635
the thing is that

455
00:34:52.155 --> 00:34:54.955
while the federation runs on residential,

456
00:34:54.955 --> 00:34:56.875
where let's say you have like 95%

457
00:34:56.875 --> 00:34:58.315
uptime, which is not enough,

458
00:34:58.955 --> 00:35:00.075
the gateways,

459
00:35:00.075 --> 00:35:01.435
they run-in the cloud

460
00:35:01.595 --> 00:35:05.360
just because of the lightning node that needs to be running in the cloud.

461
00:35:05.760 --> 00:35:09.520
So they should have much better uptime and then it kind of

462
00:35:09.920 --> 00:35:11.760
kind of evens out there. Yeah.

463
00:35:12.799 --> 00:35:15.599
So, I mean, but there's no technical

464
00:35:17.165 --> 00:35:23.165
limitation on couldn't you run it? Could you not run a Lightning Gateway on a, like, a Stark nine as well?

465
00:35:23.565 --> 00:35:31.885
Yeah. You can do it, and we technically support it, but there's inherent problem with Lightning that you just can't back them up well.

466
00:35:32.205 --> 00:35:32.525
Yeah.

467
00:35:34.020 --> 00:35:38.180
So that like limits you, you know, you really want to put like

468
00:35:38.580 --> 00:35:40.020
1 or 2 Bitcoin

469
00:35:40.180 --> 00:35:42.900
in a hot wallet runs on your start line?

470
00:35:43.460 --> 00:35:50.445
Not, but with a five out of seven federation, that's completely reasonable. Like, federations are not made for small amounts. We have

471
00:35:51.645 --> 00:35:59.325
right now it's still possible because your on chain fees are low, but we have really have two types of users here. We have the person that has

472
00:36:00.060 --> 00:36:02.940
their savings in an on chain wallet, and then,

473
00:36:03.260 --> 00:36:14.940
so in a hardware wallet, and then they move it inside the federation, and then they spend it over Lightning, but they move thousands of dollars in value at a time, you know, assuming an on chain transaction is more expensive,

474
00:36:15.975 --> 00:36:19.735
And then you have the other way around, you have the business owner that has

475
00:36:20.295 --> 00:36:21.895
one or maybe a handful

476
00:36:22.055 --> 00:36:25.655
of point of sale systems based on Lightning, and he

477
00:36:25.735 --> 00:36:30.215
collects Lightning payments over time and eventually withdraws on chain

478
00:36:30.860 --> 00:36:31.740
$10.20,

479
00:36:31.740 --> 00:36:33.100
$30,000

480
00:36:33.100 --> 00:36:35.020
of value at

481
00:36:35.020 --> 00:36:36.300
a time. So,

482
00:36:36.940 --> 00:36:40.700
need to be able to save a significant amount

483
00:36:40.940 --> 00:36:49.075
or maintain a significant amount of value, like to yourself significant amount, maybe like a year's worth of savings in that federation,

484
00:36:49.075 --> 00:37:01.234
and this can only be achieved on local hardware with like with like the system being federated. So, this creates a lot of technical complexity, of course, for us, which is also like where the vast majority of our, like,

485
00:37:01.770 --> 00:37:03.610
engineering time goes to.

486
00:37:04.490 --> 00:37:05.530
In practice,

487
00:37:06.490 --> 00:37:13.450
eCache is a very important part of the system, but it is something that was solved like three years ago. We still like run the same

488
00:37:14.835 --> 00:37:20.035
cryptography basically for that, that we wrote three years ago. This was done when I joined the project.

489
00:37:20.515 --> 00:37:21.235
Got it.

490
00:37:21.555 --> 00:37:22.755
In 2023,

491
00:37:22.755 --> 00:37:25.075
and since then everything's been about like

492
00:37:25.635 --> 00:37:29.180
the federated aspect. So you get the data replication

493
00:37:29.180 --> 00:37:34.140
out of the box, like for the people who run Lightning Notes, if you wanna do a series setup,

494
00:37:34.700 --> 00:37:40.075
you like either run it in the cloud where like your storage there just gets automatically

495
00:37:40.075 --> 00:37:40.955
replicated,

496
00:37:40.955 --> 00:37:44.315
or you go even further and then you use like

497
00:37:44.795 --> 00:38:02.150
like managed Postgres with like data replication built in to build your lightning node on top, because if you lose that data, your money's gone. Right. And we brought that into Fediment, so the data replication is extremely important, like your payment is not shown as confirmed

498
00:38:02.150 --> 00:38:02.950
before

499
00:38:03.589 --> 00:38:09.365
the transaction that you created is not replicated and stable on disk of five guardians.

500
00:38:10.005 --> 00:38:13.845
You don't notice it because we do it in two hundred milliseconds,

501
00:38:14.165 --> 00:38:14.725
but

502
00:38:15.445 --> 00:38:20.965
yeah, it happens every time. And the other thing is, of course, the uptime, like if you have a residential Internet connection,

503
00:38:21.450 --> 00:38:25.290
maybe you have 95% uptime, maybe you have 97%,

504
00:38:26.010 --> 00:38:37.985
that's really not the percentage that we are shooting for with the system overall. I think if you, you know, do a payment system that people rely on, like in the two use cases I just described, where, like, people may run a business over it,

505
00:38:38.385 --> 00:38:42.065
you are really like in the category of like 99.5,

506
00:38:42.065 --> 00:38:43.105
99.9%

507
00:38:43.105 --> 00:38:52.300
uptime, but if you have a five zero seven federated system where the individual nodes have like 95 or 97% uptime, overall, you will get like 99.5%

508
00:38:52.300 --> 00:38:53.500
or higher uptime,

509
00:38:53.820 --> 00:38:56.220
assuming that they are like independent,

510
00:38:57.100 --> 00:39:00.620
like if the entire Internet of a region goes down, there's nothing we can do, but

511
00:39:02.255 --> 00:39:07.055
usually that's not the case, and we have individual peers that or individual guardians that go down,

512
00:39:07.375 --> 00:39:13.295
but the entire system just works. Yeah. So spread out your guardians, so they're not affected by the same rolling blackout.

513
00:39:14.349 --> 00:39:14.910
Yeah.

514
00:39:17.310 --> 00:39:20.030
So, yeah. I mean, that all makes sense to me.

515
00:39:20.750 --> 00:39:22.510
So with the gateways,

516
00:39:22.830 --> 00:39:26.270
with the Lightning Gateway so first of all, a lot of this comes down to

517
00:39:26.905 --> 00:39:30.505
trust trade offs and performance optimizations.

518
00:39:30.585 --> 00:39:31.785
And the reason,

519
00:39:32.265 --> 00:39:36.105
you know, one of the coolest aspects of Fedement is that you

520
00:39:36.985 --> 00:39:38.585
your trust is distributed,

521
00:39:38.585 --> 00:39:44.150
like, at at the base of it. Right? So it's five of seven. You you effectively need

522
00:39:44.630 --> 00:40:03.915
you need five of the guardians to basically be malicious to steal money. You also you would need, you know, three of the guardians to be incompetent to lose money. So, like, you're you're you're distributing the trust. You're making it less likely that that people have funds lost. But with the gateways, it's literally a single person, a professional,

523
00:40:03.995 --> 00:40:07.435
running a lightning node and managing liquidity and keeping uptime.

524
00:40:07.595 --> 00:40:08.635
What is that?

525
00:40:09.355 --> 00:40:13.035
What is that trust trade off for the end user? Like, I'm, if I'm receiving,

526
00:40:14.049 --> 00:40:17.410
if I'm receiving, I don't know, $100 over lightning

527
00:40:17.970 --> 00:40:19.250
through a gateway

528
00:40:19.890 --> 00:40:21.089
in transit,

529
00:40:21.089 --> 00:40:22.609
am I am I trusting

530
00:40:22.609 --> 00:40:25.890
that gateway provider? Is that that's a trusted relationship?

531
00:40:26.505 --> 00:40:28.984
Sorry. I think we lost you for a second.

532
00:40:29.305 --> 00:40:31.945
I still can't hear him, Matt.

533
00:40:33.224 --> 00:40:34.585
Yeah. Speaking of

534
00:40:34.825 --> 00:40:39.705
speaking of shitty Internet. Reliability.

535
00:40:40.424 --> 00:40:41.785
Yeah. And he's gone.

536
00:40:43.500 --> 00:40:45.580
Okay.

537
00:40:51.260 --> 00:40:53.020
I see the video move again.

538
00:40:53.740 --> 00:40:54.940
Oh, there we go.

539
00:40:55.820 --> 00:40:57.180
It's back. I think you're back.

540
00:40:57.945 --> 00:41:01.385
Yeah. I lost Internet briefly, but the Federmid stayed online.

541
00:41:01.705 --> 00:41:02.825
Yeah. No.

542
00:41:04.105 --> 00:41:05.625
Did you get my question?

543
00:41:06.185 --> 00:41:07.145
No. No.

544
00:41:08.585 --> 00:41:10.585
So I'm I was my question was,

545
00:41:11.170 --> 00:41:16.370
this all records locally, so they've heard my question. The the listeners heard my question.

546
00:41:16.690 --> 00:41:17.250
The

547
00:41:17.570 --> 00:41:20.450
what is the trust trade off with the individual gateways?

548
00:41:21.330 --> 00:41:28.315
Oh, yeah. So basically, there is none because the gateway is just an extension of the Lightning Network into the federation.

549
00:41:28.474 --> 00:41:34.075
And just like you don't trust any Lightning node on the route when you're sending a payment, you don't trust the gateway.

550
00:41:34.315 --> 00:41:35.915
They can either forward

551
00:41:36.010 --> 00:41:41.370
the money to the end user who receives it and then receive the incoming funds they are routing,

552
00:41:41.610 --> 00:41:44.410
or they don't do that and then they don't receive any funds.

553
00:41:44.570 --> 00:41:47.370
So the only thing you really rely on is them not

554
00:41:48.170 --> 00:41:49.370
denying the service to you.

555
00:41:50.125 --> 00:41:52.765
But that's in their best interest because they're making fees.

556
00:41:53.565 --> 00:41:54.125
That

557
00:41:54.925 --> 00:41:57.165
that was my other assumption was that

558
00:41:57.645 --> 00:42:07.600
at some point, you would probably see people who are good at running Lightning nodes that will offer gateway gateway as a service and would want to connect to federations

559
00:42:07.920 --> 00:42:11.040
as a way of providing a service to federations.

560
00:42:11.040 --> 00:42:14.320
And because you're not really trusting the gateway, that's something that

561
00:42:14.800 --> 00:42:17.040
is an acceptable trade off.

562
00:42:18.135 --> 00:42:20.455
Don't necessarily wanna put yourself in a situation

563
00:42:20.695 --> 00:42:21.975
where you rely on

564
00:42:23.175 --> 00:42:26.055
federations to run their own lighting notes because that

565
00:42:26.455 --> 00:42:29.735
is more technical. And if I think about the use case on the ground here,

566
00:42:30.450 --> 00:42:32.690
it would be relatively easy to

567
00:42:33.329 --> 00:42:37.570
help a bunch of people set up federation, but it's gonna be a whole different story to

568
00:42:38.130 --> 00:42:40.130
help them set up a Lightning node and manage that.

569
00:42:42.865 --> 00:42:51.185
Yeah, it's a completely different skill set. Running something in the cloud, then like running something on a like Start9 or like a different type of home server is a completely different

570
00:42:51.985 --> 00:42:52.865
experience.

571
00:42:53.585 --> 00:42:59.950
And I think what we have seen is that Lightning in general has been moving more into a professionalized

572
00:42:59.950 --> 00:43:00.590
direction,

573
00:43:01.310 --> 00:43:02.350
like the

574
00:43:02.910 --> 00:43:06.670
claps running the whole Lightning node at home and using that for all the transactions

575
00:43:06.829 --> 00:43:07.470
that

576
00:43:07.630 --> 00:43:10.349
was still big in twenty twenty one, twenty twenty two.

577
00:43:10.955 --> 00:43:13.115
But I think by now a lot of people

578
00:43:13.915 --> 00:43:17.115
kinda stopped doing that. At least when I go to conferences,

579
00:43:17.355 --> 00:43:24.475
I see many people using the quality of Satoshi. Blink is great. Like, I mean, I saw a lot of people use Blink in South Africa.

580
00:43:25.110 --> 00:43:29.190
Phoenix Wallet. You have Async manage your Lightning Net for you.

581
00:43:29.510 --> 00:43:30.630
Yeah. Yeah.

582
00:43:31.750 --> 00:43:34.390
So I think there's a certain reason

583
00:43:35.350 --> 00:43:36.230
to make

584
00:43:36.390 --> 00:43:40.230
it a separate service that a professional can manage. And

585
00:43:40.595 --> 00:43:49.395
even if you want to manage it yourself, it's pretty easy to run your own gateway. So not to say it's actually hard. Like, have start nine packages. We have unbilled packages for that

586
00:43:49.875 --> 00:43:51.795
kind of stuff. But then

587
00:43:51.954 --> 00:44:06.810
you really need to be aware of the trade off of running a Lightning node on note in a box at home, and also spend the time actually managing that node because otherwise your routing will not be good enough, and you won't provide a good service to your community and nobody wants that.

588
00:44:07.370 --> 00:44:13.655
Yeah. And you have to have I mean, the listeners, the freaks are very aware of running their own lightning nodes and

589
00:44:13.815 --> 00:44:24.694
the mental burden and the financial burden that comes with it. I mean, it's not even just a technical thing. Right? Like, you need to have solid liquidity. You have to lock up funds. You know, it's you're you're

590
00:44:25.100 --> 00:44:33.020
you're in a beneficial situation if you have more money at your disposal for doing that. If you try and run a very tight ship, you're gonna have payment failures.

591
00:44:33.660 --> 00:44:35.420
So on the gateway question,

592
00:44:35.980 --> 00:44:41.095
this is once again, I I I I'm assuming this is like completely detached from end users. Users.

593
00:44:41.495 --> 00:44:58.310
The are the Fediments is the Guardians choosing which gateways they bless? You you mentioned that there's they could have multiple gateways. Like, are they going into, the Guardian UI and being, like, I am adding this gateway and then, like, five of seven of them have to be, yes. We're adding this gateway to the system or how does that look?

594
00:44:59.510 --> 00:45:04.150
Almost exactly right. So they do go into the UI, they add the

595
00:45:04.790 --> 00:45:08.870
the they add the gateways URL there, but it doesn't have to be

596
00:45:09.990 --> 00:45:11.910
it doesn't have to be

597
00:45:12.025 --> 00:45:15.065
at least five for it to work, but so

598
00:45:15.305 --> 00:45:18.505
the guardians, they can actually configure different gateways right now.

599
00:45:19.225 --> 00:45:30.010
Not ideal, but it would work, and then the client, it's gonna use them in the it's gonna try the gateways in the order that they receive votes, basically. The more Guardians configure this gateway,

600
00:45:30.330 --> 00:45:32.090
the the sooner it will be tried.

601
00:45:33.130 --> 00:45:40.330
Yeah. And the idea is that even a single Guardian, if they notice, all our old gateways that we had configured before,

602
00:45:40.755 --> 00:45:46.115
they're all offline. And the others the other guardians aren't online right now, so they can just add another

603
00:45:46.355 --> 00:45:48.115
gateway unilaterally.

604
00:45:48.194 --> 00:45:55.315
And if that's the only gateway that's available, clients or apps will use that. And you can unblock your federation immediately

605
00:45:55.460 --> 00:46:05.059
and then others at the same gateway too, so it gets more votes, but you're never in a situation where you first have to gather the whole team and have to vote on it. That's awesome. That's clever. I like that.

606
00:46:08.435 --> 00:46:14.355
I a different question as well. So I'm asking a bunch of questions, but it's not often I get the two of you together on

607
00:46:15.475 --> 00:46:16.595
one call. Yeah.

608
00:46:19.635 --> 00:46:21.155
I asked somebody from

609
00:46:21.560 --> 00:46:22.520
Fedi's

610
00:46:22.520 --> 00:46:25.720
marketing team, Medibay, and I wasn't sure about

611
00:46:25.960 --> 00:46:29.800
his answer. But so Fedi, obviously, Fedi the app has

612
00:46:30.600 --> 00:46:33.640
a whole communications component to it. It's not just the wallet.

613
00:46:34.865 --> 00:46:44.545
And obviously once you connect the Fedi app to the federation, then I understand that the financial component lives on the Guardian machines. But what about the communications component? Is that still

614
00:46:44.865 --> 00:46:53.680
sort of like cloud based and managed by Fedi? Or does that also live on, does does this become a community custody for for finances,

615
00:46:53.680 --> 00:46:56.800
or does it become community custody for finances and communications

616
00:46:57.119 --> 00:47:03.200
once you're using the Fedi app on a on a federation? No. The So that's that's a great question.

617
00:47:03.520 --> 00:47:09.325
And, yeah, I mean, I'm somewhat more involved on the petty side, so I will just take

618
00:47:09.325 --> 00:47:15.485
that. Take it. But, yeah, so only the custody moves to the community run federation.

619
00:47:15.885 --> 00:47:16.525
The

620
00:47:16.910 --> 00:47:18.430
chat functionality

621
00:47:18.430 --> 00:47:22.430
is still cloud hosted. And the reasoning behind that is,

622
00:47:22.910 --> 00:47:24.830
so for custody,

623
00:47:24.990 --> 00:47:25.870
you actually

624
00:47:26.590 --> 00:47:33.625
like, that's something where you want the trust to be local. Right? Like, you can't outsource that without negative repercussions.

625
00:47:33.625 --> 00:47:34.985
While for the chat,

626
00:47:35.225 --> 00:47:40.265
it's encrypted with state of the art encryption technology using the same protocol as signal.

627
00:47:40.585 --> 00:47:43.225
So even though you're relying on a central service,

628
00:47:43.900 --> 00:47:51.580
the central service can't really see anything about your chat, and that makes it much more viable and made it a lesser priority to decentralize.

629
00:47:51.820 --> 00:47:55.980
But I would say the end goal is and we chose a protocol

630
00:47:56.300 --> 00:47:57.900
called the matrix protocol

631
00:47:57.980 --> 00:47:58.940
as the underlying

632
00:47:59.475 --> 00:48:01.155
that it could be decentralized

633
00:48:01.155 --> 00:48:02.035
in the future.

634
00:48:02.435 --> 00:48:07.395
So I think the direction everything is moving into is decentralization.

635
00:48:07.635 --> 00:48:12.355
And I hope we will see even more decentralized solutions in matrix, like

636
00:48:12.440 --> 00:48:15.240
what was the one MLS based one called that

637
00:48:16.680 --> 00:48:19.000
White noise. White noise. Exactly.

638
00:48:19.319 --> 00:48:22.680
That's being pushed in Nostice space. That's really promising

639
00:48:22.680 --> 00:48:23.319
and

640
00:48:23.975 --> 00:48:30.855
just we need to mature these technologies and then we can really embrace them, not have any single point of failure anymore.

641
00:48:31.015 --> 00:48:35.735
While for custody, I think federations are a pretty good trader and a pretty sweet spot.

642
00:48:37.670 --> 00:48:43.990
For just building easy to use Bitcoin wallets that users can be confident in, that they can hold large amounts of money.

643
00:48:45.270 --> 00:48:45.750
Think

644
00:48:46.549 --> 00:48:48.390
Fedium that just fills a

645
00:48:49.109 --> 00:48:50.710
space in the trade off space

646
00:48:51.115 --> 00:48:56.475
that was underexplored before, and I personally really like it. And

647
00:48:56.715 --> 00:48:57.595
I think

648
00:48:58.715 --> 00:48:59.435
with,

649
00:48:59.835 --> 00:49:03.035
like, being able to show, like, how easy it can be to

650
00:49:03.195 --> 00:49:06.075
transact and still have custody in your community,

651
00:49:07.010 --> 00:49:09.810
many other people will get to appreciate it too.

652
00:49:10.930 --> 00:49:13.170
Yeah. I mean, I think it's awesome. I

653
00:49:14.930 --> 00:49:22.555
got back from the Nairobi conference two days ago, and I spent more time talking about Ferrymand at the conference than I did about speaking

654
00:49:22.635 --> 00:49:24.715
about my own project. So I

655
00:49:25.275 --> 00:49:30.075
think it's fantastic because it a really kind of a sweet spot.

656
00:49:31.355 --> 00:49:33.675
Yeah. I don't know. It just feels like it

657
00:49:34.235 --> 00:49:36.555
was really necessary to have something there.

658
00:49:38.170 --> 00:49:41.130
And trying to explain to people

659
00:49:41.450 --> 00:49:42.650
that you

660
00:49:42.810 --> 00:49:43.610
wanna bring

661
00:49:43.930 --> 00:49:52.875
And another thing is like in these types of communities, trust often a very different kind of trust looks very different. The trust between people

662
00:49:53.275 --> 00:49:55.994
looks very different. So it's totally fine. I mean,

663
00:49:56.954 --> 00:49:57.994
it's

664
00:49:57.994 --> 00:50:00.875
not unheard of for neighbors to trust each other with

665
00:50:03.099 --> 00:50:07.580
bank details and PINs and ATM cards. You you're living on top of one another, so it's

666
00:50:08.300 --> 00:50:09.660
not unheard of. And

667
00:50:10.460 --> 00:50:12.380
it just kinda feels like there's

668
00:50:13.900 --> 00:50:15.180
gonna be a lot of use

669
00:50:15.820 --> 00:50:23.495
case for this kind of setup where you have these community trust models that sort of it kinda feels like it naturally fits into

670
00:50:24.215 --> 00:50:26.295
the social setup that you already have.

671
00:50:28.295 --> 00:50:31.495
And when like, I was thinking about fame in the beginning.

672
00:50:31.990 --> 00:50:35.030
Like, my biggest fear was if we

673
00:50:35.430 --> 00:50:36.630
got hyperbitcoinization

674
00:50:36.630 --> 00:50:37.510
tomorrow,

675
00:50:38.150 --> 00:50:42.950
then most people would actually go to the big banks and just keep their Bitcoin in

676
00:50:43.190 --> 00:50:49.485
JPMorgan Chase or whatever their bank is right now. And that would just be a horrible outcome in my opinion.

677
00:50:50.045 --> 00:50:51.485
So finding

678
00:50:51.645 --> 00:50:53.085
pragmatic ways,

679
00:50:53.165 --> 00:51:14.140
like, that might not be pure from a Bitcoin's perspective, like, because back in 2021 when Freddie Mac was starting out, like, I was kinda scared to get tarred and feathered for even bringing up the idea of not being fully self custody and, like, finding this trade off there. Like, just acknowledging that we could have a trade off, and it doesn't have to be black or white.

680
00:51:14.875 --> 00:51:17.595
But, I think over the years,

681
00:51:17.755 --> 00:51:18.715
turns out

682
00:51:19.595 --> 00:51:22.475
there might actually be something interesting about it. And,

683
00:51:22.715 --> 00:51:29.835
yeah, I'm super happy to after, like, working for five years to see it out in the wild and people use it day to day and,

684
00:51:30.840 --> 00:51:31.800
it's

685
00:51:31.960 --> 00:51:33.000
just amazing.

686
00:51:33.720 --> 00:51:35.320
Lots of learnings on the way.

687
00:51:36.200 --> 00:51:37.240
Definitely. Definitely.

688
00:51:37.400 --> 00:51:38.760
We are Sorry,

689
00:51:39.560 --> 00:51:48.265
was just gonna say it's definitely worth the trade off because there's so many benefits that come with it that you wouldn't otherwise get. It gives you a unique set of benefits. It's definitely,

690
00:51:48.424 --> 00:51:55.465
I mean, it is a trade off, but everything in life is a trade off. And the benefits that you get for it is definitely worthwhile considering for

691
00:51:56.585 --> 00:51:57.464
a lot of use cases.

692
00:51:59.870 --> 00:52:03.230
Yeah. And generally, how I think about federated

693
00:52:03.230 --> 00:52:04.270
applications,

694
00:52:04.270 --> 00:52:06.830
like, we're building a federated eCache platform here.

695
00:52:07.390 --> 00:52:08.830
But, generally, most

696
00:52:09.230 --> 00:52:11.230
centralized services that you can build,

697
00:52:12.185 --> 00:52:15.785
you can probably also build in a federated way

698
00:52:15.945 --> 00:52:18.425
while that is much less

699
00:52:18.585 --> 00:52:22.025
easy to claim about a fully decentralized implementation.

700
00:52:22.425 --> 00:52:27.545
Like, there's a lot of problems that are just impossible to super hard to solve

701
00:52:27.630 --> 00:52:29.470
in a fully decentralized way.

702
00:52:30.029 --> 00:52:34.270
And many people are trying and, like, that's what's happening in shitcoin then, basically.

703
00:52:34.509 --> 00:52:40.589
Like, they're trying to solve a lot of really hard problems fully decentralized and end up with basically a federation with extra steps.

704
00:52:41.315 --> 00:52:45.635
So it's all Yeah. Comes down to, yeah, they have a multisig.

705
00:52:45.875 --> 00:52:53.235
While if you're just honest about, hey, we have a multisig here, then suddenly you get a lot of freedom to implement a lot of cool features.

706
00:52:53.555 --> 00:52:54.755
Like one thing, for example,

707
00:52:55.299 --> 00:52:59.619
Fadi built and Fadi built is a modular architecture, so you can just extend

708
00:52:59.619 --> 00:53:07.619
it, which makes it for an engineer like me, makes it really cool. It might be too much nerd talk, but the functionality that Fadi built is

709
00:53:07.859 --> 00:53:09.380
a way to stabilize

710
00:53:09.380 --> 00:53:10.099
your

711
00:53:10.875 --> 00:53:19.275
Bitcoin in the federation against, like, another asset like the US dollar. Like, I wouldn't do that. I don't think the US dollar's particularly stable.

712
00:53:19.435 --> 00:53:21.835
It goes down all the time. But, like,

713
00:53:22.395 --> 00:53:34.580
if you have a more shorter time frame that you're working on, then it makes sense, like, for a shop owner, if they want to keep their proceeds or, like, their income in USD because they have to restock pretty soon,

714
00:53:35.060 --> 00:53:38.580
then they can do that with Fedi. And

715
00:53:39.234 --> 00:53:43.714
there's a module in FADI Mint that allows you to hedge your Bitcoin exposure

716
00:53:43.714 --> 00:53:44.355
and

717
00:53:44.755 --> 00:53:46.995
basically hold a synthetic USD.

718
00:53:47.795 --> 00:53:51.875
And that solves the problem for real people. So I think that's really cool.

719
00:53:57.940 --> 00:54:00.180
The the other thing lose Met again.

720
00:54:02.100 --> 00:54:02.980
No. I don't think so.

721
00:54:04.965 --> 00:54:10.805
Was gonna say the other No, thing that's Amir, you guys are just running, so I'm enjoying the conversation. Continue, Herman. The

722
00:54:11.605 --> 00:54:12.485
other thing that

723
00:54:12.725 --> 00:54:14.485
I noticed that

724
00:54:14.485 --> 00:54:15.925
is really cool is

725
00:54:16.485 --> 00:54:18.869
that you can't, there's

726
00:54:18.869 --> 00:54:20.710
no better way to do this is,

727
00:54:20.950 --> 00:54:24.390
I mean, you'd be surprised how much attention people pay to

728
00:54:24.630 --> 00:54:25.670
fees in

729
00:54:25.990 --> 00:54:33.485
a setup where the transaction amounts are really, really small, you know, and you might be paying less than a dollar for most of your transactions,

730
00:54:33.725 --> 00:54:35.885
people pay attention to fees. And

731
00:54:36.445 --> 00:54:38.125
I mean, you can if

732
00:54:39.165 --> 00:54:43.645
you've got several people transacting between each other and a community and they're all on the same federation,

733
00:54:44.040 --> 00:54:48.760
you're sending e cash back and forth. There's literally zero fees on those transactions.

734
00:54:48.760 --> 00:54:57.640
And the only other way to do that is to onboard people to like a fully custodial wallet, like Wallet for Satoshi or Blink or whatever, and then sending transactions between each other

735
00:54:58.615 --> 00:55:00.535
in that wallet. And obviously the

736
00:55:00.935 --> 00:55:13.060
trade off between those two, it's way better to have zero fees sending one another eCash on a federation setup rather than onboarding people all to a fully centralized custodial wallet to

737
00:55:13.220 --> 00:55:15.380
cut down on the fees. But because the moment

738
00:55:16.260 --> 00:55:20.580
you're sending transactions over the Lightning Network, people do start noticing the fees.

739
00:55:21.300 --> 00:55:27.619
And they may be really low, but if you're talking about very, very small transactions, people do pay attention to that.

740
00:55:29.515 --> 00:55:32.155
It was surprising for me at first to see that,

741
00:55:33.035 --> 00:55:35.595
but that's definitely a worthwhile consideration.

742
00:55:36.635 --> 00:55:37.435
I

743
00:55:37.435 --> 00:55:42.075
mean, and not only that, you also have incredibly strong default privacy guarantees

744
00:55:42.360 --> 00:55:51.000
bringing financial privacy to people that maybe would not be able to afford it otherwise. On the fee piece, I actually have a technical question for you guys.

745
00:55:52.040 --> 00:55:54.760
So the whole federation's based on on chain Bitcoin.

746
00:55:55.665 --> 00:56:02.785
And presumably, it's particularly the South Africa example, think is probably a great example because a lot of Erman's users are probably,

747
00:56:03.265 --> 00:56:04.705
you know, they're sending

748
00:56:04.945 --> 00:56:06.625
$5 lightning transactions.

749
00:56:07.440 --> 00:56:11.680
All of this stuff is getting presumably at some point settled on chain.

750
00:56:12.320 --> 00:56:15.280
Is there, like, an automatic mechanism that is,

751
00:56:15.520 --> 00:56:23.455
like, combining UTXOs in the background so, like, the federation doesn't end up in a situation where they have a ton of tiny UTXOs

752
00:56:23.455 --> 00:56:24.335
and then

753
00:56:24.975 --> 00:56:29.695
on chain fees spike and then they're in I mean, this almost happened to Coinbase in 2017.

754
00:56:29.695 --> 00:56:33.215
When on chain fees went up, Coinbase had, like 600,000

755
00:56:33.215 --> 00:56:34.415
small UTXOs

756
00:56:34.415 --> 00:56:36.080
or something that were prohibitively

757
00:56:36.080 --> 00:56:37.920
expensive to spend on chain.

758
00:56:38.080 --> 00:56:40.800
Have you guys thought about that? How is that handled?

759
00:56:41.520 --> 00:56:42.480
Yeah,

760
00:56:42.480 --> 00:56:47.680
absolutely. So not to go into it too much, but Hermann and this new federation,

761
00:56:47.760 --> 00:56:51.595
they are running, they're running a V2 generation of modules,

762
00:56:51.595 --> 00:56:53.994
which, especially in that regard, work different.

763
00:56:54.474 --> 00:56:55.835
We gonna

764
00:56:56.155 --> 00:57:05.550
talk more about the V2 modules at some later point, not right now, because they're being still rolled out and we, you know, prefer to talk about stuff that we have already done.

765
00:57:06.349 --> 00:57:09.950
But the federation that Harman is running is it

766
00:57:10.670 --> 00:57:15.230
runs a Wallet V2 module, and it actually consolidates

767
00:57:15.465 --> 00:57:19.785
on every single peg in into the federation. It immediately consolidates

768
00:57:19.785 --> 00:57:21.625
into a single UTXO,

769
00:57:21.625 --> 00:57:22.425
and then

770
00:57:22.665 --> 00:57:24.025
it issues

771
00:57:24.425 --> 00:57:26.105
e cash to the corresponding

772
00:57:26.905 --> 00:57:28.505
to the exact increase

773
00:57:29.000 --> 00:57:30.280
in the federations

774
00:57:30.440 --> 00:57:35.720
UTXO wallet. Yeah. So it's only ever one. The federation only ever has a single UTXO

775
00:57:35.720 --> 00:57:36.760
in their wallet.

776
00:57:37.240 --> 00:57:45.905
That's quite awesome. So the the big benefit of that is that you can always make the user who made a transaction pay exactly the fee that they cost the federation.

777
00:57:46.145 --> 00:57:49.425
Like, what we want to avoid is that we kinda have to socialize

778
00:57:49.425 --> 00:57:51.505
the fees that we're paying for on chain.

779
00:57:51.745 --> 00:57:57.425
Like, you could, do, like, way fancier things if you allow that, but then it's

780
00:57:57.930 --> 00:57:59.130
just impossible

781
00:57:59.130 --> 00:58:03.930
to do that fairly. Like, there will always be some exploit where someone can just

782
00:58:04.810 --> 00:58:08.730
they give the federation a lot of small UTXOs basically and then

783
00:58:09.050 --> 00:58:10.410
drain the fee pool.

784
00:58:10.650 --> 00:58:10.970
So

785
00:58:11.625 --> 00:58:12.985
with this new version,

786
00:58:13.705 --> 00:58:17.705
what we're doing is just anyone who is doing any on chain operation,

787
00:58:18.025 --> 00:58:19.065
they are paying

788
00:58:19.385 --> 00:58:20.985
the cost that

789
00:58:21.305 --> 00:58:24.105
it takes the federation to either consolidate

790
00:58:24.360 --> 00:58:26.600
the UTXO they are sending into the

791
00:58:26.840 --> 00:58:30.520
one UTXO the federation holds or the fee to split it into

792
00:58:30.920 --> 00:58:31.720
like the

793
00:58:31.960 --> 00:58:35.880
amount that the user wants to receive and the change that goes back to the federation.

794
00:58:36.040 --> 00:58:38.360
So everyone's always paying for their own fees.

795
00:58:38.994 --> 00:58:42.595
Yeah. And we also wanted an option that has

796
00:58:43.875 --> 00:58:49.955
zero config and zero management especially, and if you say, okay, we allow for like multiple UTXOs,

797
00:58:50.515 --> 00:59:02.210
then you kind of to do it well, you need to manage that and basically, for example, if the fees start to rise, you would have to take a look and then you would have to do an educated guess, like how the fees are gonna develop

798
00:59:02.850 --> 00:59:14.575
and what your user behavior is gonna be and if it makes sense to consolidate some of the trends some of the UTXOs now. Otherwise, you might end up in a situation where the fees have risen significantly,

799
00:59:14.575 --> 00:59:22.079
and some of your UTXOs are not economically spendable anymore, or just in a situation where, like, users have to pay 20%

800
00:59:22.079 --> 00:59:25.839
of the on chain value that they're trying to transfer in fees. Yeah.

801
00:59:26.319 --> 00:59:27.040
So,

802
00:59:27.279 --> 00:59:31.359
to avoid avoid all that and really have a setup that has zero management,

803
00:59:31.519 --> 00:59:32.080
the

804
00:59:32.480 --> 00:59:40.185
most reliable option is immediate consolidation into a single UTX, or that's also why it was chosen. Like, we need to keep in mind that people,

805
00:59:40.505 --> 00:59:41.945
install a FettyMint

806
00:59:42.265 --> 00:59:44.185
on a box, and they

807
00:59:44.825 --> 00:59:47.705
like, it's either start nine with remote access or it's

808
00:59:47.945 --> 00:59:49.465
like a regular PC,

809
00:59:49.625 --> 00:59:54.480
and they unplug the monitor. They put it in the shelf, and then it just runs there for, like,

810
00:59:55.120 --> 00:59:56.880
months and years uninterruptedly

811
00:59:56.880 --> 01:00:00.640
besides, like, an update now and then similar to Bitcoin Core.

812
01:00:01.360 --> 01:00:02.160
Yeah.

813
01:00:03.040 --> 01:00:08.035
No. That's clever. That makes a lot of sense to me. And, I mean, it goes to reason that that would probably

814
01:00:08.915 --> 01:00:14.675
I mean, especially as it because it's automated, the lowest on chain fee burden possible for the Fediment,

815
01:00:14.995 --> 01:00:18.035
the I mean, short of like actively managing things. How

816
01:00:19.550 --> 01:00:22.510
is there like a confirmation time expectation?

817
01:00:22.510 --> 01:00:23.550
Because obviously,

818
01:00:24.190 --> 01:00:36.105
sometimes fees spike, but like, if you're willing to wait six hours or twelve hours for a confirmation, you can get away with much cheaper fees. Is there a technical limitation there where you need quick confirmations?

819
01:00:36.585 --> 01:00:44.425
Yeah. So, because it is a shared, like the UTXO is a shared resource, we can't have any users federation,

820
01:00:44.665 --> 01:00:57.720
any users transaction just pending there for like twelve hours because they wanted to save on fees. So, the federation is going to tell you the minimum fee it expects, and that should always be the one confirmation

821
01:00:57.720 --> 01:00:58.599
estimation

822
01:00:58.599 --> 01:01:01.724
from the Bitcoin Core node that they're running. So,

823
01:01:02.285 --> 01:01:04.365
there again, we are erring

824
01:01:04.525 --> 01:01:10.685
on the higher side, safer side. Yeah, so we will never have we will never have the

825
01:01:10.845 --> 01:01:12.765
absolute lowest fees

826
01:01:12.924 --> 01:01:16.610
of like someone that would batch transactions,

827
01:01:17.090 --> 01:01:24.370
maybe RBF them if if if they estimated the fees too low or it hasn't confirmed like after two hours.

828
01:01:25.490 --> 01:01:27.010
No, we always

829
01:01:28.305 --> 01:01:34.305
we always require enough fees to have the transaction confirmed, like probably within the next block.

830
01:01:35.984 --> 01:01:37.585
And I think when you assume that

831
01:01:39.840 --> 01:01:45.280
No. Was gonna ask a clarifying question there, or maybe just on behalf of people at

832
01:01:45.600 --> 01:01:48.080
a slightly less technical level of understanding.

833
01:01:50.560 --> 01:01:52.640
This only applies to on chain transactions,

834
01:01:53.325 --> 01:01:55.005
whereas Lightning transactions

835
01:01:55.165 --> 01:01:56.525
are obviously not

836
01:01:57.405 --> 01:02:04.205
has nothing to do with that single UTXO because the gateway is essentially just swapping its own e cash for SATs

837
01:02:04.285 --> 01:02:07.680
back and forth as transactions come in and It's

838
01:02:08.000 --> 01:02:09.520
only on chain transactions

839
01:02:09.520 --> 01:02:12.160
into the federation that gets consolidated

840
01:02:12.160 --> 01:02:12.800
into

841
01:02:13.599 --> 01:02:14.960
that UTXO, obviously.

842
01:02:17.040 --> 01:02:17.600
Yes.

843
01:02:18.160 --> 01:02:28.075
Like the cool thing here is that in a way we are batching all these Lightning transactions into like one large on chain transaction eventually.

844
01:02:28.315 --> 01:02:29.355
You can imagine,

845
01:02:29.675 --> 01:02:32.235
for example, a federation gets set up and

846
01:02:32.900 --> 01:02:38.580
the gateway deposits like 0.1 Bitcoin into the federation, and now the users are depositing.

847
01:02:38.820 --> 01:02:42.420
And after a while, they have deposited 0.08

848
01:02:42.500 --> 01:02:48.580
Bitcoins with federation. The gateway is slowly running out of e cash, and they notice, oh, we have all these Bitcoin in our lightning channels now,

849
01:02:49.194 --> 01:02:54.795
and we are lacking e cash, let's rebalance. And then they might send 0.05

850
01:02:54.795 --> 01:02:59.835
Bitcoin from their Lightning channels via something like Bolt Exchange to the federation

851
01:03:00.075 --> 01:03:05.190
and get more e cash. And then that's how they rebalance. And that's how the federation also gets

852
01:03:05.590 --> 01:03:11.430
more on chain Bitcoin into its wallet. That's in the end backing all the user funds.

853
01:03:12.070 --> 01:03:14.870
So the gateway has some float. They

854
01:03:15.684 --> 01:03:17.605
exchange between e cash

855
01:03:17.845 --> 01:03:19.765
that's backed by on chain Bitcoin

856
01:03:19.924 --> 01:03:22.325
and their Lightning liquidity.

857
01:03:23.204 --> 01:03:30.005
And then if the if it's a net inflow, then over time, they will have to deposit on chain just to get more e cash to swarm.

858
01:03:31.470 --> 01:03:32.030
Yeah.

859
01:03:33.150 --> 01:03:35.950
And what I want to say about the on chain

860
01:03:36.270 --> 01:03:37.230
discussion,

861
01:03:37.470 --> 01:03:42.990
like, my belief is Bitcoin will be successful. And it might take many years

862
01:03:43.470 --> 01:03:44.750
to decades,

863
01:03:44.750 --> 01:03:45.310
but eventually,

864
01:03:46.335 --> 01:03:49.455
Bitcoin will be so successful that most people don't really

865
01:03:49.775 --> 01:03:51.695
do on chain anymore.

866
01:03:51.935 --> 01:03:58.175
Like, we will have to find other ways of transacting for day to day. And so I think what we really need to optimize for

867
01:03:58.655 --> 01:03:59.055
is,

868
01:03:59.820 --> 01:04:07.180
yeah, good layer to support, like finding ways of batching transactions and only going on chain when absolutely necessary.

869
01:04:07.580 --> 01:04:13.340
So that's, I think, very much in line with not optimizing for the having the lowest on chain fees too much because

870
01:04:13.695 --> 01:04:16.735
we probably only have reasonably low on chain fees

871
01:04:16.975 --> 01:04:21.775
in the short term, not the long term. And I think we lost Matt. At least I don't see him anymore. So

872
01:04:22.575 --> 01:04:24.335
much for the good internet.

873
01:04:25.215 --> 01:04:25.535
Yeah.

874
01:04:26.130 --> 01:04:27.730
I think it's recorded

875
01:04:28.130 --> 01:04:30.849
locally though. Afterwards, you'll be able to

876
01:04:31.329 --> 01:04:31.810
up.

877
01:04:32.529 --> 01:04:34.130
Catch up, yeah. I guess

878
01:04:35.730 --> 01:04:36.450
we can

879
01:04:37.010 --> 01:04:39.250
just keep chatting while we wait for Matt to rejoin. But

880
01:04:40.155 --> 01:04:47.515
I was kinda surprised by the number of people I spoke to at the at well, actually, both both the Prague Conference and the Nairobi Conference

881
01:04:48.155 --> 01:04:49.595
that that's

882
01:04:49.595 --> 01:04:52.075
kind of kind of familiar with with Fedi,

883
01:04:54.089 --> 01:04:55.130
Wallet app,

884
01:04:55.450 --> 01:05:00.010
but have no idea what eCash is or that eCash actually

885
01:05:00.490 --> 01:05:05.210
predates Bitcoin. And that it was something that was kind of picked up by Bitcoiners

886
01:05:05.210 --> 01:05:05.849
and

887
01:05:06.575 --> 01:05:08.575
applied in a way that

888
01:05:09.375 --> 01:05:13.214
the creator did not maybe foresee, well, obviously didn't foresee when

889
01:05:13.694 --> 01:05:15.135
he came up with this idea.

890
01:05:16.494 --> 01:05:17.454
That's

891
01:05:17.454 --> 01:05:22.174
why I said I spent more time talking about this than my own project at the conference, because there's,

892
01:05:22.790 --> 01:05:26.550
I mean, outside of a small sort of group of people that are

893
01:05:26.869 --> 01:05:28.950
obsessive with this type of stuff,

894
01:05:29.670 --> 01:05:31.830
there's a lot of people, like it

895
01:05:31.830 --> 01:05:35.350
needed some explaining of what exactly is eCash and

896
01:05:35.670 --> 01:05:37.270
where does it come from and so on.

897
01:05:39.055 --> 01:05:45.135
Yeah, I mean, the question is, do we really need users or people to understand what is eCash?

898
01:05:45.455 --> 01:05:58.830
Like for the longest time, my philosophy has been that if we don't have to explain, we shouldn't. Like if it just works and people can just use ferrymand apps as a more convenient way of interacting with Bitcoin,

899
01:05:59.310 --> 01:06:08.615
then that should be good enough. And we don't have to bother them with, hey. There's this new concept eCache. It gives you this great privacy. They're getting it anyway. Why explain it to them?

900
01:06:08.935 --> 01:06:12.615
And then when they want to get additional benefits or when they get deep enough,

901
01:06:13.015 --> 01:06:24.570
then they will learn, hey. If I use this eCash stuff, then I can actually also send Bitcoin just like a chat message. Like, the conference in Croatia recently, I did a little experiment.

902
01:06:25.050 --> 01:06:31.210
I just sent some, e cash notes on bit mess BitCheck, and whoever claims it first, they get the sets.

903
01:06:31.985 --> 01:06:37.665
And I want to see how many people will get online with BitChat. And that's something you unique to eCash. You just

904
01:06:37.985 --> 01:06:39.905
have money that's data,

905
01:06:40.545 --> 01:06:44.560
and that's really cool. But for the average Joe who just needs

906
01:06:44.880 --> 01:06:47.440
free the money, needs to be financially empowered,

907
01:06:47.520 --> 01:06:50.400
I think it's too much. Like, the more you have to explain to get started,

908
01:06:50.559 --> 01:06:53.200
the harder it is to get people to actually use something.

909
01:06:53.760 --> 01:07:03.285
So I think the gradual approach makes a lot of sense of not overloading or not front loading too much. Yeah. That is one of the coolest features of eCache though, is that you

910
01:07:03.925 --> 01:07:05.445
can literally encode.

911
01:07:05.445 --> 01:07:08.725
It's literally a string of code and that is the eCache.

912
01:07:08.965 --> 01:07:17.540
Had to That took a while to get my head around that, but that is one of the coolest things that you can literally send it like you would give someone a physical

913
01:07:18.580 --> 01:07:19.700
fiat note.

914
01:07:19.860 --> 01:07:25.060
You can literally send this code over a chat message, and it's like sending cash

915
01:07:25.460 --> 01:07:26.660
over an internet connection.

916
01:07:27.204 --> 01:07:30.405
It's one of the coolest features. There were people that was encoding

917
01:07:30.805 --> 01:07:32.725
e cash notes into emojis,

918
01:07:32.964 --> 01:07:35.685
and that became a little bit of a game at some point in our

919
01:07:36.325 --> 01:07:38.325
local WhatsApp chat. That was quite fun.

920
01:07:39.045 --> 01:07:42.885
Yeah. Like what I did at a few conferences, I printed paper e cash.

921
01:07:43.500 --> 01:07:47.340
And, like, I think, Carlo did it first, so props to him.

922
01:07:47.820 --> 01:07:56.620
But, just having some physical voucher that you can hand to people, and you can make it look like real money, like some old US dollars or whatever. And it's

923
01:07:57.035 --> 01:07:59.275
it's just a super cool way to onboard people.

924
01:07:59.515 --> 01:08:07.195
They just scan it. They receive their sets right into their wallet. They get onboarded to the federation that I choose, and it's just very smooth.

925
01:08:08.155 --> 01:08:12.350
And I think also, like, the people not being aware of eCash,

926
01:08:12.510 --> 01:08:14.190
it's just a testament how

927
01:08:14.430 --> 01:08:20.350
big this space has become because, I mean, Cashew has done so much publicity work about the topic,

928
01:08:20.750 --> 01:08:26.625
you know. I can understand that people are not familiar with like what a federated system is, but

929
01:08:27.905 --> 01:08:38.065
there was like there was so much talk and publicity about e cash as a concept, but this space is so huge these days, like you can run into full time Bitcoiners and they have vaguely heard

930
01:08:38.989 --> 01:08:40.269
vaguely heard of this.

931
01:08:40.989 --> 01:08:41.710
Yeah.

932
01:08:43.070 --> 01:08:46.750
And that's what winning looks like. More options for users, the better.

933
01:08:47.949 --> 01:08:48.989
Yeah. Yeah.

934
01:08:50.030 --> 01:09:00.505
Guys, this has been a great conversation. I really enjoyed it. I love what you guys are building. Should we, before we wrap, let's, let's finish up with some final thoughts. We'll start with

935
01:09:01.385 --> 01:09:02.985
Arman final thoughts.

936
01:09:05.705 --> 01:09:08.025
Final thoughts. I think that

937
01:09:08.710 --> 01:09:10.310
it's, I mean, I was talking

938
01:09:11.510 --> 01:09:12.390
Frank

939
01:09:12.710 --> 01:09:16.710
the other day, and I do think that Frank Corva,

940
01:09:17.030 --> 01:09:19.430
and it's

941
01:09:19.430 --> 01:09:21.190
not an

942
01:09:20.625 --> 01:09:24.464
overstatement to say on my part that I think Fediment is

943
01:09:25.105 --> 01:09:29.664
probably gonna be one of the most important technologies in Bitcoin going forward, just because it

944
01:09:30.144 --> 01:09:30.945
creates

945
01:09:32.144 --> 01:09:33.425
this system where

946
01:09:33.985 --> 01:09:34.625
you can

947
01:09:34.960 --> 01:09:46.159
have an acceptable trust model. I see it as an acceptable trust model. I think a lot of people maybe have a problem with that, but in the environment that I'm in, I see it as an acceptable trust model and way better than a fully

948
01:09:46.559 --> 01:09:48.800
centralized trust model. And

949
01:09:50.515 --> 01:09:59.315
it's gonna be very necessary to have these types of systems where I feel okay onboarding somebody to this. I've always had a funny feeling when I onboard somebody to a fully centralized

950
01:09:59.635 --> 01:10:07.679
wallet service, no matter how good the experience is. It's kinda like, do I really wanna do this? But that's kind of like the only option. Whereas now it's

951
01:10:08.000 --> 01:10:16.880
a way more comfortable feeling to onboard somebody to something that I think is an acceptable trust model, but still has a really great user experience. So I think it's probably one of the most important

952
01:10:17.200 --> 01:10:18.640
technologies going forward.

953
01:10:21.204 --> 01:10:21.925
Love it.

954
01:10:22.965 --> 01:10:26.484
Maybe onto Herman's point, it's like the FAMER project is as

955
01:10:27.045 --> 01:10:42.840
much of a social experiment than it is one as a technical one. We put a new we put a lot of, like, new technologies together to, get to this point and make it work. Like, for example, which now even only makes it viable to run on Start nine,

956
01:10:43.159 --> 01:10:45.320
has just only released their OneNote,

957
01:10:45.815 --> 01:10:47.255
like two weeks ago

958
01:10:48.135 --> 01:10:51.495
and now really the question is, can we form like the social

959
01:10:51.655 --> 01:10:55.655
structures around those systems that, you know, make them work for

960
01:10:56.535 --> 01:10:57.735
like communities,

961
01:10:57.735 --> 01:10:59.095
everyday people and so forth.

962
01:11:02.480 --> 01:11:05.599
Love that. Which for me kind of out of my hands.

963
01:11:06.000 --> 01:11:09.999
Yeah. Yeah, makes sense to me. It is a social problem. Those are the hardest ones.

964
01:11:11.119 --> 01:11:14.880
Yeah, to tie back to something you mentioned in the beginning, bear markets are for building

965
01:11:15.454 --> 01:11:16.014
And

966
01:11:16.494 --> 01:11:19.135
more than ever before, we have to need to

967
01:11:19.695 --> 01:11:23.934
fight for our privacy, fight for our freedom. Join us, and thanks for having us on.

968
01:11:24.494 --> 01:11:31.400
Yeah. Thank you, guys. It's an honor and a privilege. Freaks, I hope you enjoyed the conversation. We'll be back next Tuesday.

969
01:11:31.800 --> 01:11:38.600
I got another great conversation lined up. All relevant links will be in the show notes. All relevant links for the show are at civildispatch.com.

970
01:11:38.600 --> 01:11:43.560
Share with your friends and family. Search Civil Dispatch in your favorite podcast app. Thank you guys for joining us.

971
01:11:44.884 --> 01:11:48.403
Awesome, dude. Thank you. Thank you. Yeah. Take care. Bye.

972
01:11:48.884 --> 01:11:50.963
Love y'all. Stay humble, StackSets.

973
01:11:51.364 --> 01:11:51.843
Peace.