Gzuuus

cashuBpGFteCJodHRwczovL21pbnQubWluaWJpdHMuY2FzaC9CaXRjb2luYXVjc2F0YXSBomFpSABQBVDwSUFGYXCFpGFhCGFzeEBmZDI1NjI3Yzc5NmVmNWU3MzNhMGM0ZjNiNDkzOGY3ZmZlOWU5ZDUwZTFlNDI1MTllZTdkYmQ2YWJhNDg2ZTQ0YWNYIQKuaUgOcP8Pl-G1OKjdXXl7ACQ3lwMy5t-adbhd9TbtWmFko2FlWCD-6vL05urKzbCsNXdxhOwoAt3k3MFUhKCzMb6UUWz2vmFzWCCmMEYhQjkarS6oOAlkxz3oyiGru895sH0C6AxJfrmTUmFyWCBbA8X8nFMa-M9BzJ9ynGy25q01pfSEtvL13iGC43_FG6RhYQJhc3hAMGE3Yzk0ZmE1MmZlYjk3ODRhODQyNmJhYzkwODgwZDUzNGExMGNlOTcwNWJhYzgxMjA2ZGZiNTM2MmE2MWNlZGFjWCEDZ-8_Wx7fb4D6_Z0at4-hweaFrH0jW3C9mAUcFPP55ithZKNhZVggw3cVr1QwqxpyP_X4iPUtiPVUk2NoKN0BQMyUNfb3cKRhc1ggD8WLlJjakytbpiug0hnWA2atV0mMp_96w-ErOSjgKI5hclgginFx-grhFl8gTzIJxpv-ovCN4pJ8gkLu0TPv39GYRv6jYWEBYXN4QDMyOTVjZWFlNTZlODVhZDkyYTlmYzUzMTUwNTBiMjg4ZjUyZGEzNzI5YzEwMjk0NDNmMDE2ZGRiYmQ0YzRlZjJhY1ghAkCLWueFFmhCKVPUXqP0HYpzQxq4WWiRYU9kS2sacn2bo2FhAWFzeEAyZGE2ZTNlYjg0NDU3NDUwYzhkNzg4NTRhZWU0YTNhNjZlNjFmN2QyYWU1N2FiYTBkNmIyZTc4Y2ViYmMyMmY1YWNYIQMW4-Nrv-bydD0StYw5jACTH5gvbDBr5QVwnmQac7GR_qRhYQFhc3hAN2VjMDViNjgyYmIwOTg1YTgwNTYzYmI1ZGFjNWU1MjA5Y2M5NGMzOGU0ZjcxZThjYTE0NmQ3NGZhZjY3NzQ3N2FjWCEDUMknjNYqUWfil1fitSe254Y6lwZfwKtIFTEVdBnEehJhZKNhZVggy_vqbVipZuf9Xgp8DyfiR6WTB6rbMuNJYpw-kyoNiW5hc1ggt-ZW4T23Uq6wA6lrRCMHIBXDEVy3oTdj-hOSbpktr_hhclggZhiR3Kekgfaz59g85G6D7rkb9tmKaNpU2FLAhfl0PcdhZHJTZW50IGZyb20gTWluaWJpdHM

2025-11-23 16:36:46 UTC

