Gzuuus

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

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

Public Key

npub1gzuushllat7pet0ccv9yuhygvc8ldeyhrgxuwg744dn5khnpk3gs3ea5ds

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsypwwgtll74lqu4huvxzjwtjyxvrlkujt35rw8y026ke6ttesmg5gpz3mhxue69uhhyetvv9ujuerpd46hxtnfdu43kapj

Publishing to

relay.damus.io

Author Public Key

npub1gzuushllat7pet0ccv9yuhygvc8ldeyhrgxuwg744dn5khnpk3gs3ea5ds

Show more details

Last Notes

2026-05-20 15:27:23 UTC

- reply

I think payments methods should be always be intentional and never assumed. So giving the users the ability to define them should be enough, then clients can implement interoperability with whatever they want

2026-05-20 07:58:59 UTC

This guy is building 👀
#nevent1q…pqw6

2026-05-20 07:08:26 UTC

GM 🦖

2026-05-20 06:54:19 UTC

- reply

LFG much better 👌

2026-05-19 16:37:00 UTC

- reply

Brutal, he disfrutado escuchando 👌

2026-05-19 08:52:32 UTC

- reply

Was in favor of Google login. Just for normies. I'll never update

2026-05-19 08:51:35 UTC

- reply

Is that mordor? Hahaha gm 🫂

2026-05-19 08:11:56 UTC

- reply

Thanks for that, appreciate it :) 🫡

2026-05-19 07:44:40 UTC

- reply

You are not, I'm pointing at this since the beginning. I'm glad now more people are realizing this 🙏

2026-05-19 07:43:29 UTC

GM🌞

2026-05-18 19:37:02 UTC

- reply

Until it is

2026-05-18 19:27:59 UTC

One of the most difficult lessons to learn about privacy and how it works in the digital world is that you don’t realize you need it until it’s too late; at that point you wish you had been more conscious of it from the beginning, but it’s already too late.

2026-05-18 12:49:31 UTC

What if a user could publish a silent message string (exactly the same idea behind silent payments) and others could derive one-time npubs from it to send private messages? You’d need relay hints in the string, and it’s clearly better for 1:1 than groups, but it seems very possible. We discussed this during the last #soveng
Free idea.

2026-05-18 10:12:11 UTC

- reply

You'll need to derive an xpub for that. But still not a good solution since users would need to derive address at random derivation paths to avoid collisions, among other nuances. So silent payments are the right solution, as every user will derive addresses without needing to worry about the collision or other nuances

2026-05-17 20:34:48 UTC

I'm enjoying this onchain zap episode and discussion, it's raising awareness among users while also generating educational content, which is always beneficial. Some users will become more conscious, while others might get rekt, but hopefully they'll learn along the way.

2026-05-17 18:24:31 UTC

- reply

You are the only one saying that they are the same. I just said that if you want to throw money to an npub, Cashu gives you the same properties as on‑chain.

2026-05-17 18:17:48 UTC

