Gzuuus

Forever learning, continuously buidling⚡
cryptoanarchism student
chat: https://cordn.net/p/gzuuus

#noderunner#Bitcoin | #technology | #art | #electronics

Public Key

npub1gzuushllat7pet0ccv9yuhygvc8ldeyhrgxuwg744dn5khnpk3gs3ea5ds

NIP-05 Address

gzuuus@contextvm.org

Profile Code

nprofile1qqsypwwgtll74lqu4huvxzjwtjyxvrlkujt35rw8y026ke6ttesmg5gpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduay3hhv

Publishing to

Author Public Key

npub1gzuushllat7pet0ccv9yuhygvc8ldeyhrgxuwg744dn5khnpk3gs3ea5ds

Show more details

Last Notes

2026-08-18 07:46:59 UTC

https://blossom.primal.net/fd82d89715295c88f4782bdc894c097fb8f26010e65b62862bd5689a038cd253.jpg

2026-08-17 07:36:53 UTC

https://blossom.primal.net/859dff99a2921934d48d598823724d19a9ab5bdf6d06b4af0152d28ab65d677f.jpg

2026-08-15 17:11:34 UTC

- reply

Man I need to gather some time to play with all of this

2026-08-13 08:30:36 UTC

https://blossom.primal.net/fbdb8b3232a4a7e2564b482f464f4dc87e0272e9760488be189e37ecd6d93377.jpg

2026-08-07 08:26:00 UTC

GM 🌞
https://blossom.primal.net/9654ce6d21b3ab03577cf413053a004423be903c99ffe2180adddfc96031edf0.jpg

2026-08-06 09:07:55 UTC

https://blossom.primal.net/0555a3959c526d770239a23cf2a83d72bd23240b38efed72ef4cb3746f0c4afb.jpg

2026-08-05 09:00:21 UTC

https://blossom.primal.net/9d99658189d0e6530e6fe5a6990492e56862e706bd3162af2abd815239cf75e9.jpg

2026-08-04 09:07:27 UTC

- reply

Me too, then I discovered orca and so far enjoying it, it fills some gaps herdr had from my pov

2026-08-04 07:35:09 UTC

- reply

Hahaha tbh I'll probably give you more headaches

2026-08-03 21:58:28 UTC

- reply

The good life 🫂

2026-08-03 06:30:39 UTC

GM🏄

2026-08-02 11:18:34 UTC

- reply

you're sharp my friend hahaha

2026-08-02 10:29:51 UTC

I'll get indigestion from so much popcorn 🍿

2026-08-01 09:42:44 UTC

- reply

Trezor? Why?

2026-08-01 09:33:39 UTC

- reply

GM sk8r

2026-07-31 14:46:57 UTC

- reply

The point I wanted to make is that the "rush effect" would help attackers prioritize targets by just watching the mempool. And yea, I passes my text through an llm. Just deleted, I will rewrite it later, did it in a rush

2026-07-31 14:38:55 UTC

So is the mempool full of weak ass addresses yet? Probably it's about to be.
Everyone yelling "move your funds NOW" isn't wrong. This is a live attack and sitting still isn't safer. But here's the catch nobody's mentioning: even if your wallet has poor entropy, it is indistinguishable from any other wallet. The moment everyone rushes at once, the mempool fills with exactly the weak entropy addresses attackers are hunting. Your unconfirmed sweep tx just sits there publicly, basically flagged "fleeing Coldcard user" waiting on a block.
The ugly part is that while it sits there, if your sending key is weak, whoever crack it before the tx confirms can fire a higher fee tx that redirects your funds somewhere else. Full-RBF means bigger fee wins, and for the mk3 weak wallets that crack fits confortably inside the time a block confirm.
So yeah, move, but pay the fee (fast confirm = short window) specially if your address is one of the weakest ones.

2026-07-31 13:16:11 UTC

- reply

It was at some point

2026-07-31 12:51:06 UTC

