1
00:00:03,116 --> 00:00:13,161
Hello and welcome to the Nostr Compass podcast episode seven, where we walk through this
week's news in the Nostr development ecosystem.

2
00:00:13,322 --> 00:00:28,930
We have a couple of interesting topics to cover, including a new taxi app on Nostr called
RideStir, um as well as updates to the apps like Damos, Ember, and so on.

3
00:00:28,930 --> 00:00:32,456
We also will talk about Pomade, which is a

4
00:00:32,456 --> 00:00:44,024
multi-signature key recovery mechanism and we will have a historical deep dive into
everything that happened every January since 2021.

5
00:00:44,024 --> 00:00:51,250
So if you're in for some history on how we got here, this episode is for you.

6
00:00:51,491 --> 00:00:58,506
So let's get going with the first new interesting release that happened last week and that
was the introduction of Rides-ter.

7
00:00:58,593 --> 00:01:03,235
which is a decentralized ride sharing app over the Nostra network.

8
00:01:03,317 --> 00:01:14,356
And I think this is quite cool because that was one of the very early ideas of Nostra back
with Diagon Alley of having peer-to-peer Uber basically.

9
00:01:14,417 --> 00:01:21,022
So good to see that after five years of thorough protocol development, the building blocks
start to seem to be here.

10
00:01:21,142 --> 00:01:24,264
So a couple of new event kinds are introduced here,

11
00:01:24,429 --> 00:01:39,190
The driver can use to announce his rough location and then the user or the rider itself
can uh send a direct message requesting a ride at a certain pickup location.

12
00:01:39,190 --> 00:01:43,812
There's also a pin handshake to make sure you're actually going into the right car.

13
00:01:43,893 --> 00:01:53,859
And payment is done via eCash, specifically Cachue tokens, which are locked with a hash
time lock contract for the escrow script.

14
00:01:54,254 --> 00:01:57,202
so that theft is hopefully less likely.

15
00:01:57,202 --> 00:01:58,886
There's a lot of interesting nuances here.

16
00:01:58,886 --> 00:02:02,263
What do you think about the general idea and their implementation?

17
00:02:02,263 --> 00:02:03,233
This is very interesting.

18
00:02:03,233 --> 00:02:11,637
I've been wanting to see more rideshare stuff come up to the market, especially because
I've noticed on shops that people actually list rideshare requests.

19
00:02:11,637 --> 00:02:15,469
So it's interesting to see that finally there's an application dedicated to it.

20
00:02:15,469 --> 00:02:19,960
And it's cool that they're now playing around with the HTLC escrow.

21
00:02:20,241 --> 00:02:24,016
Because we actually were working with something with that uh on our implementation.

22
00:02:24,016 --> 00:02:25,927
And yeah, there's a lot of interesting stuff here.

23
00:02:25,927 --> 00:02:29,858
I haven't fully dived into it, but yeah, I've been wanting to see more.

24
00:02:30,172 --> 00:02:41,394
playing around with recreating, especially this type of system, because getting over the
Uber and uh Lyfts of the world, being able to actually take back more of a cut as a driver

25
00:02:41,394 --> 00:02:45,514
would be monumental for people that are actually working in it.

26
00:02:45,514 --> 00:02:52,567
Is the escrow mechanism built into the protocol itself or is it in the app or tied up with
the mint?

27
00:02:52,567 --> 00:02:53,752
Does anyone know?

28
00:02:53,752 --> 00:03:03,307
Yeah, from what I was seeing, seems like it's uh currently still uh required that every
rider and driver use their escrow within the same mint.

29
00:03:03,307 --> 00:03:04,608
So there's no...

30
00:03:04,628 --> 00:03:06,785
It's tied up within the cashew protocol itself.

31
00:03:06,785 --> 00:03:08,669
It uses like not 14.

32
00:03:08,669 --> 00:03:10,279
But yeah, there's no...

33
00:03:10,279 --> 00:03:11,769
It's not like...

34
00:03:11,844 --> 00:03:14,427
There's no other uh integration or anything.

35
00:03:14,427 --> 00:03:17,901
It's just solely based on the same cashew mint as long as it supports it.

36
00:03:17,901 --> 00:03:21,242
I'm assuming since it's probably not super widespread,

37
00:03:21,431 --> 00:03:23,015
support across all catchments.

38
00:03:23,015 --> 00:03:26,153
They can't really have a swapping mechanism yet and they want to make sure everything is
reliable.

39
00:03:26,153 --> 00:03:29,951
But yeah, at least from what I've read, that seems like the implementation.

40
00:03:30,573 --> 00:03:34,795
Nice isn't this what Ethereum guys have been promising us for so long

41
00:03:34,795 --> 00:03:39,143
It turns out you don't need a blockchain for taxis on the internet.

42
00:03:39,143 --> 00:03:42,288
Neither for the taxi coordination nor for the payment.

43
00:03:42,710 --> 00:03:43,682
So that is fun.

44
00:03:43,682 --> 00:03:45,187
One question is...

45
00:03:45,187 --> 00:03:49,889
The main thing that I would be concerned about with a project like this is going to be uh
privacy.

46
00:03:49,889 --> 00:04:00,634
um If other people are able to see the activity that's going on between drivers and
riders, there'd be a lot of uh opportunities for $5 wrench attacks and that sort of thing.

47
00:04:00,634 --> 00:04:10,879
I do see there's some stuff about sending events directly and bypassing relays, um but
there's uh definitely a lot of risk there that needs to be managed.

48
00:04:11,318 --> 00:04:18,582
Also a reputation system for the driver, which might also be a potential adversary, as
well as the driver.

49
00:04:18,582 --> 00:04:22,284
So targeted attacks would be dangerous here.

50
00:04:22,284 --> 00:04:25,396
Thankfully, we have Web of Trust to at least address some of that.

51
00:04:25,396 --> 00:04:32,656
And one question I have is like, why do we need this custom kind and custom nibs?

52
00:04:32,656 --> 00:04:36,287
Isn't good enough to just put it on a NIP 99 marketplace like Shopster.

53
00:04:36,287 --> 00:04:36,851
you

54
00:04:36,851 --> 00:04:40,253
I'd say though, it's, sorry, I'll jump in here real quick.

55
00:04:40,253 --> 00:04:51,668
think it's, it's better to err on the side of, I was having a discussion with somebody
about this a few days ago, but it's better to err on the side of adding new kinds than

56
00:04:51,668 --> 00:04:57,051
trying to push new functionality into existing apps.

57
00:04:57,051 --> 00:05:06,835
So a lot of the, I don't want to speak for Calvative, but a lot of the existing 99 apps
are built around selling and buying and listing.

58
00:05:07,129 --> 00:05:19,019
physical goods and products and images and what not to add to them which it's a economic
transaction but it's fundamentally different than asking uh or paying for someone to take

59
00:05:19,019 --> 00:05:20,660
you from point A to point B.

60
00:05:20,660 --> 00:05:31,030
So trying to overload the or overloading the event kind just ends up in the long run
making more complexity on the app side.

61
00:05:31,030 --> 00:05:32,571
Yeah, yeah, completely agree.

62
00:05:32,571 --> 00:05:42,847
the especially what we've noticed, even adding simple things like different shipping
mechanisms or checkout event flows or any of that stuff, like basically in order for

63
00:05:42,847 --> 00:05:51,902
things to stay interoperable and for things to like be streamlined, especially when
people's money is like directly being exchanged, like there has to be a lot of care taken

64
00:05:51,902 --> 00:05:54,793
into making sure that everything like works seamlessly.

65
00:05:54,793 --> 00:05:59,175
And if that isn't done, then there's just a lot of bloat and

66
00:05:59,549 --> 00:06:00,611
on the client side.

67
00:06:00,611 --> 00:06:07,248
like all these applications then have to like include all of the development for all the
ride sharing requests and to make sure everything's done properly.

68
00:06:07,248 --> 00:06:14,246
Because if someone pays for a ride sharing request, but it doesn't actually go through or
people don't actually see anything that's happening, then like the service just isn't a

69
00:06:14,246 --> 00:06:16,008
good experience for anyone.

70
00:06:16,044 --> 00:06:25,658
Next up we have pomade, which is a frost-based threshold signing scheme for Noster
messages or Noster events.

71
00:06:25,778 --> 00:06:36,066
And it's specifically done here to provide easy onboarding to people who are not
comfortable with a regular cryptography and key backups.

72
00:06:36,066 --> 00:06:43,939
So this would mean that a group of third parties are holding each a shard of your private
key.

73
00:06:43,983 --> 00:06:47,728
And none of them alone can create a signature, but they have to work with each other.

74
00:06:47,728 --> 00:06:54,693
This can also be helpful for backup and recovery of that key.

75
00:06:54,693 --> 00:07:00,938
If for example, you lose your phone and you didn't make a backup and yeah, but tell us a
bit more about this.

76
00:07:00,938 --> 00:07:09,911
Yeah, so the thing I learned working on this was that email-based login workflows are both
horrendously insecure and really clunky and annoying in UX terms.

77
00:07:09,911 --> 00:07:17,170
So I wanted to take uh both of those attributes, the insecurity and the terrible UX, and
bring them to Nostr.

78
00:07:17,170 --> 00:07:19,130
So that's my innovation here.

79
00:07:19,130 --> 00:07:29,789
um No, but the UX of email-based login is familiar to uh non-Nostr users, people who don't
know what keys are.

80
00:07:29,789 --> 00:07:39,810
um And so I wanted to make Nostra a little bit more accessible to new people, specifically
to solve problems on Flotilla uh in terms of user adoption.

81
00:07:39,826 --> 00:07:49,511
And yeah, the basic idea is you go, you sign up with your email and password, you get a
confirmation email, you log in, you do stuff, you log out, you log back in with the same

82
00:07:49,511 --> 00:07:56,345
email and password, um and you can uh recover your account uh with some OTP stuff.

83
00:07:56,345 --> 00:07:57,725
So it's very familiar.

84
00:07:57,725 --> 00:07:58,798
um

85
00:07:58,798 --> 00:08:11,205
But when you're ready to take custody of your key, you can delete your session on the
remote bunkers and ah take custody of your key without anyone ever having held the whole

86
00:08:11,205 --> 00:08:12,065
thing.

87
00:08:12,145 --> 00:08:23,097
And the workflow for that is a little bit clunky as well, of course, because you're going
to get separate emails with one-time passwords from each of your potentially three

88
00:08:23,097 --> 00:08:23,577
bunkers.

89
00:08:23,577 --> 00:08:24,797
ah

90
00:08:24,797 --> 00:08:29,482
and then you can recover the shards themselves reconstituted client side.

91
00:08:29,482 --> 00:08:34,687
the client is the only software that sees the whole key.

92
00:08:34,687 --> 00:08:47,880
And because we're using OTPs over email that invalidate after use, then there's not as
much of a danger of uh email providers middle manning the recovery process.

93
00:08:48,138 --> 00:08:54,551
So lots of trade-offs here, and I'm definitely in over my head in terms of cryptography
and the security model.

94
00:08:54,551 --> 00:09:03,975
uh I'm using argon2id hashing for locking passwords uh to each signer based on their
pubkey.

95
00:09:03,975 --> 00:09:06,056
I'm using the signer pubkey as a hash.

96
00:09:06,056 --> 00:09:13,018
So if any of that sounds interesting, either in terms of what I'm trying to accomplish or
in terms of the technical challenge, please get in touch.

97
00:09:13,018 --> 00:09:17,330
I would like more eyes on the protocol before I start rolling it out.

98
00:09:17,348 --> 00:09:20,932
And if you're interested in running a bunker as well, please let me know.

99
00:09:20,932 --> 00:09:27,314
um Hopefully we can bring the UX of Noster back down to the standard.

100
00:09:27,314 --> 00:09:31,554
Do you consider what are the practical limits in terms of the size of the threshold?

101
00:09:31,554 --> 00:09:33,565
Like could we have a 5 out of 100?

102
00:09:33,565 --> 00:09:47,316
Yeah, so because we're using our Argon 2 ID, which is GPU resistant hashing algorithm,
there's only so many signers that you can be working with at the same time with a client.