Some thoughts about the ongoing “on‑chain zaps” discussion.
I think that, at the end of the day, this is good in the sense of bringing awareness to people so they understand the implications and trade‑offs of the different solutions we have nowadays for transacting on Nostr. Not everyone understands what all of this means, and technical concepts can be a bit intimidating, so here is, from my perspective, the important things to know in order to navigate this discussion.
Nostr and Bitcoin have something in common: the underlying cryptography used to generate key pairs. This means that a Bitcoin address and a Nostr address are effectively the same. You can receive btc to your nostr public key and spend using your nsec. This is not new; it has been the case since Nostr was conceived. Since that moment we could use Nostr addresses as Bitcoin addresses, nothing new.
So why haven’t we used this “magic” property of Nostr from the beginning? Because of address reuse. Address reuse can seriously harm your privacy when using Bitcoin. Address reuse is simply the practice of using the same address for sending or spending multiple times. This was a concern since Bitcoin’s early days, and it is a well known bad practice, nothing controversial, nothing new. The good news is that there is an easy way to mitigate this: simply do not reuse addresses. The reason “on‑chain” zaps have never been promoted, even though they have always been possible, is because of this.
Address reuse is bad, very bad, it makes your balance, and transactions public and traceable, also from your counter part, and it gets even worse if the same address you receive to and spend from is also linked to your identity (e.g., your username, social activity, contacts, or even your IP address if you are a relay operator). You do not need to be a Korean hacker to collect all of that information, and build a strong model of who you are, your environment, etc. If someone considers you a valuable enough target, they may attack you. This is what the “wrench attack” expression refers to. Nothing of this is new. Bitcoin users, and not just Bitcoin users, have suffered these kinds of attacks because of address reuse, lack of privacy, and lack of awareness. So yes, address reuse is bad, but an address alone is less harmful than a Nostr key, which has more attached metadata.
If you do not care because you think your environment and community are secure, that is fine; not everyone has that privilege. However, wrench attacks are not the only risk. Governments, regulators, and three‑letter agencies would also have a clear picture of all this, and again, if they consider you valuable enough, you will give them all this information for free.
Enough about that. As I mentioned, there is a lot of text discussing the dangers of address reuse, and it is nothing new or controversial, everyone in the space understands it is harmful. I mean, maybe not everyone... but still, nothing controversial; derivation of addresses is implemented in all wallets, and normally wallets not allow you or will warn you of address reuse.
So what options do we have for transacting in Nostr, and what are their trade‑offs?
Zaps were the first solution. This is NIP‑57 and it uses Lightning to perform payments. The way they work is that you attach a payment address to your profile metadata. Unlike on‑chain zaps, this is optional and opt‑in: if you want to receive payments, you can set a LN address or an LNURL string on your profile, whichever you choose, and you can change it at any time. The spec also defines a way to publicly signal when a payment is made so users can make these public, but the important part is that it is optional, and you can make the payment very private, with no need for social signaling; only the sender and receiver know it happened.
A better version is Bolt12, which is a newer standard and provides a more private way to have a static address that people can reuse without a server in the middle and without compromising privacy. How is that possible? A static address meant for reuse that does not leak metadata sounds like black magic, but it simply leverages some of Lightning’s properties. You can read about it in detail, but in any case it is another possibility for private Nostr transactions; you can simply attach the Bolt12 address to your profile metadata. In the case of Bolt12, social signaling would be a bit awkward, but if your point is to transact publicly you can just use regular zaps.
Cashu is another option, and I think it is the best if you just want to “throw money” to a user, similar to what on‑chain payments give you. The advantage is that it is much more private. The trade‑off is that it introduces a mint in the middle, which weakens the custodial model a bit. But you know, there are no perfect solutions; there are always trade‑offs, and understanding them will give you the best fit for a given case. You can also reclaim Cashu tokens if the receiver never claims them, which is an additional benefit.
Nut‑zaps just add the social signaling part to sending Cashu tokens.
There are other solutions, such as BIP‑47, but they present some points of friction.
In summary, I hope to give you the keys to navigate this ongoing discussion. On‑chain zaps are a reckless solution that puts users at risk. Understanding their privacy implications is not easy and requires education. Non‑technical users usually do not have the time or confidence to dive into these details, and pushing something without proper caveats or disclaimers is harmful. It compromises users without their knowledge, which is why some people are speaking up and why I am writing this post. You should know the implications.

2026-05-16 23:03:20 UTC

Nostr... Once was a cypherpunk dream, now is becoming a cypherpunk nightmare

2026-05-10 12:36:39 UTC

- reply

That's it! 🫶

2026-05-10 10:00:27 UTC

- reply

You already know, ask your heart 🧡

2026-05-10 09:52:49 UTC

You gotta love this island #soveng
https://blossom.primal.net/2c6ea17cd9b21d66cbefa337d5c636660b374cafebe7e5a6c502313bcd23f245.jpg

2026-05-06 19:44:22 UTC

- reply

That's not the problem. If someone suddenly sends 10 BTC to your public key, you become a target. There was a reason this hasn't been promoted before. It's not new neither every public key has been a btc address since ever. If you think creating a beautiful UI/UX around this is fine, that's your choice, but I believe it's dangerous.

2026-05-06 11:52:57 UTC

- reply

Thanks man! Appreciate it 🧡 hope you are doing great :)

2026-05-05 15:12:57 UTC

- reply

Thanks!

2026-04-23 19:44:03 UTC

- reply

Va bien. Diferentes cosas, pero normalmente enfocado en contextvm

2026-04-23 19:35:49 UTC

- reply

Pues claro 🫡

2026-04-23 19:28:10 UTC

Every week there is new shit that's the new shit, but tomorrow it would be old shit replaced by the new new shit, so indeed it doesn't matter... This is the shittiest shit about new shit nowadays... Shit

2026-04-22 09:16:21 UTC