Another great (yet painful) lesson about why open source is important, and why having as many eyes as possible, especially in security sensitive projects, is crucial.

2026-07-31 07:31:22 UTC

GM what a fuckity fuck oopsie woopsie 👀

2026-07-29 08:01:00 UTC

- reply

Well, anything that's not nip01 could be considered "special" so relays need to support extra features like count, search, etc. So yes, I would say vertical

2026-07-29 06:30:11 UTC

GM🖖

2026-07-28 10:58:26 UTC

My god... And they complain about destillation from other companies... They are evil
#nevent1q…r7jj

2026-07-27 19:02:56 UTC

TLDR of the TLDR: Notes and other stuff TRANSMITTED by relays. Assume storage, have fun 🫂
#nevent1q…hz4f

2026-07-27 12:42:08 UTC

- reply

Yea that's interesting indeed we are thinking about how to do the same in cordn. So far that's one of the options, and the other is to share group state for the epochs you want new users to have access to, so they could naturally just catch-up from them and decrypt by themselves. I think this scales better since it avoids redundancy. But still exploring different solutions. In any case, why is this incompatible with the cordn client? I should be able to join your group even if I don't have access to the previous map data right? Are you using your own cordn coordinator?

2026-07-27 12:23:07 UTC

Great post, and it gives me the groundwork to write about something I’ve been thinking about for a while now. I’ve discussed it with different people, the latest being @npub1wf4…dgh9 . This is about relay specialization versus a dumb relays topology. There’s a lot to unpack here, but I’ll try to keep it concise and dynamic.
Also tl;dr at the end of the note ;)
One of the first things that caught my attention early on when I discovered Nostr was that relays were dumb and clients were smart. All relays could be used homogeneously and interchangeably. The more relays, the better, right? The bigger and more distributed the network, the harder it is to shut it down or prevent someone from using it. In other words, in this topology, decentralization and censorship resistance scale horizontally. And this is true, I really believe it. But as Nostr evolved, more use cases emerged, new attacks appeared (spam, etc.), and Nostr started to need more specialized relays, hardened specs, rules, and so on. This shifts the balance between dumb relays and smart clients, and in my view, it’s a logical evolution.
A one-size-fits-all solution is difficult, if not impossible, to achieve. We’re seeing this tension now with the buzz (I used this world deliberately 🐝) around chats, groups, and so on. NIP-29 is a clear example, it acknowledges this tension from the start and accepts it to make things work. From my perspective, this is the right approach, and I completely agree with @npub1t6j…ksrw :
"The point of Nostr was never to get rid of servers; the point of Nostr is to be free again to leverage them for what they are good for. "Platforms" conflated purposes, also taking responsibility for identity and by extension the social graph, resulting in the capture of the user."
#nevent1q…hthu
Accepting this limitation of "dumb" relays means accepting that not every use case will fit into general purpose infrastructure. Expecting any use case to work reliably, beautifully, and without issues in such a setup is a stretch. Specific use cases with constraints or requirements need specialized services that can support them.
On the other hand, the problem with specialized relays is that they scale vertically, unlike general purpose ones. This means each specialized kind of relay becomes its own decentralization and censorship resistance vector. This does create some tension with Nostr’s original promise, but in my view, it’s a fair and honest one. Specialized relays make sense, and we shouldn’t feel aversion towards them.
Beyond this, there’s a third path I’ve been exploring with @npub1dvm…3jdm , moving the "smart" logic to a separate service that runs alongside relays and just uses them as a bus. This way, complex or specialized logic can be offloaded from relays, which can remain as dumb and homogeneous as possible. Before CVM, DVMs already offered this characteristic, it’s just RPC over Nostr. From my perspective, this approach strikes a great balance. As I mentioned earlier, if relays are standard and not specialized, they remain homogeneous, decentralization and censorship resistance scale horizontally, and the network becomes more resilient and harder to shut down. CVM also doesn’t impose storage pressure on relays, making relays cheaper and more sustainable to run. A clear example of this is Cordn coordinators, an specialized service that handle ordering so the MLS encryption state machine can work without issues. They interface through relays and store encrypted blobs, but nothing is stored in the relays themselves. Any relay accepts their traffic, and it works well.
Another nice feature of offloading logic from relays and running it in a separate service is that the bus doesn’t know what’s running, and the logic service doesn’t have network visibility. This creates a nice balance that benefits privacy and deniability. To wrap up this section, another interesting advantage is that running CVM servers is easier than running a relay. Relays need to be exposed, requiring network configurations and touching parts of the internet’s permission backbone (DNS). Of course, you can run a relay on Tor, but a CVM server doesn’t need any configuration, you just run it, and it’s accessible. You can even run it from your laptop in a coffee shop.
TL;DR: Dumb relays are great for decentralization and censorship resistance but fall short for use cases with specific requirements. Specialized relays are necessary and make sense for supporting those use cases, but decentralization scales vertically. CVM is a third path that leverages a network of dumb relays while offloading logic from them.
#nevent1q…27qe