103
00:09:47,316 --> 00:09:51,116
So the hashes take 400 to 800 milliseconds a piece.

104
00:09:51,116 --> 00:09:59,216
And so if you have 100 different signer backends and you try to log in, you don't know
which signer is holding the user's threshold.

105
00:09:59,216 --> 00:10:01,107
So you have to ask all of them.

106
00:10:01,107 --> 00:10:03,429
So that would be prohibitive.

107
00:10:03,429 --> 00:10:05,350
That would be one bottleneck.

108
00:10:05,350 --> 00:10:11,636
And then in terms of just the Frost multisig stuff, I think you can scale up pretty high.

109
00:10:11,636 --> 00:10:16,880
I've seen numbers like 16 being the uh total on the quorum.

110
00:10:16,880 --> 00:10:21,074
I think it starts to get more expensive at that level, but I would not be the person to
ask about that.

111
00:10:21,074 --> 00:10:21,845
is that if...

112
00:10:21,845 --> 00:10:26,667
Do you think this is ever useful if a user already has a backup of his key?

113
00:10:26,667 --> 00:10:28,547
Or is this always before that stage?

114
00:10:28,547 --> 00:10:32,699
uh So, yeah, so um this is before that stage.

115
00:10:32,699 --> 00:10:42,850
So, you know, if you ask the user to back up their key first thing, you're subjecting the
key to the same level of vulnerability as like a password or something.

116
00:10:42,891 --> 00:10:44,712
And if they lose it, then they're out of luck.

117
00:10:44,712 --> 00:10:48,298
And, you know, that's just part of the learning process of dealing with keys.

118
00:10:48,298 --> 00:10:52,821
And so what I would like to do is defer the need to take a backup until later.

119
00:10:52,821 --> 00:10:56,803
So the idea is you sign up, you don't take a backup of your key.

120
00:10:56,803 --> 00:10:59,165
It's held on the signers.

121
00:10:59,165 --> 00:11:05,279
And then when your account becomes valuable, you can then take custody of that key removed
from the signers.

122
00:11:05,279 --> 00:11:10,923
ah Obviously, uh of things that the signers can do to be malicious, potentially.

123
00:11:10,923 --> 00:11:12,974
yeah, that's the idea.

124
00:11:12,974 --> 00:11:28,556
Yeah, I was just concerned that if there is collusion the user doesn't get to know that
they have been colluded with and the colluders can decrypt uh things without them knowing,

125
00:11:28,556 --> 00:11:30,466
uh which is a concern.

126
00:11:30,466 --> 00:11:37,029
My uh thought process was could we do something to notify the user if something like this
happens?

127
00:11:37,118 --> 00:11:40,018
Yeah, well for decryption, I don't think there's much you can do.

128
00:11:40,018 --> 00:11:48,547
You could potentially notify the users based on, know, if someone tries to log in to their
account or succeeds in logging into their account.

129
00:11:48,547 --> 00:11:56,453
But then, you know, that relies on the user monitoring some channel of communication,
whether it's IP 17 DMs or their email address.

130
00:11:56,453 --> 00:12:04,571
uh I just, I haven't seen anything that really uh works in such a way that the complexity
is worth it.

131
00:12:04,660 --> 00:12:08,572
You know, it's just someone has to be paying attention and people tend to not pay
attention.

132
00:12:08,572 --> 00:12:11,223
So I'm not sure there's much we can do about that.

133
00:12:11,223 --> 00:12:15,214
And for the decryption thing, you know, that would be entirely silent.

134
00:12:15,214 --> 00:12:25,789
you know, I think uh the custodians have to be trusted in this setup, which is, you know,
not a trade off that I'm going to take with my key, but is a trade off that I think works

135
00:12:25,789 --> 00:12:30,775
for, you know, newly generated keys that ah are for people trying things out.

136
00:12:30,775 --> 00:12:35,985
But yeah, like a signer bunker selection or custodian selection is really important.

137
00:12:35,985 --> 00:12:42,387
The client should have like a hard-coded list of people that the developer himself
legitimately trusts.

138
00:12:42,387 --> 00:12:53,734
um Because, you know, if we're gonna go full NIP-89 on this, then any old custodian could
get in, symbol attack it, steal everyone's keys.

139
00:12:53,734 --> 00:12:57,559
they're definitely, it's built on social trust for sure.

140
00:12:57,559 --> 00:13:05,703
And is there a way that these bunkers know the other people or servers who are involved uh
in a certain quorum?

141
00:13:07,523 --> 00:13:09,392
uh No, I don't think there's any identifying information.

142
00:13:09,392 --> 00:13:12,353
mean, you could always do timing attacks or something like that.

143
00:13:12,353 --> 00:13:17,342
um Or if you're colluding uh with other bunkers.

144
00:13:17,342 --> 00:13:21,465
You could look at a client and you could say, oh, they use these six custodians or
something like that.

145
00:13:21,465 --> 00:13:26,623
I'm going to go talk to people who run those things and then we'll steal keys secretly.

146
00:13:26,623 --> 00:13:31,885
But yeah, there's nothing in the protocol that allows them to link each other.

147
00:13:31,885 --> 00:13:34,401
I'd be happy for anyone to prove me wrong on that, though.

148
00:13:34,401 --> 00:13:41,852
Yeah, that would improve the trust assumptions also, since an adversary would not know
with whom to collude.

149
00:13:41,852 --> 00:13:48,434
Yeah, and the more more that the custodians there are involved, the stronger the
protection gets.

150
00:13:48,434 --> 00:13:56,827
Because if you have 20 custodians and you need a quorum of three, um then you're going to
have all permutations of those 20 custodians.

151
00:13:56,827 --> 00:14:03,914
if three of them are corrupt and colluding, or I guess two of them corrupt and colluding,
then they would only have access to

152
00:14:04,025 --> 00:14:06,630
a small number of the Bunker sessions.

153
00:14:06,630 --> 00:14:08,813
So some people lose their keys.

154
00:14:09,015 --> 00:14:14,243
And of course, the flip side of that is the more custodians that you introduce, the more
trust uh is in the system.

155
00:14:14,267 --> 00:14:31,520
I was going to say with open source applications, it would not be hard to probably just
take a look and see who the threshold, sorry, who the signers are, or whatever we call

156
00:14:31,520 --> 00:14:33,851
them, whoever holds the parts of the keys.

157
00:14:33,851 --> 00:14:37,302
I think we can get away with some things, but yeah, sorry, go ahead.

158
00:14:37,302 --> 00:14:42,937
Yeah, yeah, at the end of the day, this is just a substitute for the client software
holding your key itself.

159
00:14:42,937 --> 00:14:47,047
So you do have to trust the client in this situation.

160
00:14:47,047 --> 00:14:52,062
And this would also lend itself nicely to trusted execution environments running on a
server.

161
00:14:52,063 --> 00:15:04,274
This way the service provider cannot steal or collude with others and clients could
validate the exact code and logic that is running in that custodial signing provider.

162
00:15:04,274 --> 00:15:06,668
Yeah, yeah, that would be a really helpful upgrade.

163
00:15:06,668 --> 00:15:07,369
That's a good idea.

164
00:15:07,369 --> 00:15:09,850
I will look at adding that to the protocol.

165
00:15:09,850 --> 00:15:18,906
On a tangent with TEEs, is there a risk of the manufacturer having a copy of the keys and
being able to decrypt?

166
00:15:18,906 --> 00:15:24,768
Because I've been reading about it and I think that's an open issue that not everybody's
addressed.

167
00:15:24,804 --> 00:15:29,928
Yeah, this depends on the exact algorithm or hardware provider.

168
00:15:29,929 --> 00:15:35,835
With some of them, you only have trust at the machine, at the factory time, basically.

169
00:15:35,835 --> 00:15:41,328
So if they would have kept the copy at the factory time, then you would be compromised.

170
00:15:41,328 --> 00:15:49,201
But if they did delete at factory time and only years later turn malicious, then they are
no longer in the trusted spectrum.

171
00:15:49,201 --> 00:15:56,186
So yeah, this, depends, but with hardware, ultimately you always have trust in the
producer of that hardware.

172
00:15:56,186 --> 00:15:59,771
And it becomes even harder to verify because it's all encrypted.

173
00:15:59,771 --> 00:16:01,253
So you can't verify.

174
00:16:01,565 --> 00:16:06,705
Yeah, and you would have to do a full scan of x-ray scan of the entire hardware that you
got.

175
00:16:06,705 --> 00:16:10,425
Maybe it was tampered with shipment, et cetera.

176
00:16:10,425 --> 00:16:11,845
So hardware is tough.

177
00:16:11,845 --> 00:16:13,736
We have it easy in software land.

178
00:16:13,736 --> 00:16:17,636
And we can move on to some real releases in this week.

179
00:16:17,636 --> 00:16:19,156
There were four in total.

180
00:16:19,256 --> 00:16:27,756
Let's start with Damos version 1.13, which ships the neck entropy implementation we spoke
about in the previous week.

181
00:16:27,795 --> 00:16:35,441
So again, neck entropy is an efficient set reconsolidation mechanism between a client and
a relay or two relays.

182
00:16:35,441 --> 00:16:40,896
So you only request the events in that relay that you do not have in your local database.

183
00:16:40,896 --> 00:16:50,315
So this makes Damos hopefully much faster and more reliable and also safe on some
bandwidth, which Noster messages always suffer from.

184
00:16:50,315 --> 00:16:54,528
There was also a better pull to refresh synchronization mechanism.

185
00:16:54,568 --> 00:16:57,837
or the DMs that now also uses neck entropy.

186
00:16:57,837 --> 00:17:00,835
Any thoughts on Neck entropy or that specific Damos release?

187
00:17:00,835 --> 00:17:01,875
Negentropy is great.

188
00:17:01,875 --> 00:17:09,298
eh I wish that Stirfry, uh the relay that Doug, who also invented Negentropy, supported it
properly.

189
00:17:09,298 --> 00:17:12,019
It does have Negentropy, but it doesn't signal it properly.

190
00:17:12,019 --> 00:17:15,348
ah Just a gripe that I discovered kind of recently.

191
00:17:15,348 --> 00:17:17,557
uh yeah, I think Negentropy is huge.

192
00:17:17,557 --> 00:17:21,925
It's glad to see one of the bigger clients adopting it.

193
00:17:21,925 --> 00:17:33,012
Yeah, this will be good for either promoting relay operators or just promoting people
start adding it as a, to start supporting it because the more it gets support, the more we

194
00:17:33,012 --> 00:17:38,916
can start relying on it and then the more you can start building clients and assuming that
it's there.

195
00:17:39,447 --> 00:17:40,228
Yeah, I agree.

196
00:17:40,228 --> 00:17:45,154
I really wanted more relays to support neg entropy for the NosterStats project.

197
00:17:45,154 --> 00:17:55,815
um And I've got one or two relays that I'm relying on for it, but it'd be really, really
good if all of them did, or at least you had some good signaling mechanism for it.

198
00:17:56,575 --> 00:18:00,218
Moving on to Ember version 4.1.1.

199
00:18:00,218 --> 00:18:05,142
This ships also what we talked about last week, and that was the trusted relay assertion
snip.

200
00:18:05,142 --> 00:18:11,748
So here's where others can give trust scores or quality scores to external relays.

201
00:18:11,748 --> 00:18:20,978
And now Ember can quickly filter out the relays that you are connecting to uh based on the
quality that your friends say.

202
00:18:20,978 --> 00:18:22,619
So this is quite useful.

203
00:18:23,072 --> 00:18:24,024
And Ember.

204
00:18:24,024 --> 00:18:28,083
can support this now if you do connect it to the internet.

205
00:18:28,083 --> 00:18:30,184
And Amber can run completely offline.

206
00:18:30,184 --> 00:18:32,204
And then this feature would not be there.

207
00:18:32,204 --> 00:18:35,164
But in the online mode, it works.

208
00:18:35,404 --> 00:18:45,524
There is also a little bit of UI work in their current polish, which now handles the
switch relays method in a new prettier user interface.

