Avatar
Gzuuus
40b9c85fffeafc1cadf8c30a4e5c88660ff6e4971a0dc723d5ab674b5e61b451
Forever learning, continuously buidling⚡ cryptoanarchism student https://nostree.me/gzuuus #noderunner#Bitcoin | #technology | #art | #electronics

Yes, I meant that I wasn't imagining them as replacements. Regular gift wraps have their use cases, and ephemeral ones have different use cases, such as real-time secure ephemeral chat.

Regarding relay implementations, I think relays have incentives to respect the ephemeral range since it saves them storage. I've noticed that strfry typically takes 5-10 minutes to evict ephemeral events, while khatru, for example, simply relays them without storing them. This behavior is hardcoded and cannot be modified, which is not good.

How are you handling ephemerals in Orly?

Thinking about gift wraps... Currently, NIP-59 defines kind 1059 for gift wrap, which falls within the range of "regular events," which are supposed to be persisted in relays. It would be interesting to introduce an ephemeral alternative kind for gift wrap events, which would complement the current system. This would allow events that aren't intended for storage in relays to benefit from protection against metadata leakage. One option would be to use a new kind number, such as 21059, for ephemeral gift wraps. This approach could provide an extra layer of privacy because these events would never be stored, only relayed. WDYT?

#dev #nostr

What do you think guys about the new ollama service "turbo"?

You brave dog friend... xD What's the pointless part?

Yes, they are pushing in that direction, but they are mentioning tools and mcp servers different times

Someone knows a good open source screen recorder for Linux that makes easy to do pretty records?

GMonday 🌞😅

Yes, but never finished the unfollow action, you can filter contacts by the last time they published tho. I really need this tool, too, but got distracted by other stuff. I'm going to finish it one of this weekends and deploy it

https://github.com/gzuuus/colorillo-lab

LMAO a friend just shared me this 🤣 it's perfect

Replying to Avatar FLASH

GM

Hey! New logo! Nice 👌

Our society it's really suffering, hyper-individualism has carried us to this. We should reflect about our role in this society, about love and community. Neither the Internet nor any other piece of technology or scientific knowledge can bring us together. And mass communication through social media or teleconferencing can actually leave people feeling more isolated than before. Do you feel lonely? I do

https://www.city-journal.org/article/the-problem-of-hyper-individualism

Replying to Avatar Tim Bouma

I had ChatGPT summarize my research and thinking about message queues into a blog post. Please excuse the clippy tone, there is some useful info here:

Why Nostr Messaging Queues Are More Resistant Than REST APIs

In the world of digital communication, REST APIs have long been the standard for client-server interactions. They’re predictable, easy to integrate, and widely supported. But they also come with structural vulnerabilities that make them brittle in adversarial or decentralized environments.

Enter Nostr—a lightweight, censorship-resistant messaging protocol that’s quietly redefining how we think about message delivery and system resilience. While Nostr is typically seen as a social or publishing protocol, at its core it functions as a kind of message queue—and a remarkably resilient one at that.

🌐 REST APIs: Centralized and Fragile

REST APIs rely on a centralized request-response model. The client initiates communication by sending a request to a known server, which processes it and returns a response. This tightly coupled interaction assumes that the server is online, reachable, authorized, and responsive. In adversarial settings—such as environments with censorship, high latency, or denial-of-service attacks—these assumptions often fail. REST APIs become single points of failure and are easily blocked, rate-limited, or decommissioned.

⚡ Nostr as a Decentralized Messaging Queue

Nostr flips this model on its head by embracing a decentralized, publish-subscribe architecture. Clients send signed events to one or more relays. These relays, which are untrusted and easily replicated, store and forward events to any subscribing clients. This decouples the sender from the recipient and transforms the relay into a kind of stateless message queue. The result is a system where message persistence, delivery, and filtering can all occur independently of centralized control or even direct client-to-client awareness.

Unlike REST APIs, which depend on a single endpoint, Nostr clients can broadcast messages to many relays simultaneously. Subscribers pull data based on their own filters, creating a robust, self-curated stream of relevant content. No single relay needs to be trusted or relied upon, and users can switch or self-host relays with minimal friction. The result is a system that offers inherent resistance to censorship, downtime, and infrastructure fragility.

🔄 Nostr Wallet Connect: Evolving into a Resilient Message Queue Server

One of the most promising evolutions of this architecture is Nostr Wallet Connect. Originally designed as a simple method for wallets and apps to communicate using Nostr events, it has increasingly taken on the characteristics of a resilient message queue server. Instead of relying on tightly integrated APIs, wallets can push and pull payment requests, invoices, and metadata using Nostr events routed through relays. These messages can be signed, broadcast, persisted, or retrieved later—making the system ideal for asynchronous financial messaging. In this role, Nostr Wallet Connect inherits the strengths of Nostr: decentralization, offline tolerance, cryptographic authenticity, and graceful degradation. It opens up the possibility of building a new class of wallet infrastructure where critical financial communication does not rely on any single API endpoint, service provider, or uptime guarantee.

🛡️ Resistance by Design