- reply

Oo yea it is f good

2026-04-22 08:20:23 UTC

GM 🖖

2026-04-21 21:13:31 UTC

Vibes and stuff
https://music.youtube.com/watch?v=jLXe13ICck4

2026-04-21 20:55:14 UTC

- reply

Pure poetry

2026-04-21 19:34:07 UTC

- reply

Ricky is the best

2026-04-21 15:19:00 UTC

- reply

Hahaha banana bread?

2026-04-21 15:14:28 UTC

- reply

@npub1wsp…7rqf is this real?

2026-04-16 16:00:59 UTC

Let's #soveng hard 🫶
#nevent1q…4sr3

2026-04-16 08:18:22 UTC

It seems that the marketing strategy of most major US AI labs is to instill as much fear as possible in everyone.
#nevent1q…kn6u

2026-04-12 17:24:52 UTC

- reply

Yes, love it 🧡
https://music.youtube.com/watch?v=6zexKiOafjk

2026-04-12 09:52:01 UTC

https://music.youtube.com/watch?v=slDNOtOQ8oA

2026-04-07 19:12:19 UTC

Encrypted communications != private communications. Few understand this

2026-03-27 08:56:34 UTC

- reply

GM :)

2026-03-26 08:56:43 UTC

Guess who is using it the most 👀
https://blossom.primal.net/f6a571a06587058214b89b6d178bf80c4b8976d6ffb3f8b22be2300fa5a1563e.jpg

2026-03-22 10:40:24 UTC

GM!

2026-03-21 18:48:31 UTC

Hey! How’s it going? I’m sharing some new ideas that came out of @npub1s0v…rmq5 6. They feel especially relevant given the recent news about compromised keys.
This is a new NIP for identity checkpoints. In simple terms, a checkpoint is a signed event that says: "this key is me at this moment" Over time, that checkpoint can gather evidence and attestations from other people, helping to maintain identity continuity.
https://github.com/nostr-protocol/nips/pull/2278
The idea is that anyone can create a checkpoint to show they control a key. Later, if something bad happens, like losing the key or having it compromised, they can publish a new checkpoint linked to the old one. That creates a lineage people can look at to decide whether the new identity claim seems legitimate or trustworthy.
When you combine this with OTS, social graphs, NIP-05, and other forms of evidence, you get a way to deal with identity recovery, which in decentralized networks like Nostr, is crucial since there is no central authority that can definitively say "this person kept their identity". The best we can do is evaluate the available evidence. This proposal is all about that
Alongside this, there is also a complementary Snapshots NIP, which lets users preserve a specific version of a replaceable event. That can strengthen the evidence and reduce some attack vectors.
https://github.com/nostr-protocol/nips/pull/2279
I’ll soon publish an app to help create, visualize, and use all of this. Hope you find it interesting.
#soveng #sec-6

2026-03-19 21:00:49 UTC

- reply

I may be dumb or something but still not understanding why it is relevant to include the sig, as the id contains all necessary stuff to verify.

2026-03-19 12:50:56 UTC

- reply

As far as I understand, there is no problem here. You have an ID of an event, and whether a signed version of that event is created at the same time or afterward the ots does not matter for the validity of the proof, since the ID alone contains all the meaningful details like the author's public key, created_at, and the entire payload. The ID proves that the event payload existed at some point in time, and the signature makes that claim verifiable. Therefore, there is no real need to include anything more than the event ID

2026-03-19 08:44:08 UTC

- reply

Why the dataset is not public?

2026-03-18 23:31:28 UTC

- reply

Well, the ID is unique for each event, it contains the digest of all the fields present in it including the pubkey of the author, so the ID alone should be enough as a reference for that 'contract'. Then, you will go to the notary carrying the entire event and the OTS proof, and say, 'See, this event existed at this point in time, and the signature is valid' and that already serves as irrevocable proof

2026-03-18 22:55:35 UTC

- reply

To be honest, I think that none of that is really needed, the event ID is enough to prove that a specific event existed at a given moment in time. You don't need all that data, as you can simply fetch the event by its ID and retrieve the sig, ts and so on. You are attesting a reference, not a self-auditable piece of information. But that is just my opinion

2026-03-18 22:08:50 UTC

- reply

What's the rationale to also include the sig? If you would want to keep something you can verify without fetching the event you should also include the pubkey

2026-03-18 17:52:37 UTC

- reply

Why? The event id is already a digest of the whole event