https://image.nostr.build/31c0e6a0d2f164f1429c7fff20537e59006d051b04984a0f36a48f57aca6236c.jpg
I'm excited to introduce Nostr Social Duck, or just NSD, a library I've been crafting over the last two weekends that brings sophisticated social graph analysis, even to hardware that doesn't have the luxury of abundant memory. This library leverages DuckDB to perform graph operations over Nostr social graphs built from Contact List events (kind 3), and it's designed to run on all sorts of hardware, from low-end devices to powerful servers.
The inspiration came from limitations I encountered with @npub1g53…drvk excellent nostr-social-graph library. While powerful, loading entire social graphs into memory becomes challenging, specially on resource constrained devices like older computers, mobile devices, Raspberry Pis, and similar environments. Once the graph grows, memory constraints can cause performance issues or outright failures.
The recent launch of Relatr and its inclusion in the Umbrel community store (thanks to @npub1ye5…knpr ) got us thinking: how could we enable anyone to run this without being constrained by their hardware? Since disk storage is cheaper than memory, how we can balance the tradeoffs 🤔... That's when DuckDB emerged as the perfect solution
DuckDB is quite a cool piece of software that's been around for some time with an amazing team committed to open source. It's an embedded, in-process database designed to run on all sorts of hardware. What makes DuckDB particularly compelling for our use case are its advanced memory management capabilities. When complex queries require more memory than available, DuckDB automatically spills to disk, ensuring queries complete even if there is not enough memory, rather than crash. No memory, no problem.
This feature alone makes DuckDB a strong choice, but there's more. Its advanced analytic SQL capabilities make graph analysis operations possible and performant. NSD already provides methods to get the shortest distance between pubkeys, along with a complementary method to find the shortest path that returns both the path and distance. You can define a root pubkey which creates a temporary table with all distances precomputed, making subsequent queries much faster.
The library also includes methods for social graph analysis, like, get the degree of a pubkey, how many inbound and outbound connections it has, which helps determine the weight of a pubkey in the graph. There are convenient methods to check if one pubkey follows another or if two pubkeys are mutual follows. As well thanks to DuckDB in the future we could use parquet files to distribute social graph data. You can find all the details in the repo.
We're currently refactoring Relatr to use NSD, and the results are impressive. By replacing the previous combination of nostr-social-graph library and SQLite database with DuckDB and NSD, we've eliminated the inefficiencies of having separate data sources. Complex queries like profile search now benefit from analytical SQL directly in the search algorithm, reducing data transfer between the program and database and returning more relevant results efficiently.
I did some naive benchmarking to understand how it performs compared to the nostr-social-graph library, and it behaves pretty well. Both libraries are pretty close in performance when there's a root pubkey set in NSD.
This effort aligns with the ongoing #WoTathon organized by @npub1hea…vp8p , as we believe NSD provides fundamental primitives for performing graph operations on everyone's hardware without sacrificing simplicity of use and deployment.
The library is available now and can be integrated into any js project:
```bash
bun add nostr-social-duck
# or
npm install nostr-social-duck
```
As we finalize the Relatr refactor, we'll share detailed insights about the improvements and performance gains. The combination of Nostr's decentralized social protocol with DuckDB's efficient analytics creates a powerful foundation for the next generation of social applications.
The library's repository: https://github.com/gzuuus/nostr-social-duck
Related DuckDD's blog posts:
- https://duckdb.org/2025/01/17/raspberryi-pi-tpch
- https://duckdb.org/2024/03/29/external-aggregation
- https://duckdb.org/2024/12/06/duckdb-tpch-sf100-on-mobile
If you like the project please consider supporting our work by zapping, or contribute to it's development

2025-11-18 21:10:04 UTC

- reply

Maybe @nprofile…ympz is interested?

2025-11-17 09:14:53 UTC

GM🌧️

2025-11-14 13:46:14 UTC

- reply

How are you doing this? I feel curious, I've already done some testing on streams over CVM, and it works out of the box using MCP notifications or resource subscription, as well as with the possibility of bidirectional communications between the server and client

2025-11-13 17:56:43 UTC

- reply

That's already possible, it's the whole idea behind CVM and Relatr. You can easily integrate it into any Nostr client without needing a service website. All you have to do is call the service using its pubkey and perform a search or look up an individual pubkey. So, if a Nostr client integrates this feature, users could specify their own instance for a personalized Web of Trust computation, or use the default Relatr service, or any other public instance. The only difference is the pubkey of the service. I've already heard from people who are implementing it in their clients.

2025-11-13 09:48:59 UTC

- reply

Gm🦧

2025-11-13 09:41:07 UTC

- reply

Yes, you are right. The search functionality still needs some tuning to give better results. These accounts appear if you increment the limit of the filter, but you are right, they should appear at the top. Just need to tweak some knobs, and should be better

2025-11-13 09:16:52 UTC

- reply

Probably unrelated
#nevent1q…8vtl

2025-11-12 21:42:29 UTC

- reply

Just jumping in. Currently search results that exactly match the query get a slight boost to balance things out. But remember that relatr is about the point of view of the source pubkey, so for the same query, you can obtain different rankings depending on the source pubkey used for the measurement

2025-11-12 09:04:18 UTC

- reply

GM flash ⚡

2025-11-12 09:03:56 UTC

- reply

GM🌞

2025-11-12 08:24:02 UTC

GM🌞

2025-11-09 09:24:39 UTC

GM🌞

2025-11-08 09:53:46 UTC

- reply

GM flash 🫂

2025-11-08 09:25:15 UTC

- reply

Hahaha I thought the same... Probably vibe coded

2025-11-06 13:19:12 UTC

Mynymbox is good... Until you have to deal with the service assistance

2025-11-05 07:36:36 UTC

- reply

This 👌

2025-11-03 13:13:45 UTC

- reply