209
00:18:45,884 --> 00:18:49,044
Amber is coming along nicely with better UI.

210
00:18:49,144 --> 00:18:51,810
Plus some performance improvements that

211
00:18:51,810 --> 00:18:54,775
will specifically help you if you have an older device.

212
00:18:54,833 --> 00:19:00,618
Next up, have NUC, the Nostor Army Knife, with version 0.18.2.

213
00:19:00,618 --> 00:19:04,741
And now it adds a model context protocol support.

214
00:19:04,741 --> 00:19:13,173
So AI agents can search for people on Nostor or publish notes, mention users, all of the
use cases that NUC can do.

215
00:19:13,173 --> 00:19:19,424
You can now expose via an MCP server to your agent so that the vibes flow better.

216
00:19:19,424 --> 00:19:27,838
This is actually a really interesting one for me today because I saying before we started
recording I've got a uh clawed bot which is now called open clawed which was also called

217
00:19:27,838 --> 00:19:39,343
molt bot and for a moment there uh But I got a server set up there with this and I gave it
NAC I basically put NAC on the you know installed it on that machine and then just told

218
00:19:39,343 --> 00:19:49,158
the agent via telegram Hey, you have access to this tool called NAC go find it and look it
up uh And it immediately could start using it basically, but I think having an MCP server

219
00:19:49,158 --> 00:19:59,687
there would be an even easier way for it to be able to interact with it um for especially
a lot of ah the kind of open codes and quad codes when you're running it in the terminal.

220
00:19:59,687 --> 00:20:01,956
So it's really cool to see that it's been added.

221
00:20:01,956 --> 00:20:13,871
Yes, and also what helps here in the setup is there's a new install script which you can
get from GitHub and that removes the requirement to install Go on your machine to actually

222
00:20:13,871 --> 00:20:16,062
get this tool.

223
00:20:16,222 --> 00:20:17,522
So that's quite good.

224
00:20:17,522 --> 00:20:22,404
Now agents can install NUC for themselves in a single one-liner.

225
00:20:22,985 --> 00:20:29,407
Plus the bunker integration also now supports Unix sockets as a direct transport layer.

226
00:20:29,483 --> 00:20:33,725
Is that part of NIP55 or is that just a NAP thing?

227
00:20:34,405 --> 00:20:35,982
That is a good question, I don't know.

228
00:20:35,982 --> 00:20:39,176
I haven't heard it anywhere else, but I also haven't been looking.

229
00:20:39,410 --> 00:20:41,318
Interesting to check that.

230
00:20:42,117 --> 00:20:46,693
We have SUS version 0.12.2 beta being released.

231
00:20:46,796 --> 00:20:53,508
Here are the main noteworthy aspects are the Nostra Wallet Connect fixes, which we in
depth covered last week.

232
00:20:53,508 --> 00:20:55,461
So you can get that release now.

233
00:20:55,609 --> 00:20:59,201
And we can jump forward to our project updates.

234
00:20:59,381 --> 00:21:02,963
Let's start with white noise and the Marmot protocol.

235
00:21:03,303 --> 00:21:11,248
MIP3 got a pull request merge to specifically handle, again, the deterministic commit
resolution.

236
00:21:11,348 --> 00:21:13,329
And we did cover this last week.

237
00:21:13,329 --> 00:21:15,510
And in the meantime, this got merged.

238
00:21:15,931 --> 00:21:23,705
There is also a new PR that ensures that each group converges on the same state.

239
00:21:23,705 --> 00:21:26,067
if when there are multiple valid commits.

240
00:21:26,147 --> 00:21:28,990
So here, continuous protocol refinement.

241
00:21:29,110 --> 00:21:35,616
And there's also a PR to the spec, which adds an init key lifecycle requirement.

242
00:21:35,757 --> 00:21:47,338
So this means that we can use private key material from the welcome messages, and they
must be securely deleted after being processed to address any keys in memory potential

243
00:21:47,338 --> 00:21:47,879
attacks.

244
00:21:47,879 --> 00:21:59,910
Yeah, I mean, I the main thing here is that it was an update to the spec to make it more
clear as to how um apps should handle the key package key, which is this init key.

245
00:21:59,910 --> 00:22:05,490
um You know, we use what's called a last resort key package in the protocol.

246
00:22:05,490 --> 00:22:08,311
And I went back and forth with the auditors a lot on this point.

247
00:22:08,311 --> 00:22:16,779
um You know, there is a replay risk there of if the init key from a key package leaks and
you have a whole bunch of

248
00:22:16,779 --> 00:22:18,400
welcomes out there in the wild.

249
00:22:18,400 --> 00:22:24,365
If they could somehow get a hold of those welcomes, then they would be able to replay
those welcomes and join these groups.

250
00:22:24,365 --> 00:22:30,518
um Now, in our case, there's like four other layers of things they would have to get
through.

251
00:22:30,518 --> 00:22:36,763
So they would need to be able to decrypt the NIP44 encrypted welcome message that is sent
directly to you.

252
00:22:36,763 --> 00:22:40,095
So they would actually have to have your NOSTER private key as well.

253
00:22:40,096 --> 00:22:43,998
And if they have your NOSTER private key, they basically have the keys to the castle.

254
00:22:44,362 --> 00:22:45,683
But I think it is important

255
00:22:45,683 --> 00:22:56,070
that we made it really clear that when you join a group, you know, via these key packages,
what you need to do is replace the key package on the relays and make sure that you delete

256
00:22:56,070 --> 00:23:01,573
the local um init key that you're storing in the MLS storage.

257
00:23:01,573 --> 00:23:06,537
Make sure that gets deleted as soon as you've joined the groups that you need to join with
that key.

258
00:23:06,537 --> 00:23:15,057
um And then we've also kind of hardened up the language a little bit around like how
quickly you should perform a self-update, which basically

259
00:23:15,057 --> 00:23:17,994
rotates that key once you've joined a group.

260
00:23:17,994 --> 00:23:24,298
It's both good practice but also it helps to improve the forward secrecy for everybody in
the group when you do that.

261
00:23:24,298 --> 00:23:36,082
So it uh was kind of uh small wording changes, but like you said, it kind of adds up with
all of the stuff we were doing about commit resolution, race conditions, and just making

262
00:23:36,082 --> 00:23:43,832
sure that the protocol is going to do what it needs to do when it gets into a situation
where there's lots of people making commits and doing lots of different things.

263
00:23:43,832 --> 00:23:52,526
Yeah, commit resolution on an unreliable non-global network like Nostra is a bit
difficult, but I think we can make it work.

264
00:23:52,526 --> 00:23:57,709
We also have numerous changes to the Marmot TS TypeScript SDK.

265
00:23:58,149 --> 00:24:10,016
There were at first a bunch of demo mini apps being built, and they are now being
integrated into an actual chat application as a reference demo app.

266
00:24:10,036 --> 00:24:19,021
So this now supports creating and publishing the key packages, as well as deleting them,
and creating a group and adding people to the group.

267
00:24:19,221 --> 00:24:20,982
And there were now some

268
00:24:20,982 --> 00:24:26,707
Open PRs merged with history persistence and pagination.

269
00:24:26,708 --> 00:24:30,561
So this means that your chats will be there when you reload the browser.

270
00:24:30,561 --> 00:24:40,869
And there were also further numerous PRs merged to the white noise rust uh back end layer,
which with further improvements.

271
00:24:41,190 --> 00:24:44,354
Maybe Hazard, you can give us a quick update on the marmots.

272
00:24:44,354 --> 00:24:48,394
Yeah, I've been just slowly working on that, getting that going.

273
00:24:48,614 --> 00:24:53,774
The MLS layer seems to be working pretty well, and the NostraTransport is working.

274
00:24:53,774 --> 00:24:57,870
now it's just been a matter of...

275
00:24:57,870 --> 00:25:03,082
taking the code we've written and creating a simple implementation.

276
00:25:03,082 --> 00:25:07,794
And that's mostly to kind of discover what parts are missing.

277
00:25:07,894 --> 00:25:17,523
if we implement a chat app um as like a reference implementation, then we can quickly find
out things that are just missing from the package of the library.

278
00:25:17,523 --> 00:25:21,185
And one of those things was uh persisting message history.

279
00:25:21,185 --> 00:25:22,815
So got that put together.

280
00:25:22,815 --> 00:25:26,537
And there's a whole bunch more, a whole list of stuff that

281
00:25:26,537 --> 00:25:32,535
also needs to be polished up or added or whatnot to make the library easier to use.

282
00:25:32,550 --> 00:25:35,721
Yeah, I mean on the white noise stuff, I don't think there's anything really to mention
here.

283
00:25:35,721 --> 00:25:39,883
Like we're still blasting through all of the audit changes.

284
00:25:39,883 --> 00:25:42,284
we've MDK has been fully updated.

285
00:25:42,284 --> 00:25:48,447
sort of one layer, you know, one layer further up the stack now, um working through all
those breaking changes in white noise RS.

286
00:25:48,447 --> 00:25:52,888
um And at the same time, we're rebuilding the front end completely in a new repo.

287
00:25:52,888 --> 00:26:02,142
So um I would say in a couple of weeks here, we're going to have, you know, the next
release of white noise will look completely different and basically be, you know,

288
00:26:02,245 --> 00:26:03,969
quite different under the hood as well.

289
00:26:03,969 --> 00:26:08,878
So it should be a massive step up in terms of performance and security and all the rest.

290
00:26:09,290 --> 00:26:13,732
We have Amethyst with continuous work on their desktop client.

291
00:26:13,813 --> 00:26:17,616
Phase 2A pull request has been shipped and merged.

292
00:26:17,616 --> 00:26:25,261
It's not yet released, but it now includes search and bookmarks, saps, thread views, long
form content.

293
00:26:25,502 --> 00:26:29,026
And all of this in a nice desktop experience.

294
00:26:29,127 --> 00:26:32,632
I'm going to be really interested to see when that comes out.

295
00:26:34,042 --> 00:26:37,869
What are your thoughts on getting a mobile app ported to desktop?

296
00:26:37,869 --> 00:26:38,951
Sounds like a lot of work.

297
00:26:38,951 --> 00:26:44,553
I've never used Amazlist too much on Android, besides logging in occasionally to check out
some new features.

298
00:26:44,553 --> 00:26:48,941
So this will be interesting to see how it works on desktop.

299
00:26:50,041 --> 00:26:53,426
Yeah, I've never seen, I mean, I've seen apps go the other direction.

300
00:26:53,426 --> 00:27:04,129
Somebody build something as a web app or as a desktop app and then packages it for native,
but I don't think I've, yeah, it's a strange direction to go from native to desktop.

301
00:27:04,129 --> 00:27:08,264
I'm going to be very interested to see how the UI looks and how it feels.

302
00:27:08,809 --> 00:27:13,104
I've never used a native client in desktop.

303
00:27:13,104 --> 00:27:15,095
So that will be interesting to use.

304
00:27:15,517 --> 00:27:16,918
I use Amethyst a lot.

305
00:27:16,918 --> 00:27:20,522
Amethyst is one of my favorite master apps.

306
00:27:21,123 --> 00:27:23,176
So I'm really excited for it.

307
00:27:23,176 --> 00:27:33,753
To keep on track with desktop apps, also NoteDeck in its desktop version is making some
progress with minor UI changes to the toolbar.

308
00:27:33,994 --> 00:27:50,126
But what's really interesting is the addition of NIP-52, which is the calendar uh app for
monthly, weekly, or daily views for calendars that can be public with a Reserve Me a Spot

309
00:27:50,126 --> 00:27:50,817
support.

310
00:27:50,817 --> 00:27:54,119
And comments underneath these public calendars.

311
00:27:54,259 --> 00:28:01,563
So really good to see that more other stuff features are making it to the regular clients.

312
00:28:01,623 --> 00:28:05,066
As any of you played with NIP52 calendar events yet.

313
00:28:05,066 --> 00:28:07,708
Yeah, we have a calendar.formster.app.

314
00:28:07,824 --> 00:28:16,383
has a public calendar, but it's focused more towards private calendar use cases, oh like a
Google calendar.

