👀 View quoted note →

WoT should be *personalized* and *portable*. Those features should be our focus. Contextual comes next. #wotathon

Any devs looking for ideas for the #wotathon ? Integrate trust metrics from a WoT Service Provider ( #brainstorm, @Vertex, #relatr, hopefully more WoT SPs to come!) into your client! There will be more than one way to do that, but for many use cases, Trusted Assertions will be your lowest hanging fruit. View quoted note →

#wotathon Build a WoT primitive: decentralized lists View quoted note →

#wotathon WoT for key rotation View quoted note →

👀 View quoted note →

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.