Appreciated your thoughts! Thanks. Yes, about the 'send cashu' vs 'create token,' you might be right. 'Send cashu' implies creating and sending, so it should be complemented with a sending action, while 'create' is the pure act of creating the token, which can then be sent manually. That makes sense; I'll change it.

2025-11-03 09:21:28 UTC

- How is your #nutvember going?
- Already doing well, putting together a wallet that's just right 😎
https://video.nostr.build/7a138c243c0f796943fdd1d0232001e885e272f9cf6838fd5cbacbd2add0fb5c.mp4

2025-11-02 09:34:36 UTC

- reply

Hahaha my god

2025-10-31 07:37:41 UTC

GM🌞 what can you see herr?
https://nostr.download/5f852f20fb97ee3b4cfe2145a8f8de70f0e155474557cb0091838d4020d9de43.jpg

2025-10-16 08:59:23 UTC

- reply

Mute notifications movement going on rn. In nostr we don't have them (not by default at least) and it's not a bug, it's a feature 🤙
#nevent1q…r2gx

2025-10-15 21:32:28 UTC

- reply

PROTECT YOUR ATTENTION AT ALL COST specially for things you care about
#nevent1q…zme6

2025-10-15 14:21:49 UTC

It's incredible how now days any conversation or discussion can be interrupted by a notification. You could be having an important discussion, and then a notification rings on a phone. With a high likelihood of this happening, the conversation or discussion gets hijacked and distorted, and it just vanishes as our attention wanes and jumps between stimuli. This is destroying relationships between people, and not just between people, but also within ourselves. It's incredible that this happens so frequently. Your priorities just switch between what is happening and this random thing that makes your phone ring. To be honest, it's pathetic, and just demonstrate how hackable our brains are... I hope we realize how dangerous this is.

2025-10-13 07:57:28 UTC

GM🌞

2025-10-10 09:00:08 UTC

- reply

I did this one sometime ago, its a relay that can sign notes, the idea is that you can create "subkeys" in the relay dashboard and use them in any client connected to the relay and then get the notes signed with the main key https://github.com/gzuuus/mimoty

2025-10-06 07:44:16 UTC

GM 🌞
https://nostr.download/309c4ab3ed329168fed819e886d03fbb3d6cb77d51b42174b3688f491a07009c.jpg

2025-09-28 08:00:00 UTC

- reply

The og
#nevent1q…92lu

2025-09-28 07:38:45 UTC

- reply

Cool! I'll avoid to watch the trailer and wait until the film (trailers are shitcoins)

2025-09-28 07:29:58 UTC

GM is GFY 🌞

2025-09-27 09:59:58 UTC

Just a retired in a field
https://nostr.download/7cca706a7a022ce1414d964e6c85288094231dee93886368bd4851db33acbbaa.jpg

2025-09-26 11:34:19 UTC

- reply

Today is shipping day arr

2025-09-26 07:47:03 UTC

GM 🌞
https://nostr.download/50853ef54b719afb01130b8b7055a0e8b7a7eb417da1427fc867e0c40b4bbb30.jpg

2025-09-25 21:45:39 UTC

- reply

It always does, it's a quite powerful duck👌

2025-09-25 20:53:02 UTC

- reply

🦆🍀🚀🚀

2025-09-25 08:32:08 UTC

- reply

GM 🫶

2025-09-25 07:26:03 UTC

- reply

Gm frann :)

2025-09-25 07:19:15 UTC

GM🌞

2025-09-25 07:19:01 UTC

- reply

What I've lost? 👀

2025-09-24 19:32:54 UTC

- reply

and nutoff 🤟

2025-09-24 14:25:09 UTC

- reply

Yes, I understand. I'm also not engaging in politics within the NIPs repo. The interoperability we have today is the result of blood, tears, and sweat, the hard work, dedication, and passion of developers who truly believe in what they are doing. However, this is not due to clear guidelines or good support for interoperability. The fact that Nostr is relatively easy to reverse engineer has facilitated this interoperability, but it is not because the protocol is well-specified.
I see this as a potential vector of attack that could lead to the protocol being captured. You cannot combat this if you are merely ranting and confused (which, incidentally, is the name of the Nostr Telegram groupgroup xD). The direction I'm pointing towards in the article is simply a suggestion on how we can improve this situation. We need cleaner and clearer specifications and processes. As Nostr grows, the effort required to maintain interoperability will inevitably increase.

2025-09-24 14:12:18 UTC

- reply

