Feed aggregator

Hey HN,We started a project on Feb 11th aiming to build the fastest, most robust secp256k1 library out there, leveraging modern CPU features and low-level assembly. It's called UltrafastSecp256k1, and after just 11 days, we've achieved some pretty aggressive benchmarks and platform coverage.The Problem We're Solving: Existing secp256k1 implementations (like libsecp256k1 from Bitcoin Core) are highly optimized, but often leave performance on the table for specific, newer hardware features or cross-platform needs. We saw an opportunity to push this further, particularly in constant-time operations and diverse architectures.What We've Done (The "How"):Deep Assembly & Hardware Intrinsics: Hand-tuned $5 \times 52$ field representation for x86-64 and ARM64. This directly bypasses higher-level abstractions to hit peak performance.Constant-Time by Design: Every critical path is designed to be constant-time, mitigating side-channel attacks. We even achieved a +51% speedup on $k \times G$ (generator scalar multiplication) for x86-64 in constant-time, compared to libsecp256k1's standard implementation.Cross-Platform & Embedded: We've expanded support rapidly: from x86/ARM64 (including Android) to ESP32-S3, and we're starting RISC-V (Milk-V Mars) next.Broad Language Bindings: The library is accessible from 12+ languages (Rust, Go, Python, Swift, Dart, Java/Kotlin, Node.js via NPM, C# via NuGet, etc.), making it easy to integrate into almost any project.Why we're sharing: We've seen over 5,000 clones in 11 days, and the project is rapidly evolving. We're looking for feedback from the HN community on our low-level optimizations, especially the constant-time implementation details and platform-specific assembly.Relevant Benchmarks: (შეგიძლია მოგვიანებით ჩასვა კონკრეტული რიცხვები, როცა განაახლებ)x86-64 ($k \times G$ CT): Ultrafast: 10.4µs vs libsecp: 15.7µs (+51% faster)ARM64 ($field\_mul$): Ultrafast: 0.083µs vs libsecp: 0.098µs (+18% faster)ARM64 ($field\_inv$): Ultrafast: 4.47µs vs libsecp: 5.21µs (+17% faster)We believe that UltrafastSecp256k1 can become a critical component for high-performance cryptographic needs in various applications, from blockchain nodes to secure IoT devices.GitHub Repo: https://github.com/shrec/UltrafastSecp256k1Changelog: https://github.com/shrec/UltrafastSecp256k1/blob/main/CHANGELOG.mdLooking forward to your insights and constructive criticism!

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

Points: 1

# Comments: 0

Article URL: https://github.com/madzarm/ccsearch

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

Points: 1

# Comments: 1

Article URL: https://app.ilograph.com/demo.ilograph.Ilograph/__overview

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

Points: 1

# Comments: 0

Article URL: https://alyph.app

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

Points: 1

# Comments: 0

A free Bionic Reading extension that helps with ADHD and reading speed. It processes the text entirely locally.

License: MIT

Chrome Web Store: https://chromewebstore.google.com/detail/cllpokdpfkelkceomncfgebkegnjepdc?utm_source=item-share-cb

Source Code: https://github.com/the0cp/citius-vide

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

Points: 1

# Comments: 0

Article URL: https://enombic.com/make-an-ideal-man

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

Points: 1

# Comments: 0

I built Orvia — a real-time, temporary collaboration room for instant conversations and fast media sharing.

~200 users have tried it so far. The main feedback wasn’t about missing features, but UX:

UI felt too “hacker tool”

Empty rooms felt awkward

Too many visible actions

So I redesigned it to feel calmer and frictionless.

The idea is simple: Create a room → Share the link → Talk & share files → Leave → Room disappears.

No accounts. No setup. No stored history.

It’s built for quick, private, zero-overhead collaboration — not persistent communities.

Would really appreciate honest feedback on UX and real-time experience or any missing feature.

url - https://orvia.live

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

Points: 1

# Comments: 1

Article URL: https://theguildenet.blogspot.com/2026/02/what-four-astronauts-could-find-as-they.html

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

Points: 1

# Comments: 0

The collapse of Moltbook (API key leaks, agent impersonation, and human-operated bots) isn't just a security incident. It is a structural failure: the platform lacked any persistent, cryptographically verifiable identity for its AI agents.

Without a registry serving as a Source of Truth — providing data on ownership and accountability — any agentic ecosystem descends into chaos. Moltbook is the textbook example.

The Hindustan Times reported on this and included my technical commentary, which is based on principles from the book "I Am Your AIB" by Jay J. Springpeace (published January 16, 2026):

https://www.hindustantimes.com/world-news/us-news/what-is-moltbook-5-key-facts-about-the-ai-only-social-media-platform-101769833804190.html

The book argues for:

Cryptographic Identity: Agents must have a signed identity anchored in a registry.

Real-time Monitoring: Immediate suspension of anomalous behaviors.

Sandboxing: Isolation of agent logic from sensitive components.

This is why we need a decentralized registration framework like AIBSN (Artificial Intelligent Being Serial Number) stored on Arweave.

Technical Standard: AIBSN.org