2026-07-27 10:29:21 UTC

- reply

Well, I’m still trying to wrap my head around the protocol, and my analysis also points to a relay specialization for running Concord groups. Concord introduces special features, such as the gift‑wrap inversion and edge cases like deletion, that cannot be solved in any way by real relays aside of your other points from your article. Alex left me a note saying "deletion by all" can be seen as a feature, not a bug. I think it is a huge source of instability/edge cases, especially in large, public groups where not everyone is trusted and can easily disrupt the group’s health.
As you noted, rate‑limiting and relays potentially dropping events can be harmful to Concord’s control plane. In a world with a diversity of relay implementations and cofigs, each with different settings for rate limiting, spam prevention, and so on, this could become very unreliable, assuming relays will behave homogeneously is too happy path protocol design. Put aside from the ability of relay operators to calculate heuristics over the stream provenance and users.
So, yea, I would say that Concord works over any relay for its fundamental operation, but it is probably not reliable in the long term because of all the possible relay quirks, weirdness, and edge cases that could exist. NIP‑17 is more straightforward yet still considered unreliable by many developers, so Concord could be even less reliable. Let’s see how it evolves

2026-07-27 08:26:07 UTC

- reply

https://blossom.primal.net/420e9c6891aa97522500900fd064b170b5d2b7b51b7a206f5bdbaebf362ade89.jpg

2026-07-27 08:22:56 UTC

I'm looking for ~/

2026-07-27 07:43:45 UTC

GM🌞

2026-07-26 12:42:44 UTC

- reply

How did you achieved that? To provide historical messages to new joiners?

2026-07-26 11:04:01 UTC

- reply

Do you have a cordn group for this? 👀

2026-07-26 11:02:21 UTC

Just wow 👀🔥
#nevent1q…4wla

2026-07-26 10:51:43 UTC

- reply

Also the deletion issue, in a normal relay anyone could delete anything because everyone share the same stream key, therefore deletion requests are valid. Maybe not important in a "trusted" environment, but critical flag in a public o big group

2026-07-26 10:37:17 UTC

- reply

Oh man 🫂

2026-07-26 10:24:51 UTC

- reply

This is really cool, congrats! 👏👏👏
But so far, Concord needs special relays, right? Or would it work fine with any existing relay?
I wrote this note the other day but never got a response. Maybe you can clear my doubts
#nevent1q…twku

2026-07-26 09:33:04 UTC

GM 🌞

2026-07-24 17:22:14 UTC

This is great! Look at this flashy url https://cordn.net/p/gzuuus Just ping me there if you want to chat. If you want one like these answer in the comments of the release note 👌
#nevent1q…v8en

2026-07-22 16:38:35 UTC

- reply

2026-07-21 16:14:59 UTC

- reply

