No more GitHub — publish your git repos on Blossom:

---

cargo install hashtree-cli

cd your_repo

# self is an auto-generated nostr identity (nsec) in ~/.hashtree/keys

git remote add htree htree://self/your_repo

git push htree master

clone:

git clone htree://npub1xndmdgymsf4a34rzr7346vp8qcptxf75pjqweh8naa8rklgxpfqqmfjtce/hashtree-rs

In December 2023, a U.S. Senate investigation revealed that governments worldwide have been demanding push notification records from Apple and Google to surveil smartphone users, including tying anonymous messaging accounts to real identities. For years, privacy engineers dismissed this attack vector as unsolvable, since mobile operating systems require routing through platform servers.

MIP-05, a new specification for the Marmot Protocol, proves them wrong: by encrypting device tokens with probabilistic encryption and delivering notifications through gift-wrapped Nostr events, it makes push notifications functionally anonymous. If you care about private communication, this is the specification you need to understand.

nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk added follow/social graph indexes to #nostrdb 🤯. Damus clients getting accurate web of trust graphs soon 👀

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 nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk 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 nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr ) 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 nostr:npub1healthsx3swcgtknff7zwpg8aj2q7h49zecul5rz490f6z2zp59qnfvp8p , 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.

If anyone wants to try out a GPU (CUDA) based npub miner I put one together and pushed to GitHub.

Sophisticated WoT will require queries with many traversals, and IFA (index free adjacency, the defining characteristic of *native* graph dbs) helps with multi-traversal queries.

LMDB does not inherently boast IFA. But is it possible to build it in? Can we marry the lightning speed of LMDB with the advantages of IFA? Yes.

It turns out there are at least two native graph databases built on LMDB: HelixDB and LemonGraph.

HelixDB is new (2025) but supported by y-Combinator and boasts some good benchmarks.