315
00:28:17,021 --> 00:28:20,214
I think Coracle has a calendar as well.

316
00:28:20,346 --> 00:28:26,416
So does that feature exist yet for someone else to book an appointment in a calendar?

317
00:28:26,416 --> 00:28:27,776
Not yet.

318
00:28:27,776 --> 00:28:29,256
I'm working on it.

319
00:28:29,256 --> 00:28:31,087
It's definitely on the roadmap.

320
00:28:31,087 --> 00:28:34,498
The booking feature is not there yet, but it's definitely on the roadmap.

321
00:28:34,498 --> 00:28:38,908
But you're focusing on notifications right now so that it's much more useful.

322
00:28:39,241 --> 00:28:40,762
That would be exciting.

323
00:28:42,003 --> 00:28:56,434
Jumble has a new community mode and a way to now white label the client and deploy it on a
custom instance with a custom domain and custom theme.

324
00:28:56,501 --> 00:29:04,160
So this might make it better for communities wanting to have a bit of their own unique uh
visual experience.

325
00:29:04,681 --> 00:29:08,464
What I'm curious, is this compatible with Coracle?

326
00:29:08,595 --> 00:29:09,752
or flotilla.

327
00:29:10,046 --> 00:29:11,123
I honestly don't know.

328
00:29:11,123 --> 00:29:12,536
I haven't looked at this one yet.

329
00:29:12,536 --> 00:29:13,827
That would be good.

330
00:29:13,827 --> 00:29:17,527
We also have a Shopster with a new orders dashboard.

331
00:29:17,527 --> 00:29:22,478
In the past, the direct messaging was mainly used to manage orders.

332
00:29:22,538 --> 00:29:24,718
And this is a bit of a pain.

333
00:29:24,718 --> 00:29:36,689
So now there are dedicated user interfaces for a shop to see all of their existing items
and existing orders and handle them directly there.

334
00:29:36,689 --> 00:29:38,140
What's up with that feature?

335
00:29:38,140 --> 00:29:48,380
Yeah, so we basically streamlined a lot of the interface so people aren't any longer
burying themselves through messages and everything.

336
00:29:48,380 --> 00:29:55,836
with the new marketplace spec that we have been working on, it adds a lot of the
information, the relevant information, tags and everything.

337
00:29:55,836 --> 00:30:00,616
So it makes for a lot better structured visual representation.

338
00:30:00,616 --> 00:30:04,832
So now we have a standardized order dashboard similar to how you have

339
00:30:04,832 --> 00:30:07,183
our online e-commerce shops and stuff.

340
00:30:07,183 --> 00:30:15,485
So now you can actually manage things a little more seamlessly and more easily manage the
shipping delivery, review management.

341
00:30:15,485 --> 00:30:20,536
Because a lot of times there's like, you would get information, especially how I was
setting it up at the time.

342
00:30:20,536 --> 00:30:26,378
It wasn't like really the best UX because you'd be getting a DM from a random end pub and
you'd just be like, what in the world is happening?

343
00:30:26,378 --> 00:30:31,555
So now it kind of abstracts that away and just like reveals the information that's
actually relevant to the order.

344
00:30:31,555 --> 00:30:33,942
It actually shows exactly who it's from, everything that's happening.

345
00:30:33,942 --> 00:30:39,291
So you get everything in a more easily manageable visual field.

346
00:30:39,291 --> 00:30:42,491
And we have improved data caching.

347
00:30:42,491 --> 00:30:47,153
So this is no longer relying on some of browser APIs.

348
00:30:47,153 --> 00:30:54,801
And now we're using our server-side caching in order to actually be able to have more
reliable data persistency.

349
00:30:54,801 --> 00:30:57,476
And we're able to, if like a...

350
00:30:57,476 --> 00:31:06,667
If NOSTER events don't get published immediately, which can often happen, especially with
like the gift wrap, NIP 17DNs, you're able to, uh on the next session, republish them at a

351
00:31:06,667 --> 00:31:11,173
later time while still having everything cached and making sure that everything's still
showing up properly for you.

352
00:31:11,173 --> 00:31:15,232
So, and it still persists across actually for both ends of the party.

353
00:31:15,232 --> 00:31:19,334
So both messages, both people, the buyer and the seller, both see all the statuses and
everything.

354
00:31:19,334 --> 00:31:20,765
So they're all stayed up to date.

355
00:31:20,765 --> 00:31:24,616
So yeah, it's been just a nice improvement while we make our way to...

356
00:31:24,775 --> 00:31:30,119
kind of streamlining the rest of the process and then eventually get going into like a
mobile first approach.

357
00:31:30,119 --> 00:31:32,445
I just took a quick look at the...

358
00:31:32,445 --> 00:31:35,214
Sorry, maybe I'm bringing the conversation too far back.

359
00:31:35,214 --> 00:31:47,074
I just took a quick look at jumbles community mode, and it looks like it allows you to
white label jumble for your community by whitelisting a certain number of community relays

360
00:31:47,074 --> 00:31:49,294
or relay sets, which I think is a great idea.

361
00:31:49,294 --> 00:31:51,134
I've done that a couple of times.

362
00:31:51,134 --> 00:31:58,245
Coracle used to support it, Flotilla supports that, but it's definitely not like a deep
integration with NIP43 or anything like that yet.

363
00:31:58,245 --> 00:31:59,671
Thanks for looking that up.

364
00:31:59,671 --> 00:32:03,917
the shop story thing, you mentioned the server side caching.

365
00:32:03,959 --> 00:32:08,019
So is that on relays or on uh legacy server?

366
00:32:08,019 --> 00:32:08,930
On both, actually.

367
00:32:08,930 --> 00:32:13,399
So we have also for relays and for legacy server as well.

368
00:32:13,399 --> 00:32:14,080
OK.

369
00:32:14,080 --> 00:32:29,414
Next up, we have Formster, which adds grid questions, multiple choice, basically, as well
as a rewriting of the SDK to support for embedded operating system apps, and also some

370
00:32:29,414 --> 00:32:32,706
fixes for bunkers and local signers.

371
00:32:32,706 --> 00:32:36,439
You now have to pub key correctly in the request.

372
00:32:36,453 --> 00:32:38,114
So, yeah, great questions.

373
00:32:38,114 --> 00:32:41,560
Basically brings us to feature parity with Google Forms.

374
00:32:41,560 --> 00:32:47,936
It was a feature that was requested lot by people, so we finally added it.

375
00:32:47,936 --> 00:32:52,818
Yeah, the rewrite to SDK so that you can embed it into your websites with your own themes.

376
00:32:52,818 --> 00:32:58,754
Earlier you could do an iframe and embed, but that still had forms of themes.

377
00:32:58,754 --> 00:33:00,486
Now you can access all

378
00:33:00,486 --> 00:33:10,972
all of the things directly like the complete form element or if you just want the HTML,
just get the HTML and write your own CSS on top of it.

379
00:33:10,972 --> 00:33:16,103
And of course people can just query the relays and get the form events themselves, but
this just makes it easier.

380
00:33:16,103 --> 00:33:23,748
And yeah, there was a bunch of fixes for people with, people who were trying to self-sign
forms and couldn't with bunker.

381
00:33:23,748 --> 00:33:24,599
So now that's it.

382
00:33:24,599 --> 00:33:26,834
So what exactly are those grid questions?

383
00:33:26,834 --> 00:33:27,829
How do they look?

384
00:33:27,829 --> 00:33:31,441
ah So basically those are like matrix questions.

385
00:33:31,441 --> 00:33:44,522
So you probably would have seen it on forms where you have a customer feedback survey and
you get how satisfied are you ah among these 10 categories like let's say delivery, how

386
00:33:44,522 --> 00:33:49,664
did the staff treat you and then you have four columns unsatisfied, satisfied, very
satisfied.

387
00:33:49,664 --> 00:33:56,215
uh So you can use the same options across multiple rows.

388
00:33:56,262 --> 00:33:58,506
Those are what great questions are.

389
00:33:58,506 --> 00:34:00,187
And then there could be radio buttons.

390
00:34:00,187 --> 00:34:04,209
You can choose unsatisfied either or.

391
00:34:04,209 --> 00:34:05,617
Or it could be check boxes.

392
00:34:05,617 --> 00:34:08,131
You can choose one to be in each.

393
00:34:08,396 --> 00:34:09,857
Those are good questions.

394
00:34:09,857 --> 00:34:16,070
Mostly used for surveys, but it could also be, if you remember from school, we used to do
match the following questions.

395
00:34:16,070 --> 00:34:20,363
So yeah, it could be used for quizzes like that as well.

396
00:34:20,363 --> 00:34:24,145
Like a dog barks at pow meows and those sorts of things.

397
00:34:24,176 --> 00:34:25,748
I'm I've got a mousse.

398
00:34:25,748 --> 00:34:26,628
Cool.

399
00:34:26,628 --> 00:34:31,959
We can move on to the Nostr tools, which makes an important upgrade to the crypto
dependency.

400
00:34:31,959 --> 00:34:36,999
So the noble curves got upgraded to version 2.0.1.

401
00:34:37,219 --> 00:34:40,390
That addressed some breaking API changes.

402
00:34:40,390 --> 00:34:43,101
Yeah, and changing your crypto is always scary.

403
00:34:43,101 --> 00:34:48,312
So someone please review the library and the implementation to make sure everything is
good.

404
00:34:48,312 --> 00:34:53,195
uh It also adds the switch relay support for NIP46.

405
00:34:53,195 --> 00:35:00,279
So this is for remote bunker signers, which can now dynamically change the relay
connections on the fly.

406
00:35:00,480 --> 00:35:05,174
Last week, numerous different projects have integrated that specifically, which is good to
see.

407
00:35:05,174 --> 00:35:11,414
So I actually fell over the noble underlying dependency a couple weeks ago.

408
00:35:11,734 --> 00:35:14,293
There was a bug some...

409
00:35:14,293 --> 00:35:20,312
can't remember exactly what it was, but when I was working on pomade, something to do with
normalizing secp point.

410
00:35:20,312 --> 00:35:27,012
There was something that was just not quite correct and I had to patch it and the version
two did solve that.

411
00:35:27,012 --> 00:35:32,167
So I know there was at least one bug fixed in the 2.0 release of the noble...

412
00:35:32,167 --> 00:35:33,832
curves library.

413
00:35:33,832 --> 00:35:39,298
Unfortunately, the migration is a little bit painful because the module structure is
completely changed.

414
00:35:39,298 --> 00:35:44,354
So it's not a trivial upgrade, but it is worth doing, I think.

415
00:35:44,354 --> 00:35:45,936
And it's still by Paul Miller.

416
00:35:45,936 --> 00:35:51,417
He's been a very reliable developer of that stuff for a long time.

417
00:35:51,417 --> 00:35:53,119
Yeah, I'm glad to see this now.

418
00:35:53,119 --> 00:36:03,921
This brings the Nostra Tools library in line with, like if you end up using the Noble
Curves library yourself, then you usually end up installing version two, and then if you

419
00:36:03,921 --> 00:36:06,833
grab Nostra Tools, you end up running with version one also.

420
00:36:06,833 --> 00:36:11,740
So this is nice to not have two versions of the same library.

421
00:36:11,740 --> 00:36:12,860
Very good.

422
00:36:13,081 --> 00:36:18,666
We have Zeus, the Bitcoin wallet, adding NIP87 Mint reviews.

423
00:36:18,666 --> 00:36:33,348
So Mint reviews are Nostr events where users can give a score to different cashew or feddy
mint, ecash mints, and score them across a couple different vectors.

424
00:36:33,369 --> 00:36:40,052
And now Zeus has integrated that to allow for better discovery of high quality mints.

425
00:36:40,414 --> 00:36:43,066
with the local web of trust of that user.

426
00:36:43,066 --> 00:36:50,450
So you can filter out to only show the minutes that your friends have requested or
supported.

427
00:36:50,611 --> 00:36:59,324
And I think that is a good way of improving the UX of discoverability and trustworthiness,
thanks to Noster.

428
00:36:59,324 --> 00:37:00,785
Yeah, I'm excited to see this.