Yea, sure that's the same critique I had for nip-70 (protected events) since the beginning, but from my perspective, the key here is that if an implementation doesn't follow the spec is a bad implementation, and then we can discuss about sibyl attacks, but that's a different conversation.

2026-07-21 16:07:11 UTC

- reply

A protocol defines a contract that all implementations must follow.
If an implementation deviates from that, it is either a non‑compliant (bad) implementation or an entirely different protocol.
The “discretionary” aspect refers to enforcement: no external authority automatically guarantees compliance, so violations may go unchecked. When non‑compliance occurs, interoperability breaks

2026-07-21 15:48:28 UTC

- reply

It's just what the spec says, its not trust, just compliance with the protocol. An implementation doing something different is just not implementing the protocol

2026-07-20 13:19:12 UTC

A little secret
#nevent1q…xyug

2026-07-20 13:14:53 UTC

- reply

Hahaha yea, sure, but that will potentially interfere with other standards, so it is a specialized relays, which essentially is a server with an specific function

2026-07-20 08:51:28 UTC

- reply

Well, kindly pushing back on the "just like regular nostr" part. I've been reading through the spec and the Armada codebase, and that part doesn't really hold up. Concord relays need a specific configuration, as far as I can tell.
Concord reverses nip 59. A normal gift wrap has a random one-time author and the real recipient in the p-tag. Concord flips it: the author is a the stream key, and the p-tag is a random ephemeral key. Members read by the author, not by the p-tag. So it breaks on any relay doing the nip 59 "correct" thing, because nip 59 says relays SHOULD only serve kind 1059 to the marked recipient, and here nobody is the marked recipient. The spec admits it outright: "Communities must choose relays accordingly."
Also, if someone uses relays that prune or just nuke their db, that breaks the whole authority layer (roles, bans, channels all ride on 1059), and deletion gets messy because every wrap is authored by the same shared stream key that every member holds: on generic relays that honor author-based deletion, anyone can delete any message, or all of them, just by sending deletion requests, which from my POV is a huge hole.
In practice Armada runs on two default relays configured in the same way

2026-07-19 17:28:05 UTC

- reply

Well, someone needs to do it, and if you are relying on someone else infra (specially when there is no mandatory redundancy / coherence between relays) you better be prepared for that infra to disappear or be hostile

2026-07-19 17:02:12 UTC

- reply

Relays are servers too ¯\_(ツ)_/¯

2026-07-18 16:08:32 UTC

> 2022-Present: The Butthole Era
https://velvetshark.com/ai-company-logos-that-look-like-buttholes

2026-07-18 11:13:57 UTC

Two years ago, I started this discussion about on‑chain channel funding for phoenixd https://github.com/ACINQ/phoenixd/discussions/24#discussioncomment-8996757 . Finally, it has been worked out and released! Yay! 🔥🔥

2026-07-17 12:22:22 UTC

Since then, I’ve moved from using Cordn through its PWA to using it in the Keychat browser. The reason is that I was logging into the PWA using a NIP-46 remote signer. It worked flawlessly, but each signature required a round trip through relays, a limitation of remote signers, as they can’t be called natively from PWAs. Now, by using it in Keychat, I’ve overcome that limitation, and the app feels much faster for signed operations (which aren’t too frequent, anyway), Cordn is very signer-friendly. Also I can use it from my desktop and mobile. So good 🏄
#nevent1q…8xwy

2026-07-16 17:58:23 UTC

- reply

I will revibe nostree but that will take a week or so

2026-07-16 17:57:51 UTC

- reply

I'm a https://wavefunc.live/ enjoyor. Maybe contextvm.org as well?

2026-07-16 16:36:49 UTC

- reply

O man that would be amazing

2026-07-16 16:13:04 UTC

- reply

This is cordn.net the most cpunk chat nostr have

2026-07-16 15:38:38 UTC

Its alive! 🔥🔥
https://blossom.primal.net/2d17c4bf10f6239ed871832aea382d1bf1ea3c95716390257495b4634a99c564.jpg
#nevent1q…l34w