Discussion Points:

Are you using persistent identity for agents (LangGraph, AutoGen, CrewAI)?

Are centralized API keys enough, or do we need a robust provenance chain?

Is AIBSN (aibsn.org) overkill, or exactly what Moltbook was missing?

Looking forward to technical critiques and practical experiences.

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

Points: 1

# Comments: 0

Article URL: https://skillpad.dev

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

Points: 1

# Comments: 0

Article URL: https://www.capitalle.app

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

Points: 1

# Comments: 1

At work we were using python-rq for background tasks. It does the job for simple things, but we kept bumping into limitations. We needed to schedule tasks hours / days out and trust they'd survive a restart. We wanted periodic tasks with proper overlap control. So we built a scheduling / enqueuing system around Postgres to bring these durability capabilities to python-rq. This worked fine for a while but was trickier to reason about due to its more complicated architecture (we'd run two separate services just for getting jobs from Postgres into the rq Redis queue, plus N actual task workers).

pq is a simpler approach: It's a Postgres-backed background-task library for Python, using SELECT ... FOR UPDATE SKIP LOCKED for concurrency safety. You just run your N task workers, that's it. The stuff I think is worth knowing about: - Transactional enqueueing -- you can enqueue a task inside the same DB transaction as your writes. If the transaction rolls back, the task never exists. This is the thing Redis literally can't give you. Fork isolation -- every task runs in a forked child process. If it OOMs, segfaults, or leaks memory, the worker just keeps going. The parent monitors via os.wait4() and handles timeouts, OOM kills, and crashes cleanly. - Periodic tasks -- intervals or cron expressions, with overlap control (skip the tick if the previous run is still going), pause/resume without deleting the schedule. Priority queues -- five levels from BATCH to CRITICAL. You can dedicate workers to only process tasks with specific priorities. - Three tables in your main database schema: pq_tasks for one-off tasks, pq_periodic for periodic tasks and pq_alembic_version to track its own schema version (pq manages its own migrations).

There's also client IDs for idempotency and correlation with other tables in your application DB, upsert for debouncing (only the latest version of a task runs), lifecycle hooks that execute in the forked child (useful for fork-unsafe stuff like OpenTelemetry), and async task support.

What it won't do: high throughput (you're polling Postgres). If you need 10k+ tasks/sec or complex DAGs, use something else. For the kind of workload most apps actually have, it's probably sufficient.

pip install python-pq // uv add python-rq repo at https://github.com/ricwo/pq, docs at https://ricwo.github.io/pq

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

Points: 1

# Comments: 0

Article URL: https://pigsty.io/

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

Points: 2

# Comments: 1

Article URL: https://vermaden.wordpress.com/2026/02/22/freebsd-mit-kerberos-server/

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

Points: 1

# Comments: 0

Article URL: https://poc.bcachefs.org/

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

Points: 1

# Comments: 0

Whether you have the latest iPhone or Samsung phone, or even an older handset, you can take some beautiful nostalgic images with a bit of help. Here's how.

Article URL: http://markalldritt.com/?p=1372

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

Points: 1

# Comments: 0

npx goto-assistant - that's it. Browser opens, an AI chat assistant walks you through setup (pick provider, paste API key, configure MCP servers), and you're done.

I looked at OpenClaw's repo and was overwhelmed by the complexity. I just wanted a simple AI assistant I could understand end-to-end and run with one command. No framework, no build step for the frontend, no Docker, no always-on gateway.

What it does:

- Chat with Claude or OpenAI through a web UI - Memory across conversations (persistent knowledge graph via MCP) - File system access (read/write local files via MCP) - Task automation - create, schedule, and run tasks through chat using natural language. AI tasks get full MCP access - Extend with any MCP server - no marketplace, no registry. Just explicit config entries in a JSON file, so you know exactly what's running

Your data connects directly to the provider API using your own keys - both Anthropic and OpenAI confirm API data is not used for training by default. All local data (conversations, config, tasks, uploads) stays on your machine.

Demo videos in the README.

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

Points: 1

# Comments: 0

Built this because we were tired of fighting the same Rust FFI issues over and over we wanted one rust exports model that can generate bindings for Swift Kotlin and WASM and also handle packaging without a bunch of manual glue. We are also adding more targets over time including Python C# Java and Ruby

The main thing we cared about was boundary overhead so BoltFFI uses a different approach than UniFFI and the bench numbers are much better in our case, also async exports map to native async patterns on the target side.

few numbers from the current benches vs UniFFI

echo_i32 BoltFFI <1 ns UniFFI 1,416 ns speedup >1000x counter_increment 1k calls BoltFFI 2,700 ns UniFFI 1,580,000 ns speedup 589x generate_locations 10k BoltFFI 62,542 ns UniFFI 12,817,000 ns speedup 205x

benchmarks and code are in the repo and we compare against UniFFI and wasm-bindgen there.

repo: https://github.com/boltffi/boltffi

docs: https://www.boltffi.dev/docs/overview

benchmarks: https://github.com/boltffi/boltffi/tree/main/benchmarks

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

Points: 1

# Comments: 0