We have received very good feedback from clients across the enterprise and consumer segments, they really like it.

Comments URL: https://news.ycombinator.com/item?id=49305100

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49161983

Points: 1

# Comments: 0

We build agents in Elixir. We kept running into the same issue and found there is no observability for agentic systems.

We decided to take the best aspects of LangChain, LangGraph, and DeepAgents and put them into Elixir.

BeamWeaver comes with an OTP-native design and: - agents and tool calling - graph workflows - checkpoints and resumable execution - memory stores - retries, fallbacks, interrupts, and human review - typed streaming events - provider adapters for OpenAI, Anthropic, Google Gemini, xAI, and Moonshot/Kimi - fake/replay models for deterministic tests

We're also building observability on top of it through WeaveScope, which we'll release very soon.

BeamWeaver gives Elixir teams the tools needed to build advanced agentic systems without pushing the hard parts into Python services.

Comments URL: https://news.ycombinator.com/item?id=48594068

Points: 3

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=48009364

Points: 2

# Comments: 0

We built NoxScan as a side product to solve our own problem.

Backstory: we're SOC 2 compliant, which means we have to run continuous vulnerability scanning on our own infrastructure. We were paying €700/mo to a well known scanner for 50+ IPs. For that money we got full port coverage, but scans ran once a month on top of basic Nmap. No service enrichment, no smart filtering. Just raw output that we had to triage by hand. Their cheaper tiers were worse: capped at the top 1,000 ports.

What we actually wanted was three things: full 65,535 port coverage, daily scans instead of monthly, and output that a human didn't have to hand filter. That combination didn't seem to exist at a price that made sense for our size, so we started building it ourselves. After running it internally for a while we realized other small SOC 2 and ISO 27001 shops almost certainly have the same pain, so here we are.

We started with masscan. It's the obvious choice for sweeping 65K ports across a lot of hosts. It's fast, but under load it drops open ports, and context switching eats into throughput when you're trying to push line rate on cheap hardware.

Then we read c3l3si4n's Phrack article on high performance scanning with AF_XDP (Phrack #72, article 5) and it was pretty much exactly what we needed. The short version: attach an eBPF program to the NIC's XDP hook, set up a shared UMEM region with a four ring mailbox (RX, TX, FILL, COMPLETION), and you get zero copy packet I/O between userspace and the driver with almost no syscall overhead. The eBPF side handles SYN/ACK matching at the XDP hook, so we never push every response up to userspace. Rate limiting is done per destination ASN instead of globally, otherwise a few large targets will starve everything else. For now we run masscan and our AF_XDP scanner in parallel. Masscan is still the battle tested workhorse doing the bulk of production scans, and we cross check its findings against our AF_XDP path on every run. The Phrack benchmarks line up with what we see on our own infra: AF_XDP is faster and more accurate in dense scans against a single host (c3l3si4n measured ~1.3s vs masscan's ~2s on a full 65,535 port scan, and masscan dropped ports at that rate while AF_XDP didn't). Once we're confident our AF_XDP path is stable across the mix of NICs and kernels our customers actually run, we'll switch to it fully. Right now the redundancy is worth the extra compute.

Port open/closed on its own is almost useless. What you actually want to know is "what's running on that port and which version is it." For that we use ZGrab2 with a set of custom probes we wrote for the services we care about: HTTP and TLS of course, but also etcd, Consul, Prometheus, unauthenticated Redis, exposed Docker daemons, and similar. ZGrab2 is underrated. It's pretty much what you'd build yourself if you had to fingerprint thousands of services per second, and the output format is cleaner than Nmap's NSE.

Once we know what's running, we enrich it with known CVEs and assign severity. Web services also go through Nuclei. Nuclei is the best thing that happened to vuln scanning in years. Compared to OpenVAS or ZAP, which will happily flag every missing X-Content-Type-Options header as a vulnerability, Nuclei's templates are version aware and the signal to noise ratio is much better.

Even Nuclei produces noise in aggregate. We route anonymized findings through an LLM that cross references against the NVD CVE database, deduplicates related findings, and assigns severity based on actual exploitability in context (exposed to the internet vs. behind auth vs. requires specific config to trigger).

Last piece: because we're SOC 2 compliant ourselves, the PDF reports are in the exact format our auditor asked for. CC7.1 mapping, timestamps, scope definitions, remediation tracking. Basically the report we wish our old scanner had been producing.

HN folks can use LAUNCH30 code during checkout.

Comments URL: https://news.ycombinator.com/item?id=47703319

Points: 1

# Comments: 0

FBI and Europol will work with the same forest (unless they are using on-premise setup), but with different "patches".

There are many possible optimizations, but they’re all highly specific to the particular problems you’re trying to solve.

A linked list can be split in two in O(1). When it comes to updating the roots for all the removed nodes, there is no easy way out, but luckily:

- This process can be parallelized.

- It could be done just once for multiple clustering changes.

- This is a multi-level disjoint set, not all the levels or sub-clusters are usually affected. Upper level clustering, which is based on lower confidence level, can be rebuilt more easily.

If by undoing you mean reverting the changes, we don’t use a persistent data structure. When we need historical clustering, we use a patched forest with concurrent hash maps to track the changes, and then apply or throw them away.

We use a single instance for all clients, but when one CFD server processes new block data, it becomes fully blocked for read access. To solve this, we built a smart load balancer that redirects user requests to a secondary CFD server. This ensures there's always at least two servers running, and more if we need additional throughput.

That said, we absolutely believe that blockchain and cryptocurrency will shape the future of the financial system. When you look beyond the noise of scam tokens, speculative NFTs, and high-profile scandals, there is significant and meaningful financial innovation happening. This extends beyond DeFi to include the tokenization of RWA, where major institutions like BlackRock and JPM Chase are actively exploring and implementing blockchain-based solutions. Numerous projects are driving real progress, and there’s a slow but steady movement toward a more decentralized and transparent financial ecosystem.

We’re the core engineering team at Caudena (which is used globally by investigative and intelligence agencies, including: Europol, Interpol, BKA, DHS, IRS-CI, FBI, NPA and others), and we just released the technical details behind Prism - our real-time, in-memory C++ database for blockchain analysis.

To tackle the massive scale and complexity of blockchain data, we had to get creative with low-level engineering:

- We utilize barebone servers with 2TB RAM and 48 Cores.

- Implemented lock-free concurrent data structures

- Developed a custom memory management system

- Leveraging CPU-level vectorization

- Built a custom in-memory columnar/graph database from scratch

We’d love to AMA about:

- the engineering choices we made

- crazy optimizations that paid off

- pitfalls we hit

Ask us anything about scaling, memory trade-offs, building real-time analytics on immutable data, or the crypto-forensics space.

Looking forward to a great convo!

Comments URL: https://news.ycombinator.com/item?id=44313107

Points: 76

# Comments: 68