I’ve been heads-down on this for months and wanted to finally post here, partly to get eyes on some Waku integration decisions before I commit to them in Phase 1, partly because a few of you have been doing this longer than I have and the cold start question is keeping me up at night.
So — InsightNest. The pitch is a platform for turning community discussion into knowledge artifacts that the community actually owns. Not a forum, not a wiki. The flow is: someone posts a Spark (an idea, an argument, a question worth sitting with), others contribute to it, the community highlights the contributions worth keeping, and eventually someone triggers a Weave that assembles the whole thing into a versioned Insight that lives in a searchable Library. Every Insight carries fractional ownership shares — 40% Spark author, 20% Weave curator, 40% split across accepted contributors. Right now that lives in Postgres. Phase 3 it goes on-chain as ERC-721 on Status Network.
The thing I keep having to explain is the friction. There’s a read timer before the contribution form unlocks. Minimum 50 words per contribution. You can’t post a new Spark until your previous one has at least one contribution on it. People’s first reaction is usually “that’ll kill your DAU” and I get why, but the product thesis is specifically that slow knowledge needs structural incentives for slowness — you can’t slap that on as a feature after you’ve already optimised for engagement. The constraints are load-bearing.
Stack is Elixir / OTP 27 / Phoenix LiveView 1.1, single repo. I was on Go + Next.js earlier this year and switched. Won’t go back. Real-time through PubSub is just built in, no polling, no WebSocket plumbing, no client state management library. For what InsightNest actually needs it’s a much better fit.
Auth is SIWE. I want to be honest about what that means here because I’ve seen projects use it as a Logos alignment claim and I think that’s a stretch — SIWE is an Ethereum standard, it’s not a Logos product. What it gives InsightNest is no centralised identity provider and no personal data in the auth flow. That’s the actual claim and I think it’s worth making on its own terms without overstating it.
The implementation is pure Elixir with no Rust NIFs, which I didn’t plan for — the siwe and siwe_ex hex packages both use Rustler and hit an incompatibility with OTP 27 that I discovered mid-sprint. So Auth.Siwe and Auth.Secp256k1 are hand-rolled using :crypto.mod_pow from OTP stdlib and ex_keccak for keccak-256. It works fine, it’s clean, but it was an annoying detour.
The Logos integration is really two behaviour interfaces, both stubbed from day one so the swap is surgical when the time comes.
MessageBus — NoopMessageBus now, WakuMessageBus in Phase 1. Phoenix PubSub handles the live contribution thread today. The Phase 1 plan is a nwaku sidecar, Elixir backend bridges to it via the REST API, browsers publish contributions directly via js-waku signed with the member’s wallet key. Backend only writes to Postgres at Weave time. I actually think Waku’s ephemerality is a feature here rather than a limitation — the live discussion thread should be transient, the Insight is the thing meant to last. The messaging layer and the storage layer have different jobs.
Publisher — NoopPublisher now, CodexPublisher in Phase 2. codex_cid column already exists on the insights table. Insight body is typed blocks (quote, paragraph, section_header) that serialise cleanly. Content hash assigned at Weave time becomes the CID anchor. Swapping in CodexPublisher is one line in Application.start/2, nothing else touches it.
When Waku node management and Codex upload queuing land as supervised GenServer processes later, the BEAM’s fault isolation and backpressure just handle it. That’s actually a meaningful reason to be on this stack for this kind of multi-component architecture, not just a talking point.
Three things I’d genuinely value input on from people here:
Waku content topic design — I’m going with /insightnest/1/spark/{sparkId}/proto. My worry is fan-out on a popular Spark with heavy subscriber load. Has anyone hit that problem in practice, or know of projects with a similar per-thread subscription pattern that I should look at?
RLN — I want it for spam prevention in Phase 1, wallet addresses as membership credentials, rate-limited per epoch. Is it stable enough to build against now or is the real answer to ship without it and integrate once it’s further along?
Cold start — this is the one I’m most uncertain about. The platform only makes sense if the Library has real Insights in it when people show up. Open registration into an empty Library would be a disaster for the exact audience InsightNest is trying to attract. My current plan is to recruit a founding cohort of around 30 people from PKM communities — Obsidian, Logseq, that world — and seed the Library with completed Insights before anything public-facing goes live. If anyone has seen a different approach work for knowledge platforms specifically, I want to hear it.
Repo is GitHub - Rayleaf-Application/insightnest · GitHub . Single Phoenix LiveView app, behaviour stubs are in lib/insightnest/messaging/ and lib/insightnest/publisher/ if that’s the part most relevant here.
— Dzmitry