429
00:37:00,785 --> 00:37:09,786
That was one of the things I ran into when I was kind of messing around adding Cashew
support to applesauce stuff.

430
00:37:10,153 --> 00:37:18,077
There was too many Cashew mints out there to test with, and so I needed a few just to
quickly test and see what my friends were using and whatnot.

431
00:37:18,396 --> 00:37:27,870
I hope they're following the NIP because currently all the NIP, all the NIP review events
that are published right now don't follow the NIP at all.

432
00:37:28,058 --> 00:37:36,369
Somehow they're, I don't know, they would be the first one to publish a correct uh NIP
compliant event if they actually follow the NIP.

433
00:37:36,440 --> 00:37:37,840
Let's hope that they do.

434
00:37:37,923 --> 00:37:50,977
What's also included in this release is that USD End User can create these ratings in the
app directly, either anonymously, just signed by a random private key, or with your actual

435
00:37:50,977 --> 00:37:52,467
user's NSIC.

436
00:37:52,532 --> 00:37:59,686
Both might be useful, but especially with your own pubkey, this is a good web of trust
signal.

437
00:37:59,708 --> 00:38:03,109
But of course, be aware that this is public and

438
00:38:03,109 --> 00:38:05,289
others would know that you are using this mint.

439
00:38:05,413 --> 00:38:09,527
We had a lot of ongoing work in Kamelos this week.

440
00:38:09,527 --> 00:38:14,832
Kamelos is a Flutter-based Android client built on the Dart NDK.

441
00:38:14,833 --> 00:38:20,458
And its main focus is on battery efficiency and mobile performance.

442
00:38:20,558 --> 00:38:29,767
So if you want to try out a new client with this focus, then check out Kamelos on GitHub
and get the release there.

443
00:38:29,987 --> 00:38:41,383
Here specifically, they were working on different type of chat categories and message
dates and optimistic send user interface so that you show to the user the message has been

444
00:38:41,383 --> 00:38:43,294
sent before it is actually sent.

445
00:38:43,294 --> 00:38:51,238
So there's no ambiguity or missing dropping off events as well as a note to self
functionality.

446
00:38:51,419 --> 00:38:57,522
So a lot of direct messaging support in these couple pull requests.

447
00:38:57,522 --> 00:38:59,671
Let's see when it will be released.

448
00:38:59,671 --> 00:39:00,562
This looks interesting.

449
00:39:00,562 --> 00:39:02,734
have not seen this app at all.

450
00:39:02,734 --> 00:39:08,113
So this looks like another Nostra client I'll have to go take for a test drive.

451
00:39:08,292 --> 00:39:09,083
Yes, indeed.

452
00:39:09,083 --> 00:39:12,756
Another client you will soon be able to take on the test drive is Divine.

453
00:39:12,756 --> 00:39:25,315
They are working hard on finalizing the next release and currently working on uh NIP46
remote signer via a QR code authentication.

454
00:39:25,496 --> 00:39:37,435
This is supported by most of the signers so that you can scan from your phone a QR code
that is shown on the laptop and then connect these two devices to each other.

455
00:39:37,811 --> 00:39:41,863
There's also NIP17 gift wrapped direct messages.

456
00:39:41,984 --> 00:39:49,069
So far, a good privacy preserving DM scheme with sender level privacy.

457
00:39:49,269 --> 00:40:02,558
And it also made work on mentions support so that you can tag other people with the proper
Noster semicolon URI and the add sign to get clickable profile links.

458
00:40:02,999 --> 00:40:05,235
And yeah, numerous new.

459
00:40:05,235 --> 00:40:11,139
tools for video editing themselves, like adding filters or stickers or drawings.

460
00:40:11,399 --> 00:40:15,042
So there is going to be a direct video editor in that client.

461
00:40:15,042 --> 00:40:17,064
And I'm sure that's no easy task.

462
00:40:17,064 --> 00:40:18,915
This is shaping up to be a...

463
00:40:18,915 --> 00:40:28,138
it looks like they're adding just all the nice quality of life features that you'd expect
from an Oster client and generally a social media app.

464
00:40:28,138 --> 00:40:29,289
So that's really nice to see.

465
00:40:29,289 --> 00:40:31,970
I'm going to be interested to see how they...

466
00:40:31,970 --> 00:40:44,799
personally I'm going be interested to see how they're going to implement the remote signer
and the NIP-17 messages because those are notoriously hard to decrypt using a remote

467
00:40:44,799 --> 00:40:45,169
signer.

468
00:40:45,169 --> 00:40:46,181
uh

469
00:40:46,181 --> 00:40:49,241
We can move on to the NIP updates section.

470
00:40:49,281 --> 00:40:53,301
There are a couple open PRs for discussion.

471
00:40:53,421 --> 00:40:56,921
What we already covered last week is the trusted relay assertions.

472
00:40:56,921 --> 00:41:09,121
And here conversation continues with the main question being if it is more useful if these
scores are computed on a global level, so you could compute it once and that is the rank

473
00:41:09,121 --> 00:41:15,809
for all users, or if it should be more personalized so that these ranks are stored.

474
00:41:15,809 --> 00:41:21,233
or computed with a specific pubkey as the root observer.

475
00:41:21,594 --> 00:41:29,610
And these are, of course, more expensive to run, and we would have to run them for
everyone who wants them.

476
00:41:29,610 --> 00:41:41,279
alternative approaches like these page rank algorithms that NosterBands, Trust's rank, or
GrapeRank, or npop.world is applying is quite good against Sibyl attacks.

477
00:41:41,279 --> 00:41:43,092
uh

478
00:41:43,092 --> 00:41:49,513
So we would have to see how we can get civil attack resistance implemented in the trusted
relay assertions as well.

479
00:41:49,513 --> 00:42:01,140
Yeah, again, is, uh unfortunately, I haven't had the time to really participate in this
conversation or really read up on this yet, but this one, I did skim over it briefly and

480
00:42:01,140 --> 00:42:17,229
this one uh excites me a lot if I remember it correctly because it, I should look at it
quickly before I talk about it, but it seems like a really simple way of exposing.

481
00:42:17,229 --> 00:42:18,000
uh

482
00:42:18,000 --> 00:42:20,146
That's a long way up.

483
00:42:20,146 --> 00:42:28,444
Okay, well, looks like, if I remember correctly, it looks like a kind of an open
pre-computed or, you know, calculated on the fly.

484
00:42:28,444 --> 00:42:29,905
um

485
00:42:30,379 --> 00:42:33,113
API similar to Primal's caching server.

486
00:42:33,113 --> 00:42:47,320
So if it's that or if it's something like that, then this will be very useful for uh web
apps to just kind of offload questions like how many zaps have this post gotten uh instead

487
00:42:47,320 --> 00:42:49,332
of having to calculate it themselves.

488
00:42:50,004 --> 00:42:50,875
Yes, indeed.

489
00:42:50,875 --> 00:42:56,415
We also have an ongoing conversation on the topic of community keys.

490
00:42:56,635 --> 00:43:06,155
So this is a proposal for managing groups, but not based on a relay like NIP29, but
instead by any public key.

491
00:43:06,495 --> 00:43:16,774
So any public key can publish a kind 10,222 event, which then creates a community that can
be done.

492
00:43:16,774 --> 00:43:21,114
further administrated by that NPUB himself.

493
00:43:21,574 --> 00:43:31,561
So this uses the NIP58 badges for access control and can delegate membership management
with cold storage or community keys.

494
00:43:31,561 --> 00:43:35,892
I'm really curious, Holbert, if you looked into this and how it compares to NIP29.

495
00:43:35,892 --> 00:43:47,075
Yeah, it's been a while since I looked into it, although last week it occurred to me that
one of the long-standing problems that I've had with CommuniKey is potentially solved

496
00:43:47,075 --> 00:43:48,055
using MultiSig.

497
00:43:48,055 --> 00:43:50,936
So, you know, a CommuniKey has a key, right?

498
00:43:50,936 --> 00:43:52,297
A key is...

499
00:43:52,657 --> 00:43:55,268
It uh cannot be un-unknown.

500
00:43:55,268 --> 00:44:02,681
So the person who generates the key has permanent, irrevocable admin authority over the
entire group, which is kind of like...

501
00:44:02,681 --> 00:44:05,002
It's something that we were trying to get away from.

502
00:44:05,086 --> 00:44:09,630
uh like with how Mastodon works with home servers.

503
00:44:09,630 --> 00:44:21,193
uh Obviously, CommuniKey don't own your identity, but they do fully own the group, which
in some ways is okay, but it makes it impossible to transfer group ownership from one

504
00:44:21,193 --> 00:44:21,904
admin to another.

505
00:44:21,904 --> 00:44:26,340
You have to share that key, and it's been shared with the previous admin.

506
00:44:26,340 --> 00:44:32,572
But what you could do is potentially use uh a DKG distributed key generation to...

507
00:44:32,634 --> 00:44:41,252
create a key for the community that isn't known by uh any individual uh person.

508
00:44:41,252 --> 00:44:50,863
um The downside is you'd have to have a quorum when you start your community, which often
isn't the case, but it would allow you to rotate admins in and out of that quorum.

509
00:44:50,869 --> 00:44:58,125
Anyway, that was just my main objection to communiquees, and with that, it's potentially
solved.

510
00:44:58,443 --> 00:45:10,673
I still think there are problems with um enforcement of permissions and aligning
permissions between um the NOSTER event structure, which is uh interpreted by clients and

511
00:45:10,673 --> 00:45:12,234
actual relay implementations.

512
00:45:12,234 --> 00:45:21,057
So, you know, this might work well for public communities, but would not work as well for
private communities or access controlled communities.

513
00:45:21,391 --> 00:45:29,775
I believe that there's a way to use relay policies to support the community policies, but
it's a little bit of a decoupled relationship.

514
00:45:29,775 --> 00:45:38,079
So I'm still skeptical about the approach, but it's great that ah he's been continuing to
experiment on this.

515
00:45:38,090 --> 00:45:40,970
Yeah, I looked into this a little too myself.

516
00:45:40,970 --> 00:45:47,161
I honestly didn't think about the multi-sig or the distributed key generation, as you
mentioned.

517
00:45:47,161 --> 00:45:56,092
That's actually, like I said, it doesn't solve the enforcement problem because the data
has to be lived somewhere and then there's a moderation and all that.

518
00:45:56,492 --> 00:46:01,829
having kind of a multi-sig for a community key...

519
00:46:01,829 --> 00:46:04,989
It opens up some really interesting possibilities.

520
00:46:05,269 --> 00:46:12,320
I believe it's a lot like what governance and some other stuff that people have been
talking about on the non-Bitcoin side of things.

521
00:46:12,320 --> 00:46:15,771
It's a field I've never not explored, but it sounds very interesting.

522
00:46:15,771 --> 00:46:21,831
Yeah, and I think I've looked in this proposal a little bit too, and I think it's pretty
compatible.

523
00:46:22,091 --> 00:46:25,982
At least it reuses a lot of the same primitives that NIP29 does.

524
00:46:25,982 --> 00:46:31,426
It's nice to see that at least for the implementation, for most of the implementation
details are the same.

525
00:46:31,426 --> 00:46:36,955
So we won't have to, depending on which proposal the client wants to support, you won't
have to rewrite too much.

526
00:46:36,955 --> 00:46:46,067
Next up, we have a additional pull request to the Nibs repo introducing NibCF, which
stands for Changes Feed.

527
00:46:46,368 --> 00:46:55,670
And this is a proposal that each relay keeps an increasing number of order of when the
event came in.

528
00:46:55,670 --> 00:47:02,902
And then instead of clients querying with a timestamp, which could have duplicates, right?

529
00:47:02,902 --> 00:47:06,683
One event can have the exact same timestamp as another.

530
00:47:06,799 --> 00:47:09,542
or the client and relay clocks might drift apart.

531
00:47:09,542 --> 00:47:16,406
And this would be solved here by each relay simply keeping track of the number of events.

532
00:47:16,506 --> 00:47:21,100
And then clients can query all the events since a given index number.

533
00:47:21,100 --> 00:47:28,985
Notably here, each relay would have its own unique index number for these events,
depending on how many other events are in there.

