Idea for the #WoTathon to get the creative juices flowing: WoT for key rotation nostr: View article →

We welcome participants who want to work on WoT but don’t know how. You will almost certainly find someone working on an awesome idea who would love your help! 💜 🫂 View quoted note →

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.

HelixDB Blog - Database Insights & Tutorials

Explore database insights, tutorials, and the latest updates from the HelixDB team.

LemonGraph appears abandoned, no commits in 3 years.

GitHub

GitHub - NationalSecurityAgency/lemongraph: Log-based transactional graph engine

Log-based transactional graph engine. Contribute to NationalSecurityAgency/lemongraph development by creating an account on GitHub.

So would HelixDB be a better choice than neo4j for the Brainstorm rebuild? Maybe, maybe not. Two disadvantages of LMDB: first, LMDB is single-writer by design and cannot be made multi-writer without destroying what makes it awesome. If we want Brainstorm to stream large amounts of data, single-writer is fundamentally bad. Second: LMDB requires manual resizing. This might not actually be too much of a problem for Brainstorm, provided the size of the graph remains sufficiently predictable, which it probably will. (A sudden influx of a million nostr users would be a “champagne problem” 😂) The case for using HelixDB instead of neo4j for the core Brainstorm engine: 1. Reads should be faster, and we’ll be doing a lot of reads. 2. We bite the bullet and accept that we’ll be writing batched data, not streaming, which is probably fine if batches aren’t too far apart. 3. The db size will be relatively predictable, since we’re not ingesting every event, just managing users and their follow/mute/report interrelationships; therefore the LMDB manual resizing problem isn’t an issue. The case against HelixDB: it’s young and there is LOTS of open source tooling built on neo4j that does not (yet?) exist on HelixDB. Cypher, for instance. And will it be abandoned in a few years? Who knows? So I’m not completely sold on HelixDB (LMDB with IFA) over neo4j, but it is a contender. @Jay - thoughts?

Interesting discussion of the challenges of streaming live data into graph databases.

🤝 View quoted note →

If you’re looking for inspiration to join the upcoming 50 million sats WoT-a-thon, listen to this episode of the key pair pod, particularly the nice discussion of web of trust from about 30 min to about 44 min mark. #wotathon View quoted note →

👀 View quoted note →

#wotathon Bullish about web of trust! View quoted note →

Gary have you used neo4j? I see it mentioned in this article. At @nosfabrica we’re looking at building a nostr graph database relay and neo4j is our top contender.

To bring WoT to nostr, we need two primitives: 1. a way to ask questions 2. a way to answer them or, stated another way: 1. a way to represent information 2. a way to curate information or, stated another way: 1. the concept graph 2. the grapevine or, stated another way: 1. Decentralized Lists (Custom NIP) 2. NIP-85: Trusted Assertions or, stated another way: 1. math 2. physics

NostrHub

NostrHub | Discover and Publish NIPs

Explore official NIPs and publish your own custom NIPs on NostrHub.

GM nostr! ☕️ ⛅️