What makes Nostr fundamentally more resistant than REST APIs is that it doesn’t rely on a single communication path or authority. While REST APIs are tightly coupled and exposed at a known surface—making them ideal targets for censorship or throttling—Nostr clients can communicate with any number of relays, choosing freely from a global pool or self-hosting their own. Authentication in Nostr is cryptographic and embedded in the message itself, not granted by tokens or roles managed by a central server. Messages are not only signed and verifiable, but they can also be replayed or cached across multiple relays. This means that outages, censorship, and infrastructure decay have far less impact.

🧪 Use Cases Beyond Social Media

Although Nostr was born out of the decentralized social media movement, its underlying pub-sub mechanics make it suitable for a much broader range of use cases. Sensor networks can publish telemetry data to relays without relying on a central broker. Secure audit logs can be written once and replicated across multiple untrusted relays. Peer-to-peer communication, even across NATs or unreliable mobile networks, becomes feasible with store-and-forward relay logic. In each case, Nostr acts not just as a messaging layer, but as a resilient, programmable queue infrastructure for decentralized applications.

💡 Conclusion

Nostr isn’t just a protocol for social freedom—it’s a resilient backbone for communication in adversarial, distributed, or degraded environments. By functioning as a lightweight, stateless message queue, it offers a compelling alternative to REST APIs in systems where robustness, decoupling, and decentralization are strategic advantages. As tools like Nostr Wallet Connect mature, the ecosystem is evolving toward a future where even the most sensitive communications—financial transactions, identity negotiations, or supply chain signals—can flow through a network that refuses to be silenced, centralized, or shut down.

In a world increasingly defined by systemic risk and contested control, Nostr’s design isn’t just clever—it’s essential.

Love it 🔥

Replying to Avatar inpc

Hahahe, I couldn't resist to share this https://www.youtube.com/watch?v=9_OIs49m56E

Hmm im not aware. I was thinking in using this from nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx https://github.com/sandwichfarm/encoded-entities#nfeed---filters--relays . So you could encode timelines in nfeed strings. Also i was thinking in adding "presets" to create timelines, like "my friends" or "from follow pack", etc. Ideally all of this is shareable and portable so you can encode your feeds in strings and load them anywhere

Just exploring Applesauce with Svelte. It feels quite powerful. I'm creating a toy client to learn Applesauce and how it integrates with Svelte 5. In the video, you can see me creating multiple timelines with different filters and pulling data from different relays. If you're interested in the codebase: https://github.com/gzuuus/applesauce-svelte

https://video.nostr.build/5e41ee34db7fb36884a63a0fb6fa14d28ea5c24f335bca4ebfef68301eb66cd4.webm

cc nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr

KYC its bad, imposed KYC is evil

Nostr: the universal, permissionless hole-puncher layer of internet. Deal with that

Hey! Yes, you could follow what nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj is recommending. Basically, create a synthetic dataset with two columns: col 1 for questions and col 2 for answers. You can use an LLM to generate this dataset, then embed the answers. I would also recommend using an embedding model like Nomic ( https://ollama.com/library/nomic-embed-text ) since they have an interesting prefix system that generally improves the performance and accuracy of queries ( https://huggingface.co/nomic-ai/nomic-embed-text-v1.5#usage ). I can also share the code for the Beating Heart, a RAG system that ingests MD documents, chunks them semantically, and then embeds them https://github.com/gzuuus/beating-heart-nostr . Additionally, I find the videos by Matt Williams very instructive https://www.youtube.com/watch?v=76EIC_RaDNw . To finalize, I would say that generating a synthetic dataset is not necessarily needed if you embed the data smartly.

Im working on an agentic workflow to generate codebase wikis. I'm looking for some feedback on the generated docs, if you want to help, and have a repo with a codebase that you are familiar with just ping me here or in signal. The idea is to evaluate the resulting docs👌

"True innovation doesn't comes from breaking the rules in a zero-sum game, it comes from breaking free of the zero-sum game entirety, build something small, own it completely, scale it thoughtfully"

https://fountain.fm/episode/U8CYEd78LN9N1UCgqdH2

Introducing Analay, a relay analyzer with a twist. It works by collecting events from the relays it is connected to and inserting them into a DuckDB database. Additionally, it exposes an MCP interface to perform analytic queries on the DuckDB, enabling the use of LLMs to gather insights from the relays. Currently, I am using it on next.dvmcp.fun for the stats page https://next.dvmcp.fun/stats . The license is MIT and the code is available at https://github.com/gzuuus/analay

TBH I created this some time ago but never announced it. Recently, I changed to a 'firehose' approach when collecting events.

Is that not some sort of influence?🤔

Hmm, I'm not sure I understand you clearly in this statement. The number of choices you have doesn't have anything to do with how responsible you are for the choices you make. We could say that when you are more free and responsible, you have more room for choices since you can be responsible for the choices you have, in contrast to a set of given choices. Ultimately, every individual has the possibility to be free in any choice, since even if you have some imposed set of choices, you can freely choose to reject all of them.

It seems that we are talking about different topics. I was discussing individual freedom, while you are addressing collective freedom, which I believe fundamentally relies on free individuals