2026-03-18 15:02:17 UTC

Let the attestations flow 🤙
#nevent1q…l44j

2026-03-16 19:10:58 UTC

- reply

Sounds cool, but there will be some friction with a generalized implementation of this on clients i think

2026-03-13 20:00:43 UTC

Dumb relay, dumb client, smart user
#nevent1q…muxw

2026-03-10 21:40:21 UTC

If someone else wonders why nostree.me is down 👇
#nevent1q…a2qn

2026-03-10 21:38:42 UTC

- reply

Hey! Well, long story short, Namecheap suspended my account because they started requiring KYC, and I can't recover it. I'm definitely not going to KYC myself. I started Nostree a long time ago, and it has been working great so far. However, I had no support for it, so I had to put my energy into other projects. The events are still there, and the front end is open source, so anyone could run it. It is also still available at https://nostree.pages.dev/ I don't know what more to do. Maybe I should get another domain, maybe a .xyz and deploy there? What would feel better? Also, NIP-51 changed sometime ago, so how Nostree works is not compliant either... Nostr... Anyways, sorry for that. The fiat world and its demons.

2026-03-05 14:17:08 UTC

- reply

Yes! Man I was thinking about something like this for a while, already in the works, quite similar to what he is describing, same stack, same fundamental ideas, fueled by CVM, we are going to win 💥

2026-03-05 08:37:05 UTC

GM 🌞

2026-02-26 09:14:01 UTC

GM 🌞

2026-02-25 08:09:48 UTC

GM🌞

2026-02-21 21:25:08 UTC

https://image.nostr.build/b824552cac52066767358ec61e35635291fbf234b473aeee153584cbc7e4e0f9.png

2026-02-21 20:22:51 UTC

This one is pretty juicy
https://awesomeagents.ai/news/vibe-coding-security-69-vulnerabilities/
> "Coding agents cannot be trusted to design secure applications," Tenzai concluded. "They seem to be very prone to business logic vulnerabilities. While human developers bring intuitive understanding that helps them grasp how workflows should operate, agents lack this 'common sense.'"
> Databricks' AI Red Team found that self-reflection prompts can improve security by 60-80% for Claude and up to 50% for GPT-4o. The tools can find their own vulnerabilities when asked.
> But that is precisely the problem vibe coding was supposed to solve. The entire premise is that developers - or non-developers - can describe what they want and get working software. Requiring them to also know which security prompts to add defeats the purpose.
#nevent1q…ndcy

2026-02-20 19:47:50 UTC

- reply

Yes, I was asking about the relationship between the provider and the user who declares that provider. When brainstorm generates a new key pair to start publishing TAs for a user, does that new key pair have some context? For example, is there a kind of identifier, like a kind 0 or similar, that indicates 'This public key is the publisher of TAs from the perspective of user_pubkey'? I'm trying to understand if there is a way to determine which provider belongs to whose perspective. I hope this clarifies my question. Let me know if it is still unclear

2026-02-20 11:09:54 UTC

- reply

Dame caña

2026-02-20 09:52:40 UTC

- reply

No idea what synvya is

2026-02-20 09:08:14 UTC

2026-02-20 08:57:16 UTC

- reply

Yea I think relatr and brainstorm are the only ta providers out there (afaik). And brainstorm spins up a new pubkey for each user that signup so there is no single service pubkey. I don't know if there is some way to map the new pubkeys to users, maybe @npub1u5n…ldq3 can help us here

2026-02-20 08:10:04 UTC

- reply

You can reverse lookup these by inspecting 10040 events

2026-02-19 22:25:58 UTC

- reply

:chad_yes: This is very close in spirit to mcp ui

2026-02-19 14:01:23 UTC

- reply

Yes, you could use it as a handshake mechanism. I was thinking in using a progress notification based approach rather than involve other network deps like iroh. But you could experiment with that iroh approach

2026-02-19 13:51:32 UTC

- reply

Yes, relays impose a size limit. Currently, there is no automatic way to handle payloads larger than this limit in CVM. For now, you could implement size aware pagination to avoid hitting relay size limits. Perhaps we can work on a solution to handle this automatically in the SDK

2026-02-19 09:39:55 UTC

- reply

Confusion everywhere

2026-02-18 22:44:01 UTC

- reply

That would be nice. I'll pick Max Power

2026-02-18 22:19:50 UTC

What's a real name anyways? 🤷
#nevent1q…8rja