2026-07-16 13:53:44 UTC

34 days since SpaceX’s stock market launch
https://www.latimes.com/business/story/2026-07-16/spacex-stock-erases-gains-slides-below-ipo-price-in-intraday-trading

2026-07-16 10:54:17 UTC

This is pretty cool. An agent paying by itself for tool execution. In the demo the agent pays for listing and discovering relays through the @nprofile…gw67 's relayVM server. 🔥🔥
#nevent1q…93l3

2026-07-16 05:23:00 UTC

GMo

2026-07-15 07:43:57 UTC

GM🥁

2026-07-13 08:43:21 UTC

GM 🌞
https://blossom.primal.net/ebfdb08fb002c6a2f2ad5b1a4304e724aeb07ca635f5a3de4168d55552336e6a.jpg

2026-07-10 15:27:21 UTC

- reply

https://cordn.net also read my latest article

2026-07-09 18:44:27 UTC

- reply

Are you sure? So far seems that what they are proposing is client side and pre encryption

2026-07-09 18:32:10 UTC

- reply

But chat control is supposed to read your messages even before they hit the wire right?

2026-07-09 08:25:41 UTC

GM! Today, the European Parliament will vote on Chat Control 2.0 in an urgent procedure, even though it was previously rejected... Therefore there is no real urgency, people have already expressed their positions. But by pushing it this way, a majority of Parliament will need to vote against it. And since absences count as a "yes" vote, and summer has just started, you can imagine... well, these people are villains, and we’re pretty doomed in that sense.
The only good thing? Not much, tbh. We’ll have to carve our way out of this dystopia. So let's keep building 💪

2026-07-08 16:23:40 UTC

My old KYC’d phone broke, so I got a new cheap one to put the SIM in. I was horrified by the amount of crap (bloatware) it came with from the factory (Amzn, Facebook, Instagram, TikTok, Temu, Netflix... the list goes on). The first thing I did before even connecting it to the internet or inserting my SIM was to enable ADB, run UAD (https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/), remove all that junk, and then install @nprofile…tdq0 . Now the phone is as clean as it could be. I wish everyone could do this it’s not difficult, though there’s a lot of resistance for normies. Anyway, life is beautiful again! :)

2026-07-08 09:04:27 UTC

- reply

GMan 🫶

2026-07-08 07:39:00 UTC

https://blossom.primal.net/ebd68cd78af6e1501bb73155f4febbfd6271dc74629f931b88d4b0d35ad1cd05.jpg

2026-07-08 06:51:22 UTC

GMGM 🏄

2026-07-07 17:19:41 UTC

- reply

Have you checked cordn.net ?

2026-07-07 17:12:21 UTC

Great advice
#nevent1q…unpd

2026-07-06 07:18:56 UTC

- reply

Cannot see it

2026-07-04 08:34:15 UTC

GM
https://blossom.primal.net/35cbec81483ce6e342802c486c5c5a3fe493635a8e07ca362e64108242154388.jpg

2026-07-03 05:23:22 UTC

GM 🫶
https://blossom.primal.net/4732b1493d1abea5ffa08859c3fc59f157b73dd9d27bbafcba555f7cdd3a2b00.jpg

2026-07-02 19:49:54 UTC

- reply

It is similar to a marmot. It’s MLS + Nostr for identity. The difference is that instead of storing messages on relays, Cordn uses a coordinator. However, this coordinator is accessed through Nostr relays, as CVM (similar to a DVM). So everything is transmitted via relays as ephemeral events, but not stored on them.
If you really want to understand this protocol, I have an article published covering Cordn and the other messaging protocols built over Nostr. It’s called "Private Communications Over Public Infrastructure."

2026-07-02 19:02:01 UTC