534
00:47:29,265 --> 00:47:40,998
So these index numbers would not be part of the actual NOS2 event, but an additional flag
in the relay database that might speed up or make more reliable the query of a range of

535
00:47:40,998 --> 00:47:41,689
events.

536
00:47:41,689 --> 00:47:42,971
What do you guys think about this?

537
00:47:42,971 --> 00:47:50,260
Well, I hate to dish on uh someone in public, but I think this is better solved by a naked
Tropy.

538
00:47:50,260 --> 00:48:06,182
So, like, I do think that this is a more precise way of synchronizing, but uh between
time-based windowing and naked Tropy, it's pretty easy to get a complete data set and

539
00:48:06,182 --> 00:48:07,873
account for clock skew.

540
00:48:07,873 --> 00:48:12,796
It's a little bit more computationally intensive, but they're much more general purpose
tools.

541
00:48:12,853 --> 00:48:23,719
So, let's say that you have an event that either due to clock skew or being propagated to
a relay comes in 10 minutes after the timestamp on it.

542
00:48:23,719 --> 00:48:30,055
If you have an open subscription, you're going to miss that event if you're doing time
windowing after that cutoff point.

543
00:48:30,055 --> 00:48:32,522
But if you really want uh an exhaustive...

544
00:48:32,522 --> 00:48:33,353
um

545
00:48:33,353 --> 00:48:37,874
data set, is like, I guess the whole thing is like, know, no stir.

546
00:48:37,874 --> 00:48:39,235
There is no global.

547
00:48:39,235 --> 00:48:42,066
You're always, you're always going to be missing something.

548
00:48:42,066 --> 00:48:50,848
But if you really want to have an exhaustive data set, can periodically run a neg entropy
sync over the last, you know, maybe hours or something like that in order to account for

549
00:48:50,848 --> 00:48:51,668
those stragglers.

550
00:48:51,668 --> 00:48:55,479
And I don't think it'd be too, uh too computationally expensive.

551
00:48:55,479 --> 00:49:01,236
But and my main objection is not like the concept so much as I don't think

552
00:49:01,356 --> 00:49:10,017
With all the effort, all the time that it's taken for Negan Trophy to get adopted, and
it's a much more powerful general purpose tool, I don't really see this particular

553
00:49:10,017 --> 00:49:15,406
protocol being so similar getting a lot of adoption over time.

554
00:49:15,406 --> 00:49:19,428
So that's my own personal private opinion.

555
00:49:19,443 --> 00:49:21,453
I haven't done much reading up on this.

556
00:49:21,460 --> 00:49:27,822
So I will go look into this because I've implemented the negentropy protocol and I do
agree with that.

557
00:49:27,822 --> 00:49:31,973
is very efficient and a very useful tool, but I have not looked into this at all.

558
00:49:31,973 --> 00:49:33,674
So I guess I should go do my homework.

559
00:49:33,674 --> 00:49:43,156
But I did want to say that the concept that at least paginated loading of Nostra events is
difficult is...

560
00:49:43,359 --> 00:49:53,758
I think a pretty common misconception because what usually ends up happening with clients
and client devs is you implement kind of time-based pagination where you get the events

561
00:49:53,758 --> 00:49:58,977
for the last day and the last week and the last month and it always ends up a pretty big
mess.

562
00:49:59,018 --> 00:50:05,793
But then for some reason, I rarely ever see it in the discussion, but no one talks about
the field in the filter.

563
00:50:06,001 --> 00:50:16,500
If you combined until and limit you can basically paginate backwards with the filters
without ever missing an event because it's I don't know if this I need to go look up on

564
00:50:16,500 --> 00:50:22,241
this nip, but it seems to try to be solving two things at the same time, which is
confusing to me

565
00:50:22,241 --> 00:50:32,416
Yeah, Limit is a powerful uh tool, I think a big part of the reason people don't rely on
it very much is because in the early days, relays would not return uh events sorted uh

566
00:50:32,416 --> 00:50:33,333
correctly.

567
00:50:33,333 --> 00:50:36,120
They would often return them sorted ascending.

568
00:50:36,120 --> 00:50:42,445
And so if you didn't put a timestamp window on there, you would get the oldest events
first.

569
00:50:42,445 --> 00:50:49,379
ah so Limit for pagination was not really workable, but it works much better nowadays.

570
00:50:49,379 --> 00:50:50,850
It's good to see some progress.

571
00:50:50,850 --> 00:50:58,910
And the final NIP change that we have is a proposal for encrypted file synchronization
across devices.

572
00:50:59,010 --> 00:51:16,420
So this defines some kind numbers, 30,800, 801, 802, for synchronized encryption of
content, both for texts, and it is just in regular NOS2 events, as well as for Blossom.

573
00:51:16,420 --> 00:51:18,541
in with binary attachments.

574
00:51:18,822 --> 00:51:30,230
And these are all NIP-44 self-encrypted so that only he who knows the private key can
decrypt these events or messages or files.

575
00:51:30,391 --> 00:51:36,696
And so the idea was simply to move data between two laptops or a laptop and a phone.

576
00:51:36,736 --> 00:51:41,474
And you can do that as long as you have the private key to that.

577
00:51:41,474 --> 00:51:44,192
So here it also inks

578
00:51:44,192 --> 00:51:55,065
introduces a vault index Nostra event kind, which basically tells you where these files
are stored, which will help you in the lookup for them.

579
00:51:55,065 --> 00:51:57,988
What are your thoughts on this type of encrypted file?

580
00:51:57,988 --> 00:51:58,674
Sync.

581
00:51:58,674 --> 00:52:10,534
something very strange is that I was not aware that this existed and just yesterday I was
working on something like a drive setup, like a Google Drive setup, but basically on Bosom

582
00:52:10,534 --> 00:52:25,794
servers on Nostrava you could store encrypted files and this was the exact structure I had
come up with with NIP44 self encrypted files as Bosom binaries with an encrypted kind for

583
00:52:25,794 --> 00:52:26,885
folder management.

584
00:52:26,885 --> 00:52:34,116
It was nowhere near completion and I'm glad somebody has already done it so I can probably
use it.

585
00:52:34,116 --> 00:52:37,909
It's always good when someone else solves your problem faster than you can.

586
00:52:37,909 --> 00:52:38,600
Yep.

587
00:52:38,600 --> 00:52:41,162
And that brings us to our final section.

588
00:52:41,162 --> 00:52:50,446
Since this is the end of January, let's take a trip down memory lane and look at every
January that happened since the existence of Noster.

589
00:52:50,607 --> 00:52:52,808
So Noster was invented November 2020.

590
00:52:52,808 --> 00:52:57,130
And so the first January we'll look at is January 2021.

591
00:52:57,130 --> 00:53:03,194
This was only three months after Noster was first announced.

592
00:53:03,194 --> 00:53:07,048
And there was only a small group of

593
00:53:07,048 --> 00:53:11,402
early adopters and mainly discussions were happening in the Telegram group.

594
00:53:11,402 --> 00:53:19,788
And yeah, there was one main client uh back then, which was Brannel, the web client that
Fiat Jeff started working on.

595
00:53:21,190 --> 00:53:31,438
Also in this month was the release of NoCSL, which is a command line terminal based
interface for working with Noster.

596
00:53:31,438 --> 00:53:34,120
So to some extent, precursor of Nuck.

597
00:53:34,601 --> 00:53:35,181
But yeah.

598
00:53:35,181 --> 00:53:42,073
There was not much happening back then, but the basic building blocks of Noster are still
the same.

599
00:53:42,113 --> 00:53:50,655
Schnorr signatures, JSON for events, relays as dumb storage, kind numbers to identify the
type of events.

600
00:53:50,935 --> 00:53:52,465
And that was basically it.

601
00:53:52,465 --> 00:53:54,316
It was super simple back then.

602
00:53:54,316 --> 00:54:02,697
It is still super simple now, just with a bit more complexity with all the different nibs
that are by now available.

603
00:54:03,038 --> 00:54:04,288
What do you guys remember?

604
00:54:04,288 --> 00:54:05,485
January 21.

605
00:54:05,485 --> 00:54:07,513
No, that was well before my time.

606
00:54:07,513 --> 00:54:08,284
Steam.

607
00:54:09,706 --> 00:54:13,568
Well, then we have the next year, one year later, January 2022.

608
00:54:13,568 --> 00:54:26,535
So just on New Year's Eve, December 31st, there was this post about Hacker News, or on
Hacker News about Noster, which reached the top page.

609
00:54:26,636 --> 00:54:33,840
And that was covered in last edition of this yearly recap of December's.

610
00:54:34,100 --> 00:54:37,022
However, now we can talk a bit more about the actual...

611
00:54:37,352 --> 00:54:48,478
mayhem and chaos that launched because a lot of people got all of a sudden interested in
Noster and started to give their opinion, including for example, Uncle Bob, Robert C.

612
00:54:48,478 --> 00:54:54,391
Martin, quite an OG tech educator and programmer.

613
00:54:54,432 --> 00:55:06,133
And so he thought that this might actually have a chance of working and was a bit worried
about the potential for spam, but could see that we...

614
00:55:06,133 --> 00:55:08,705
find numerous different solutions for this.

615
00:55:08,865 --> 00:55:14,589
But yeah, he was bullish and he wrote in, quote, the end game solution for social
communication.

616
00:55:15,150 --> 00:55:19,093
back then a massive Nostre bull and he's still around today.

617
00:55:19,194 --> 00:55:22,195
Occasionally writing some code for this.

618
00:55:23,057 --> 00:55:28,821
These early discussions were mainly about the trade-offs of the Nostre system.

619
00:55:28,821 --> 00:55:34,225
Like some were not happy that this is a centralized system and not a purely peer-to-peer.

620
00:55:35,590 --> 00:55:46,533
model, which comes with some downsides in terms of censorship resistance, but it does come
up with great simplicity for actually implementing a code and a client.

621
00:55:46,533 --> 00:55:49,434
And that's what we started to see here.

622
00:55:49,534 --> 00:55:52,835
For example, Uncle Bob wrote the Moore Speech client.

623
00:55:52,835 --> 00:55:54,035
I think that's still around.

624
00:55:54,035 --> 00:55:59,337
uh And Fiat Jeff started the Go Nostre library as well.

625
00:55:59,697 --> 00:56:03,998
The null CSL command line tool was still around.

626
00:56:04,132 --> 00:56:10,906
And then Nostr Tools uh started to offer JavaScript support for the library.

627
00:56:11,026 --> 00:56:16,869
And Nostr Tools, already mentioned earlier in this newsletter, is still happily in
development.

628
00:56:17,610 --> 00:56:22,112
So yeah, this was one year after Nostr's creation, a bit more.

629
00:56:22,113 --> 00:56:31,019
And we are slowly starting to get recognition by other freaks online, as well as more
clients coming online for use.

630
00:56:31,019 --> 00:56:33,419
Yeah, this was the the month that I joined.

631
00:56:33,419 --> 00:56:37,230
I think my first Nostra post was January 3rd, 2022.

632
00:56:37,230 --> 00:56:49,601
And, you know, at the time, I was working on my own protocol based on Scuttlebutt with
some of the same ideas, specifically getting rid of the kind of linked list data structure

633
00:56:49,601 --> 00:56:55,355
that Scuttlebutt has, which was a huge limitation in in propagating.

634
00:56:55,355 --> 00:57:01,189
individual pieces of data across the network rather than the entire history of a person's
profile.

635
00:57:01,189 --> 00:57:10,495
And I found Noster and I sent Fiat Jaff a DM through Branley to tell him why I thought his
protocol wasn't going to work.

636
00:57:11,716 --> 00:57:17,340
And of course, the DM didn't get delivered because Branley was a giant mess.

637
00:57:17,340 --> 00:57:25,465
So I opened a pull request to Branley around that time so that I could send Fiat Jaff
messages telling him why he was wrong.

638
00:57:25,609 --> 00:57:37,481
And later in that year, in November, I finally gave up and jumped full into no-strew
development instead of building a protocol by yourself, which turns out is very hard.