I was testing https://github.com/musistudio/claude-code-router, which essentially allows you to use any llm from different providers with Claude code. I've also noticed that Codex lets you define the base URL, so theoretically, you could use any other provider, although I haven't tested this yet. The key point to understand is that different llms can be used as agents within these agentic coding CLIs. Choose the one that integrates better with your IDE and experiment with different LLMs to find what works better for you

2025-09-24 13:43:36 UTC

- reply

Yay! The duck of luck and I wish you good luck and a high grade on your exam 🦆🍀

2025-09-24 13:29:07 UTC

World of sheep, government of wolves

2025-09-24 12:42:23 UTC

- reply

GM! Sleepy?

2025-09-24 07:42:17 UTC

- reply

Good mantra xD

2025-09-24 07:35:55 UTC

GM🌞

2025-09-23 14:29:06 UTC

Be consequent; you are the only one responsible for your acts and decisions, no one else. That means that in essence, you are free

2025-09-23 09:45:42 UTC

- reply

Last windows I touched as daily driver was XP

2025-09-23 08:18:11 UTC

- reply

@nprofile…jq5m

2025-09-23 07:33:30 UTC

GM🌞

2025-09-21 17:33:57 UTC

- reply

That's definitely true; you are where everything starts, but we need collaboration

2025-09-21 17:26:39 UTC

- reply

Some people are awakening. The majority is procrastinating

2025-09-21 14:36:15 UTC

- reply

Oh man it would be amazing if you could experiment and report back on the effectiveness of these defensive techniques. It could be huge in defending against new, modern threats.

2025-09-21 14:31:35 UTC

https://www.youtube.com/watch?v=cTblxWlbcfQ

2025-09-21 14:18:05 UTC

La letra de esta canción... Escucha con atención
https://www.youtube.com/watch?v=mJ3_JHXEWlY

2025-09-21 14:17:09 UTC

- reply

Would be amazing if you find an effective way to stop ddos based on that

2025-09-21 14:09:41 UTC

The world is going nuts, period.

2025-09-21 10:38:15 UTC

- reply

Why does your cat look so sad?

2025-09-21 10:37:05 UTC

https://github.com/gensecaihq
AI defending against AI. We are living in the future

2025-09-21 09:08:12 UTC

GM🌞

2025-09-21 08:11:10 UTC

- reply

GM🌞

2025-09-20 10:08:35 UTC

Hahaha, man, that demo had more failures than all the soveng demos together. Epic https://www.youtube.com/watch?v=wsHt2YReQzA

2025-09-19 12:06:50 UTC

- reply

Virtually 0 bugs

2025-09-19 11:42:28 UTC

https://youtube.com/watch?v=iamEJE1cC14

2025-09-19 11:18:23 UTC

- reply

Thanks for your comment! I believe that any protocol requires a specification; otherwise, it's not a protocol, but rather a mess. You're right that what you're mentioning could happen: different specifications for the same use case competing and eventually needing to be interoperable through bridges, adapters, or translation layers. If Nostr ends up in that situation, I would consider it a failure. Interoperability is king

2025-09-19 11:13:32 UTC

- reply

I may have an idea for this 🤔

2025-09-19 11:12:51 UTC

- reply

👌

2025-09-19 11:11:32 UTC

- reply

Recommended
#nevent1q…r202

2025-09-19 10:22:39 UTC

- reply

Gm 🫶

2025-09-19 09:01:34 UTC

- reply

GM 🌞
#nevent1q…jpem

2025-09-18 21:26:06 UTC

- reply

Funchal? 👀

2025-09-18 18:44:38 UTC

Tomorrow is demo day #soveng
https://nostr.download/d57fccc4b7ced208ab060f01de6883e967f55fd571a23e76ae3e24524a4db301.jpg

2025-09-18 16:33:34 UTC

- reply

Hijacking your attention since 2005

2025-09-18 13:50:19 UTC

- reply

Gm 🌞

2025-09-18 09:51:02 UTC

- reply