Btw that meme is sublime 🤌 I think it was an early @nprofile…hgpr ?
https://npub1qc8quy6ah46k4q9es6fvjqjgk6rdv42cdsccnjhyx59j35n7azlq7ntwss.blossom.band/37797965261b03497a4e94814b6a7ac928871925217a0aa575f14f3c53d2fe74.png
#nevent1q…vwag

2026-07-02 07:30:55 UTC

GM🙂‍↕️

2026-07-01 21:51:08 UTC

https://blossom.primal.net/a145f73846e07a17415a7f346efdeac7320342409a4d69e7f39330b803fa50e7.jpg

2026-07-01 06:42:10 UTC

Gracias @nprofile…jt8y por este regalazo 🧡
https://blossom.primal.net/0a61f33ca7f1f5a8e800498e435696349dc16c30e2dc258bc38518abeacf56c9.jpg

2026-06-30 09:05:17 UTC

- reply

GM 🖖

2026-06-30 08:07:14 UTC

GM🤙

2026-06-29 11:09:33 UTC

Man, this guy is winning my apathy so quickly, hard, and dirty
#nevent1q…er3h

2026-06-29 11:08:34 UTC

- reply

It seems like he’s the only one in danger

2026-06-29 09:38:14 UTC

- reply

GM!

2026-06-29 08:50:20 UTC

- reply

Great, thanks for answering. Do you have a spec or research paper I can read? I'm quite interested in the topic. Do you think “asymmetry” could be achieved so the secret each user shares doesn’t need to be symmetric?

2026-06-29 08:29:16 UTC

- reply

Great, amon duul. Long time since I heard them last time

2026-06-28 21:28:14 UTC

- reply

This is very interesting indeed. I need to keep wrapping my head around this, but I have a doubt. How large does the initial prompt have to be? AFAIK, this initial prompt that both users need to use in order to initialize the LLM state so they can decode would work as a kind of “symmetric key,” right? If this is true, I was just wondering how secure or what is the shape of that initial prompt is, and whether it is susceptible to brute forcing in some way. Because for someone to participate in a conversation, they just need the LLM model and the prompt, and then they can exchange encoded messages out of band, right? Please correct me if I’m wrong on any of the points; I’m still trying to understand this :)

2026-06-25 09:01:34 UTC

- reply

Hey great I think it'll be ready today or tomorrow.
And well marmot was already covered. This v2 doesn't change privacy assumptions at first look. I'll take a deeper look to understand if I need to update that section 👌

2026-06-24 19:43:42 UTC

I'm working on an update for my article "private comms over public infrastructure" will cover cordn from @nprofile…m8px and concord from the Vector team. Among other findings. Should I cover something else?

2026-06-24 06:42:09 UTC

GM 🖖

2026-06-22 14:46:55 UTC

- reply

Hahaha fair point...

2026-06-22 14:28:25 UTC

- reply

They could perfectly use milliseconds and life would be better

2026-06-22 14:22:38 UTC

Why nostr events use timestamps in seconds, WHY 🥲

2026-06-22 09:15:59 UTC

GM🌞

2026-06-22 08:41:21 UTC

- reply

Is that true?

2026-06-21 01:04:01 UTC

Me between prompts
https://blossom.primal.net/7a79c12e2530d156db6abc72d5313b73a63656d3393f3de0ca526487ff27bf59.jpg

2026-06-19 16:41:13 UTC

- reply

A ok, so what you mean is a cvm based equivalent to loom? I've already chatted with arjen a couple of times about it, but seems there is not too much interest 🤷‍♂️ maybe I take the lead, but I'm too busy for yet another non paid side project 😅

2026-06-19 12:41:07 UTC

- reply

What do you mean? Any relay is compatible with loom / cvm as far I understand. Do you mean some specific feature like running them or something?

2026-06-19 08:29:08 UTC

GM🌞

2026-06-18 18:34:28 UTC

- reply

P2p and alternative markets my friend. If these guys have to give us permission we'll be cocked sooner or later

2026-06-18 18:31:03 UTC

- reply

No lies detected