639
00:57:37,481 --> 00:57:41,116
uh So we have to give Fiat Jaffa a lot of credit for doing that.

640
00:57:41,116 --> 00:57:44,347
Yeah, building social stuff alone is tough.

641
00:57:44,347 --> 00:57:47,067
getting feedback from others is important.

642
00:57:47,187 --> 00:57:56,407
And we did keep on getting that all the way through to January 2023, which for some extent
was a bit of a breakout year for Noster.

643
00:57:56,667 --> 00:58:06,906
And first was the sensor dragon, specifically, Damos got rejected from the Apple App
Store.

644
00:58:06,906 --> 00:58:15,651
for its first application on January 1st, and then rejected again on January 22nd, for
some unknown reasons, of course.

645
00:58:15,651 --> 00:58:30,118
But finally, uh we slew the censorship app publishing dragon on January 31st, which made
Damos jump up to the 10th most downloaded app in the US social networking area.

646
00:58:30,219 --> 00:58:35,051
And yeah, Jack Dorsey was happy with that as well, as well as Edward Snowden.

647
00:58:35,051 --> 00:58:38,666
he announced his presence on Noster January 23rd.

648
00:58:40,129 --> 00:58:44,686
Being quite happy that he was not limited to 280 characters anymore.

649
00:58:44,686 --> 00:58:50,281
So instantly people started zapping him some stats, which was already implemented back
then.

650
00:58:50,281 --> 00:58:54,584
We also saw the proliferation of more browser-based clients.

651
00:58:54,905 --> 00:59:03,452
We have Snort, which was created just end of December, 2022, having a lot of nice
improvements in January.

652
00:59:03,452 --> 00:59:07,755
For example, it introduced the NIPv5 domain verifying.

653
00:59:07,916 --> 00:59:16,874
And you were able to buy yourself a Nostrclebs domain uh NIPv5 for an easy human-readable
identifier.

654
00:59:16,874 --> 00:59:18,625
Also, Iris developed

655
00:59:18,625 --> 00:59:29,844
by Marty Malmy, then made good progress and also introduced the SNIP-5 identifiers, back
when domains were still the latest addition to Noster.

656
00:59:30,004 --> 00:59:36,369
And we've had Astral, which is another web client, a fork of Brandle.

657
00:59:36,470 --> 00:59:43,246
And that was mainly focusing on relay grouping features, so a bit more management of your
relays.

658
00:59:43,246 --> 00:59:47,300
And we've also had the initial uh

659
00:59:47,300 --> 00:59:49,863
Yeah, releases of Amethyst as well.

660
00:59:49,883 --> 00:59:59,926
wait, I don't think Amethyst was released in January, but they were definitely active and
doing more uh work on that app already.

661
00:59:59,926 --> 01:00:02,376
So any fond memories of January 23?

662
01:00:02,376 --> 01:00:05,569
The vibes were high, I will say that.

663
01:00:05,569 --> 01:00:19,576
I think this is where I got started, uh at least a few months before January, because this
is what I remember DOSTER being when I finally dove in and didn't just read the spec but

664
01:00:19,576 --> 01:00:22,217
actually started working on stuff.

665
01:00:22,838 --> 01:00:33,404
It was mostly because the original Astral Client that I started hacking on things and
trying to fix bugs and just actually diving in and figuring out how the protocol worked.

666
01:00:33,735 --> 01:00:36,947
And I think it's quite interesting to see that already back then.

667
01:00:36,947 --> 01:00:39,349
We had troubles with the app stores.

668
01:00:39,489 --> 01:00:42,572
And that continues to still be a problem nowadays.

669
01:00:42,572 --> 01:00:45,924
Not so much anymore, but it still happens.

670
01:00:45,924 --> 01:00:48,665
that was maybe a good thing.

671
01:00:48,665 --> 01:00:56,521
A little bit to a strisand effect of the things that they don't want you to download is
usually the things that you're going to end up downloading.

672
01:00:56,862 --> 01:01:01,086
That probably helped Noster get put on the map.

673
01:01:01,086 --> 01:01:10,717
Then one year later, January, 2024 is really where a lot of good improvements and new
features were added to this protocol.

674
01:01:10,717 --> 01:01:19,957
We've, we've had more, you know, physical events like Noster Phoenix had their meetup then
in January 5th.

675
01:01:19,957 --> 01:01:24,077
And we made changes to the protocol, like for example, introducing NIP 59.

676
01:01:24,137 --> 01:01:29,557
So those are the gift wraps that are now used for the current iteration of private.

677
01:01:29,756 --> 01:01:31,137
direct messaging.

678
01:01:31,137 --> 01:01:39,603
So this build on top of the earlier work of NIP44, which improved the encryption scheme
with a proper security audit.

679
01:01:39,723 --> 01:01:46,808
And now NIP59 defined on how can we send someone a message without relays knowing who the
sender of the message was.

680
01:01:46,808 --> 01:01:50,170
The receiver of the message is still easily identifiable.

681
01:01:50,170 --> 01:01:56,394
That's for easy synchronization mainly, that the receiver quickly learns that he has a new
message.

682
01:01:56,575 --> 01:01:58,470
But the sender's identity

683
01:01:58,470 --> 01:02:02,481
is hidden to the outside and only visible to the receiver.

684
01:02:03,108 --> 01:02:06,769
Disposable private keys are used for that outer layer.

685
01:02:07,049 --> 01:02:13,051
We've also had the first or guess second iteration of marketplaces being shipped.

686
01:02:13,051 --> 01:02:18,572
So that was back then in NIP-15, which is now made obsolete by NIP-99.

687
01:02:18,572 --> 01:02:23,814
But we've already had two familiar players there, the Plebian Market as well as Shopster.

688
01:02:24,107 --> 01:02:27,879
Clients focused on the marketplace and they're still going strong.

689
01:02:27,879 --> 01:02:34,243
Now with another two or three iterations of further protocol enhancements for the
marketplace.

690
01:02:34,444 --> 01:02:37,165
We've also seen the release of ZapStream.

691
01:02:37,165 --> 01:02:46,102
So this is here where you can make live streams uh through Noster with getting lightning
payments uh per minute if desired.

692
01:02:46,102 --> 01:02:47,983
We've also had more

693
01:02:48,716 --> 01:02:58,913
Developer tooling improvements like NDK made major TypeScript abstract abstractions and
Rust Noster started offering bindings as well.

694
01:02:59,173 --> 01:03:05,906
And Zeus shipped their first Noster feature, which was the Noster Contact import.

695
01:03:05,906 --> 01:03:13,733
So this means that you could log in with your end pub and see the lightning addresses of
all your friends and send them a sap.

696
01:03:13,733 --> 01:03:18,176
So this was before any Noster Wallet Connect was natively integrated.

697
01:03:18,262 --> 01:03:21,698
This was still when we were copy pasting invoices left and right.

698
01:03:21,698 --> 01:03:23,660
So yeah, yet another good year.

699
01:03:23,660 --> 01:03:30,470
uh A lot of infrastructure improvements and especially a lot of new apps coming live that
we still know and love today.

700
01:03:30,509 --> 01:03:35,793
what I also found interesting that month is that we had early academic research papers.

701
01:03:35,802 --> 01:03:41,821
So there was one research paper published specifically about the sustainability of Noster.

702
01:03:41,821 --> 01:03:52,164
And they found that most relays are definitely not profitable, if not all, with some
relays having a charged

703
01:03:53,478 --> 01:03:55,796
here, but usually not even enough to pay the bills.

704
01:03:55,796 --> 01:04:02,442
So this was mainly run by hobbyists and therefore also there was significant downtime for
all of these relays.

705
01:04:02,442 --> 01:04:06,135
Roughly 20 % of the relays had significant downtime.

706
01:04:06,135 --> 01:04:15,308
The cool thing is users didn't really notice that much because we just duplicate across
many different relays and not all of them have to be online at the same time.

707
01:04:15,569 --> 01:04:18,057
And we've also had the first scam.

708
01:04:18,057 --> 01:04:24,524
basically there was the Nostra Asset Protocol token which was launched I think on Ethereum
or something.

709
01:04:24,524 --> 01:04:34,739
It was of course a scam and of course it was rock-polled but I think that might have been
like the only affinity scam shitcoin that was launched or at least the only one that I

710
01:04:34,739 --> 01:04:35,370
remember.

711
01:04:35,370 --> 01:04:36,764
Yeah, that's the only one I remember too.

712
01:04:36,764 --> 01:04:41,697
But yeah, the scammer made a decent bit of change off of us.

713
01:04:41,697 --> 01:04:42,881
So good for him.

714
01:04:42,881 --> 01:04:45,862
Yeah, hopefully he donated that to OpenSense.

715
01:04:45,862 --> 01:04:49,622
Yeah, then next up we have January 2025.

716
01:04:49,625 --> 01:04:59,752
Here we've had the introduction of Froster, which is the Frost threshold signature scheme
for signing and encrypting things.

717
01:04:59,752 --> 01:05:02,784
That is what HODL.bot now integrated in pomade.

718
01:05:02,784 --> 01:05:04,615
So that was first introduced there.

719
01:05:04,615 --> 01:05:09,497
And also Amethyst transitioned fully to the Outbox model.

720
01:05:09,497 --> 01:05:14,183
And all of a sudden your app is connecting to a thousand relays in the background.

721
01:05:14,183 --> 01:05:27,177
We've also had major clients migrating out of the NIP4 and moving on to NIP17 for direct
messages, which not only upgrades the encryption used, but also improves the metadata

722
01:05:27,177 --> 01:05:28,277
privacy.

723
01:05:28,368 --> 01:05:41,245
and we've had the proposal of NIP104, which was the first attempt of getting the MLS
messaging layer security encryption scheme specced out for NOSTER.

724
01:05:41,285 --> 01:05:46,477
Since then, this, of course, is now being made obsolete by the Marmot protocol.

725
01:05:46,477 --> 01:05:49,719
Same idea, much more detailed specification.

726
01:05:49,728 --> 01:06:02,727
the gossip model, the outbox inbox model that we discussed last week, where you give hints
on where you store and read the notes on which relays, also gained major adoption across

727
01:06:02,727 --> 01:06:04,319
numerous clients.

728
01:06:04,319 --> 01:06:06,400
So that was only a year ago.

729
01:06:06,821 --> 01:06:07,356
What have we achieved since?

730
01:06:07,356 --> 01:06:08,345
Finally.

731
01:06:08,345 --> 01:06:14,968
think Mike Dildjer came up with the Gossip Model in 2023, early 20 in February.

732
01:06:14,968 --> 01:06:16,799
So it took two years.

733
01:06:16,799 --> 01:06:21,572
But yeah, it's finally widely adopted, which I'm happy about personally.

734
01:06:21,572 --> 01:06:24,745
Yes, indeed, these big protocol changes take a lot of time.

735
01:06:24,745 --> 01:06:27,127
And still, many clients don't support it yet.

736
01:06:27,127 --> 01:06:30,829
yeah, that's the thing in a decentralized network.

737
01:06:36,391 --> 01:06:32,420
to January of this year.

738
01:06:32,420 --> 01:06:33,270
other...

739
01:06:33,270 --> 01:06:36,302
paradigms that are emerging too, which are also interesting.

740
01:06:36,302 --> 01:06:38,793
The relay-centric model has had a resurgence.

741
01:06:38,793 --> 01:06:48,281
That's how things were in the very beginning, when it was just bunch of nerds picking
their relays and then talking on them before the outbox model.

742
01:06:48,281 --> 01:06:50,273
Now Jumble has brought that back.

743
01:06:50,273 --> 01:06:54,821
uh Pyramid uh and Flotilla in a little bit of a different way.

744
01:06:54,980 --> 01:06:56,521
And I think that's really interesting.

745
01:06:56,521 --> 01:06:58,363
It's a different way to use relays.

746
01:06:58,363 --> 01:07:00,495
It's complementary to Outbox.

747
01:07:00,495 --> 01:07:10,261
Outbox is good for the kind of broadcast social media use case like Twitter, but it isn't
the right solution for many different kinds of content like chat or, know.