2026-02-17 14:40:29 UTC

- reply

Nothing, just need some perspective

2026-02-17 08:39:16 UTC

- reply

You are not wrong, I suppose I just need a bit of perspective 🫂

2026-02-17 07:36:01 UTC

GM! Nostr feels a bit depressing lately ngl... Or maybe is just the current situation everywhere, idk, I may take some time to reflect

2026-02-15 10:36:37 UTC

GM🌞

2026-02-14 13:41:55 UTC

- reply

People are starting to use marmot for that, i think is the best option

2026-02-14 12:48:34 UTC

- reply

Nop just discovered

2026-02-14 12:42:39 UTC

- reply

cc @npub1f4u…r407

2026-02-14 12:41:31 UTC

Interesting 👀
https://worldmonitor.app and https://tech.worldmonitor.app

2026-02-14 08:38:51 UTC

- reply

Would be pretty neat if nwc supports subscriptions to lookup payments, so you could subscribe to an invoice and listen for its state changes. There is a notification approach in the nip, but I think is not widely supported.

2026-02-13 16:02:12 UTC

- reply

You are describing mtv tuning XD

2026-02-12 20:41:36 UTC

- reply

Doing my part sir 🫡
#nevent1q…8du5

2026-02-12 15:25:36 UTC

LFG 🚀
#nevent1q…ad8v

2026-02-12 07:48:33 UTC

GM🌞

2026-02-11 17:21:24 UTC

- reply

Not an expert but sounds like a circular dependency

2026-02-11 15:40:26 UTC

- reply

Agents monitoring agents

2026-02-11 12:26:16 UTC

"Nostr: you're probably too lazy for this"
#nevent1q…dfar

2026-02-11 09:42:53 UTC

- reply

GM D!

2026-02-11 08:12:33 UTC

GMMMMMMMCONNEEEECT 🌞

2026-02-10 21:00:52 UTC

- reply

Pretty good! I like the format, the only thing was the volume of the audio, was a bit low.
Also the mcp apps are new extension that allow ui capabilities: https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/
Other related thing with sandboxing stuff im following: https://github.com/anthropic-experimental/sandbox-runtime Thanks by that project i learnt about bubblewrap

2026-02-10 20:24:11 UTC

Meta paradox: the more context they have, the more their performance degrades; it doesn’t matter if they have a 1M token context window, once it exceeds 100 k they normally start to get exponentially confused, especially if that context window contains inconsistencies or repeated failures. The solution? Treat all of this as research, not as a production ready thing
#nevent1q…skku

2026-02-10 20:18:05 UTC

Here its the paradox: Agents need data, so called context; the more data they have, the more useful they are, and vice versa, the less data, the more useless they become. If you want to squeeze all the potential out of them, you have to give them free access to everything. That shouldn't need to be a problem, BUT the reality is you probably will need an upstream provider to do something useful, so you are sold. Sleeping agents are something to be worried about, you are sold. Random prompt injection attacks when fetching a website/skill, you are sold. Other agents that are instructed to scam naive agents, you are sold, or better put, a cryptobragent sold a new scam token to it, and probably paid with your money. We have to be conscious about all of this, not a doomer, just trying to cultivate some perspective to do things right.
#nevent1q…flyr

2026-02-10 10:01:19 UTC

- reply

Never had so many issues before tbh, for one reason or another, I haven't been able to do anything I had in mind with the VPS

2026-02-09 15:08:50 UTC

Were you thinking things are becoming more and more confusing lately? This is just the beginning! Quite unsettling feeling about this, ads need loads of data to be profitable and I know that people are already using llms as psychologists, partners, some are even getting married to them, people are starting to develop emotional relationships with bots, and that's the key to sell you something. Hey, do you feel sad? Sorry to hear that my dear, here you have brand new clothes, or cosmetics that you can buy... Remember, every time you tell something private to gpt you have to know that on the other side is Scam Altman, and he is going to be selling that data to other unknown third parties. Nasty
#nevent1q…ytyh

2026-02-09 14:59:23 UTC

- reply

Oh man thanks god, no more restless nights, i'll be able to sleep again

2026-02-09 12:45:04 UTC

- reply

Yes! The new address yo set works :)

2026-02-09 12:31:12 UTC

- reply

Great! lmk so i can zap you :)

2026-02-09 11:22:25 UTC

- reply

Amazing man! thanks, found it :) BTW tried to zap you, but i get invalid address