Ok, seems we touched a nerve. We can agree to disagree; that’s fine. My argument in the article is that Nostr needs a better governance model to foster collaboration and provide clarity for newcomers. I mentioned Fiatjaf’s article because it’s another example showing that the community already recognizes problems with the current model.
From my point of view, Nostr needs clearer guidelines and specifications if it expects to be interoperable within a wider ecosystem. The “wild west” approach can remain for experimentation, but that’s why I mentioned the dual-layer approach used in Lightning (BOLTs and BLIPs). I think a similar approach could help people and communities feel comfortable building on Nostr and make it easier for newcomers to participate. It would also help defend and harden the protocol against political and influence attacks, something I think is quite feasible. In fact, rejecting any governance model increases the chance of capture by an organization that can exploit the general confusion and discomfort about “how the hell do I build on Nostr” without having to dig through hundred of unstructured threads, discussions, issues, and PRs to just grasp the rationale and philosophy behind the protocol.
If you read my article with fresh eyes rather than getting triggered, you’ll see that my proposals and key guidelines are intended to improve the clarity of the spec documents, restore attribution to organically create reputation, and define clear lifecycles for new proposals that expect to be interoperable. I’m not advocating for a “Nostr steering council” or anything like that. I mention these projects (peps, rfcs) because they effectively manage large ecosystems; even if Nostr isn’t that large yet, it will need some structures if we don’t want it to collapse as it grows.
Also, Conway’s Law describes a symptom of capture: complex projects tend to take the shape of the organizational structures that design them. This ties into the “embrace, extend, extinguish” methodology I mention in the article.
In short: it’s not about bureaucracy, it’s about resilience.
PS: LNURL specs are confusing too

2025-09-18 07:57:22 UTC

- reply

Haha mas o menos 😅

2025-09-18 07:36:52 UTC

- reply

GM🌞

2025-09-17 21:31:34 UTC

- reply

GN🌝

2025-09-17 21:26:23 UTC

- reply

Death by thousand cuts

2025-09-17 16:20:28 UTC

- reply

Agree. They can be different type of specifications for relays and clients

2025-09-17 16:17:37 UTC

- reply

I think you are missing the point. I don't know whether it's because you didn't fully read the article, you weren't paying attention while reading, or something triggered you. But I'm not talking about formalizing Nostr development, I'm talking about governance and a process to propose new interoperability standards. If you read carefully, you'll notice that I treat that distinction with care. No one can impose anything on Nostr, no top‑down imposition; that will never change, but it's different when we expect interoperability: that's when we need a more robust framework.
It also doesn't matter whether it's about money. Some of the projects with more robust and successful governance that I mention in the article (Py PEPs, Rust RFCs) are unrelated to money, and yet they designed a pretty good way to manage their project with thousand and developers, stake holders and participants, so I don't understand your rationale there.
Anyway, I'm just reflecting on how weak governance can be an attack vector, and how better-designed guidelines and processes can help us be more resilient in the long term.

2025-09-17 12:43:09 UTC

Almost two weeks ago I began working on this article. It grew out of conversations with several people involved in Nostr and Open source, and from the realization that a very informal specification process is indeed a vulnerability. I would love to hear your thoughts.
Thanks also to everyone who provided feedback while I was writing, and to the participants in #soveng for sharing helpful feedback and resources I didn’t know about, they made the article much stronger.
#naddr1qv…4ag2

2025-09-16 21:32:05 UTC

- reply

Bump feast

2025-09-16 18:31:28 UTC

NOSTB - Notes and other stuff transmitted by banks

2025-09-16 07:54:03 UTC

Hahaha nice way to raise awareness
https://www.gadgetreview.com/massive-attack-turns-concert-into-facial-recognition-surveillance-experiment

2025-09-16 07:47:51 UTC

- reply

True
#nevent1q…8h55

2025-09-16 07:17:35 UTC

- reply

GM 🌞

2025-09-16 07:09:41 UTC

- reply

Screens are shitcoins

2025-09-15 15:55:29 UTC

https://youtube.com/watch?v=JxfuQ8a5gwA

2025-09-15 13:15:52 UTC

- reply

Yes, basically, the local Cashu wallet can be used remotely. The wallet can run anywhere and use Nostr relays for hole punching. From it, you can designate allowed keys that have permissions to call all the methods of the wallet, while the rest of the non-allowed pubkeys can only call some public methods (make_invoice, get_info, lookup_invoice). The HTTP server is just a public service that translates between LNURL and MCP/ContextVM. So yes, you can be nomadic and run the wallet anywhere. While the wallet is running, it is reachable remotely. I think a cool use case is for spontaneous markets where all merchants can receive payments automatically and without hassle. Of course, anyone can use this to spin up a wallet very easily

2025-09-15 11:05:33 UTC

This is a diagram showing how the different parts of nutoff work together.
https://image.nostr.build/25928ecefffe5a12164c46b929b53913ddb5561c8160e204a22543d404caec3e.png
#nevent1q…qwf3

2025-09-15 07:14:07 UTC

- reply

Yes, the reason was that nostr-tools lib broke in an update.

2025-09-15 07:12:03 UTC

GM 🌞

2025-09-15 07:06:55 UTC

- reply

Gm Franny :)