748
01:07:10,261 --> 01:07:17,254
And I think like things like geocaching, location-based content are not really solved
still.

749
01:07:17,254 --> 01:07:20,578
So I think we will see more ways to use relays in the future.

750
01:07:20,578 --> 01:07:31,495
Yeah, that's a nice dynamic, guess, skipping forward to tying back to the uh Outbox model
and what we're seeing a resurgence this year is that uh now that we have the Outbox model,

751
01:07:31,495 --> 01:07:35,225
there's kind of a realization and a much more refined process.

752
01:07:35,225 --> 01:07:37,057
Like, OK, what does it not cover?

753
01:07:37,057 --> 01:07:47,543
As you said, it works great for the broadcast social media, but there's a bunch of use
cases that we're trying to discover that don't need that type of broadcast.

754
01:07:48,119 --> 01:07:53,473
there are some limitations to the outbox model too that people like Mazin have pointed out
in the past.

755
01:07:53,473 --> 01:08:06,728
um And I think there will be, eventually there will be new ways to use relays that form a
layer, like a caching layer on top of very popular social content that I don't think has

756
01:08:06,728 --> 01:08:08,313
really been explored, but...

757
01:08:08,313 --> 01:08:15,499
If you know anything about Twitter's architecture, they have all these different edge
caching strategies that are centrally controlled.

758
01:08:15,499 --> 01:08:25,253
And I think that's still something that NOSIR hasn't solved because we haven't hit the
scale to where that kind of caching and aggregation is needed.

759
01:08:25,253 --> 01:08:30,978
mean, maybe that NIP that you were mentioning earlier, the Trusted Attestations, might
have something to do with that.

760
01:08:30,978 --> 01:08:34,270
But there's definitely lots of interesting work left to do.

761
01:08:34,614 --> 01:08:39,634
and more work we have done, especially in this January, 2026.

762
01:08:39,874 --> 01:08:42,754
So just this month, a lot of things happened.

763
01:08:42,854 --> 01:08:54,234
Primal shipped its remote and local signer support, where now you can both keep your keys
in, for example, Amber and log into Primal, but also vice versa.

764
01:08:54,234 --> 01:09:00,694
You can keep your keys in Primal and then log into Amethyst, for example.

765
01:09:00,694 --> 01:09:04,232
Quite useful and interesting to see a...

766
01:09:04,232 --> 01:09:08,593
big flagship client becoming the signer after so many years.

767
01:09:08,914 --> 01:09:16,836
We've seen a complete security audit from BitChat, which found a couple issues that were
fixed.

768
01:09:16,857 --> 01:09:24,059
And both BitChat and Damos migrated away from the Ctor client to the Rust Tor client
called Artie.

769
01:09:24,380 --> 01:09:29,212
Very good to see here that novel uh new implementation being adapted.

770
01:09:29,212 --> 01:09:32,893
We've had the addition of addressable video events.

771
01:09:33,173 --> 01:09:38,214
also with different dimensions, uh horizontal and vertical.

772
01:09:38,395 --> 01:09:47,482
We've had the trusted relay assertions that give more context over the quality of certain
relays claimed by your friends.

773
01:09:47,482 --> 01:09:52,943
We have basic uh post-quantum cryptography now explored.

774
01:09:53,143 --> 01:10:00,475
And also the Marmot protocol has undergone a security audit with major changes and fixes
this month.

775
01:10:00,935 --> 01:10:13,728
And we've continued with new and novel applications being introduced, like for example,
Rideser for hailing a taxi over the Noster network and paying in Cachio eCash tokens.

776
01:10:13,969 --> 01:10:24,271
And we're making continuous progress on keeping your keys secure, even if they're in a
custody by using Frost and threshold signature schemes of Pomade.

777
01:10:24,812 --> 01:10:28,693
And now Diamos also ships NegEntropy.

778
01:10:29,273 --> 01:10:40,307
This is not just relay-to-relay communication, but also relay-to-client communication,
very useful to efficiently keep up to date with the latest changes to remote events.

779
01:10:40,668 --> 01:10:54,074
And Amethyst is on the slow but steady progress towards a desktop client, which would be
really good to see an established client taking on a new operating system in the release.

780
01:10:54,074 --> 01:10:57,093
Yeah, and that, think, rounds up this month.

781
01:10:57,093 --> 01:10:58,594
to be packed.

782
01:10:58,835 --> 01:11:05,684
It seems like each year the content and interesting things that are happening is steadily
increasing.

783
01:11:05,766 --> 01:11:07,618
We're definitely in a good trajectory.

784
01:11:07,618 --> 01:11:09,851
What you guys think of last month?

785
01:11:10,148 --> 01:11:11,802
Just keep it going, steady on.

786
01:11:11,802 --> 01:11:17,289
Yeah, this last month has been a long month, but I don't really remember much of it.

787
01:11:17,334 --> 01:11:18,224
don't know.

788
01:11:18,224 --> 01:11:28,230
There's a tendency to see the shipments or see the things getting pushed, the updates
getting pushed, and then a week later just to assume that it's always been that way.

789
01:11:28,230 --> 01:11:36,776
I think an interesting thread to consider with all this stuff that didn't come up is the
monetization and the business side of Nostra.

790
01:11:36,776 --> 01:11:47,707
Like, you know, sort of a subtext of ah the censorship and advertising dimensions of
social media are social media platforms are monetized.

791
01:11:47,827 --> 01:11:53,651
I think at the heart of it, that's what Nostra seeks to disrupt is that incentive uh
structure.

792
01:11:53,651 --> 01:11:55,954
ah And we certainly have not...

793
01:11:55,954 --> 01:11:57,583
accomplished that yet.

794
01:11:57,583 --> 01:12:04,408
First of all, there are very few clients that have any type of business model and the ones
that do are not profitable.

795
01:12:04,408 --> 01:12:12,752
I'm not aware of any profitable projects in the space yet because of course we're cutting
against the grain of profitability in order to make this happen.

796
01:12:12,752 --> 01:12:19,234
So I think that's a very large existential risk and um a place for lots of
experimentation.

797
01:12:19,234 --> 01:12:22,686
um There's lots of failure modes in connection with that.

798
01:12:22,740 --> 01:12:34,727
It comes up every so often and I'm glad to have Primal around as the leader in that part
of the space, um both to teach us how to do business models on Nostra, but also to show us

799
01:12:34,727 --> 01:12:36,288
what the trade-offs are.

800
01:12:36,308 --> 01:12:45,993
Primal still has Nippo for DMs and those need to die, but uh it's not a priority because
it's not something that affects their bottom line.

801
01:12:45,993 --> 01:12:50,162
So I think uh that's an interesting thread to pull out.

802
01:12:50,162 --> 01:12:53,575
and definitely is something that I'd like to see mature this year if possible.

803
01:12:53,575 --> 01:12:55,666
Yeah, that is really interesting.

804
01:12:55,707 --> 01:13:02,532
And I think we have a lot of interesting ways that you can get revenue with a Nostra AMP.

805
01:13:02,532 --> 01:13:08,516
And that's mainly because the user most likely has a wallet, especially with Nostra Wallet
Connect.

806
01:13:08,696 --> 01:13:15,461
It becomes very easy to make micro payments in the background without disturbing the
mental space of the user.

807
01:13:15,681 --> 01:13:19,217
So decreasing that mental transaction cost can be quite helpful.

808
01:13:19,217 --> 01:13:25,682
That could be something like whenever the user saps, just add 10 % on top and send that to
the developer.

809
01:13:25,883 --> 01:13:33,789
Or it could be whenever there is a release, add the Zap split of all the developers in
that release announcement, like Amethyst is doing, for example.

810
01:13:33,829 --> 01:13:39,073
And of course, ZapStore makes that easy to zap developers for a release specifically.

811
01:13:39,085 --> 01:13:44,309
we've seen these subscription models of both Primal and Damos.

812
01:13:44,309 --> 01:13:47,604
So there are numerous different ways that we could do this.

813
01:13:47,604 --> 01:13:50,966
we have really monetization just with a paid relay.

814
01:13:51,381 --> 01:13:59,276
And I guess the main that is lacking here is the scale to make those small payments add up
to be something meaningful.

815
01:13:59,477 --> 01:14:09,063
And then the big question is how do we bridge that gap between now and the future point
where we would have more users, where business models would be much easier to make

816
01:14:09,063 --> 01:14:09,664
profitable.

817
01:14:09,664 --> 01:14:12,225
Yeah, I do think that is the question.

818
01:14:12,225 --> 01:14:21,027
And Zaps are great, and I'm all in favor of supporting uh the software developers whose
software you use.

819
01:14:21,027 --> 01:14:25,299
I think that's a big part of open source culture that we need to import.

820
01:14:25,299 --> 01:14:32,341
But the fact is people don't often pay for free things, uh and that makes it really
difficult.

821
01:14:32,341 --> 01:14:38,519
Plus, there's an interesting inherent tension there too, where uh if in order to become
profitable,

822
01:14:38,519 --> 01:14:40,000
you need to be at scale.

823
01:14:40,000 --> 01:14:49,429
uh That's sort of in contrast with Nostra's strength of many small projects coexisting and
interoperating.

824
01:14:49,429 --> 01:14:59,430
So, you know, if your project is serving a thousand people, you're never going to have a
business model, but that's exactly the type of project that really works well on Nostra.

825
01:14:59,430 --> 01:15:06,666
So there's going to be this balance between scale and decentralization, uh which makes it
really hard to

826
01:15:06,666 --> 01:15:08,657
Yeah, that is a really good point.

827
01:15:08,677 --> 01:15:14,540
And I wonder if people would be willing to pay for a hyper customized client.

828
01:15:14,600 --> 01:15:25,809
Now, if we take this to the extreme where the number of users of a client is one, but you
really want to customize it to exactly how you would like it, that might actually be a

829
01:15:25,809 --> 01:15:28,261
service uh worth paying for.

830
01:15:28,261 --> 01:15:31,246
Yeah, it is, and Anthropic gets all the money for it right now.

831
01:15:31,832 --> 01:15:35,882
Cool, so this brings us to the bottom of our newsletter.

832
01:15:35,882 --> 01:15:47,016
We went through numerous upgrades to both Noster clients and relays as well as NIPS and
then took a deep dive down every January in Noster's history.

833
01:15:47,042 --> 01:15:50,620
A lot has happened and we won't stop building.

834
01:15:50,761 --> 01:15:52,642
So any final thoughts?

835
01:15:53,067 --> 01:15:54,819
No, think I've said enough.

836
01:15:54,819 --> 01:15:57,662
Thanks for having me and thanks for doing this newsletter.

837
01:15:57,662 --> 01:15:58,413
It's really helpful.

838
01:15:58,413 --> 01:16:00,549
I enjoy the historical part especially.

839
01:16:00,549 --> 01:16:02,932
Yeah, same.

840
01:16:03,203 --> 01:16:04,986
This is turning out to be really nice.

841
01:16:04,986 --> 01:16:12,832
The historical reviews and whatnot are also kind of a reminder of what I've forgotten to
look at or what I've forgotten about.

842
01:16:12,832 --> 01:16:13,748
So

843
01:16:13,748 --> 01:16:15,620
This is, yeah, thanks.

844
01:16:15,675 --> 01:16:19,217
Yeah, thank you guys to the guests of the podcast.

845
01:16:19,217 --> 01:16:23,200
And this has been delightful to work through this newsletter with you.

846
01:16:23,200 --> 01:16:27,383
And of course, thanks to all the developers mentioned in this newsletter.

847
01:16:27,383 --> 01:16:28,423
You're doing good work.

848
01:16:28,423 --> 01:16:29,544
Keep it up.

849
01:16:29,764 --> 01:16:37,949
And if we forgot your project to be included in the newsletter, then please yell at us on
Noster so that we include it next week.

850
01:16:38,895 --> 01:16:42,351
yeah, feel free to review the sections and make fixes.

851
01:16:42,351 --> 01:16:44,202
This newsletter is up on GitHub.

852
01:16:44,466 --> 01:16:47,244
And thank you very much for joining us this week.

853
01:16:47,244 --> 01:16:48,649
See you next week.