u/kevtam515

Fiber Desktop — run Fiber (FNN) on your laptop without the “public node” headache

Fiber Desktop — run Fiber (FNN) on your laptop without the “public node” headache

This is pretty cool that someone is buidling how to use Fiber nodes for the non super tech crowd. If anyone tries it give the OP some feedback on the forum post https://talk.nervos.org/t/fiber-desktop-run-fiber-fnn-on-your-laptop-without-the-public-node-headache/10247

Hi everyone,

If you follow Nervos, you may have heard of Fiber — a way to move value quickly on top of CKB using channel-style payments, routing, and invoices. To use it, you normally need a small program running in the background: the official Fiber Network Node (often called fnn). That program is the “engine” that opens channels, listens for payments, and creates invoices.

The awkward part is not the idea of Fiber. It is where that engine is supposed to live. Many people end up looking at rented serversrouter settingsalways-on home machines, and security checklists just to feel like they can participate. That is a lot of work for something that should feel closer to “install an app and use the network.”

There is a second wall that hits even on your own laptop: setup is often CLI-heavy. Getting from zero to a working node can mean a long chain of terminal commands — right binary, paths, config, key material, then RPC-style steps for connecting to peers, opening channels, creating invoices, and so on. That is fine for power users, but it filters out anyone who wants to try the network without treating the docs like a daily homework assignment.

I built Fiber Desktop to narrow both gaps: less hosting pressure and less death-by-CLI. This post explains what it is and how it fits together for people who are not deep into ops or protocol details.

What Fiber Desktop is

Fiber Desktop is a desktop application for Mac or PC (tested properly for Mac). It does not replace the official Fiber software. It wraps it: it helps you install and run the same official node (fnn) on the machine you already use, with clearer steps, start/stop controls, and safer handling of secrets.

In plain roles:

  1. Tour guide — walks you through setup in order (network, data folder, configuration, where to put your key material).
  2. Dashboard — start and stop the node, see logs, and use the network from one place.
  3. Vault assistant — stores the node’s encryption password in your operating system’s built-in secure storage (keychain / credential manager) instead of scattering it in random files.

Where you would otherwise juggle many CLI commands and hand-built RPC calls, the app pushes you toward guided flows and in-app actions (for example connecting to documented relays or trying channel and invoice steps from the UI) so you are not memorizing command order on day one.

Under the hood it is a native app (Tauri + React, etc.). If you are not technical, you can ignore that: what matters is that it is a normal desktop app controlling the official Fiber node on your desk or laptop.

Source: github.com/chukwuma619/fiber-desktop

The problem it tries to solve

Using Fiber seriously usually means keeping that engine running and connected enough to be useful on the network. That often pushes people toward:

  • VPS they must maintain and lock down
  • small home server that must stay on
  • Networking questions (ports, public addresses, who can reach my machine)
  • Operational questions (updates, backups, monitoring)

On top of that, day-one onboarding is often a long sequence of CLI and JSON-RPC steps: easy to get stuck on one wrong path, flag, or payload even when you are not trying to self-host.

Fiber Desktop is aimed at a different default: run the official node locally, on hardware you already own, with a user experience closer to consumer software — guided setup instead of a wall of commands — while still following how the Fiber ecosystem expects nodes to connect and discover each other, including documented public relay nodes.

How you join the network (without turning your PC into a “public hosting project”)

Fiber nodes talk to each other peer-to-peerPublic relay nodes are well-known peers listed in the official docs. They act like on-ramps: you connect out to them so your node is no longer isolated.

In Fiber Desktop that shows up as actions like connecting to relay 1 or relay 2 for your chosen network, using the same public keys the Fiber project documents. https://github.com/nervosnetwork/fiber/blob/develop/docs/public-nodes.md

You are not inventing a custom bridge; you are joining the same mesh the docs describe. That is different from “I must run a public website that exposes my wallet.” You are participating in a network of nodes, not necessarily running a personal datacenter as the default onboarding story.

Channels, invoices, and how a payment reaches your machine

Channels are the “pipes”

After you are connected, the next big step is usually opening a channel with another node (often one of the public relays when you are learning). A channel is a rules-based pipe between two nodes.

Important nuance: payments usually do not flow as “one big public server receives everything and then downloads it to your laptop.” They move hop by hop across many channels when needed. Public relays help you plug in and become part of that map, but a payment route can be longer than a single hop.

Invoices are created on your computer

When you create an invoice, that request is generated by your local node. You share it (text / QR) with whoever pays. You do not need a public payment website for that step.

Routing is how money crosses the mesh

When someone pays your invoice, their software searches for a path across the network — a chain of channel hops from them to you. If a valid path exists and every hop has enough capacity pointing the right way, the payment settles on your node — the one running under Fiber Desktop.

So this high-level picture is right: the payment is routed across the Fiber network until it reaches my local node. The small correction is: it is not always “only the public relay sends it down to me”; it is often several hops across different nodes, with yours as the final stop.

A honest note on receiving

Receiving reliably in channel-based networks usually needs incoming capacity (liquidity and channel layout that allow value to flow toward your node). If someone tries to receive before channels are set up sensibly, they may see “no route” even when the app is working. Fiber Desktop makes the machinery easier; the economics of the graph are still part of the real network.

Fiber Desktop does not change what Fiber is. It changes how painful it is to run the real thing on a normal computer: official software firstlocal controlless accidental sysadmin, and less reliance on a long CLI checklist just to get started.

If you try it, feedback is welcome — especially first-time setup, key handling, connectivity to public relays, and whether the guided flows replace the commands you used to need.

u/kevtam515 — 3 days ago

New Community DAO proposal- Quantir Risk Intelligence for CKB Ecosystem and Cross-Chain Monitoring

This proposal in in the first discussion stage. Have a look. If its something you want to see moved ti the vote stage give it a ♥️. 30 are needed to move it forward or feel free to question and challenge the OP in the reply section if you want more clarity from them. https://talk.nervos.org/t/dis-quantir-risk-intelligence-for-ckb-ecosystem-and-cross-chain-monitoring/10218

Quantir proposes to build a CKB-aware risk intelligence and monitoring layer for the Nervos ecosystem. The system will monitor selected public CKB ecosystem activity, detect abnormal behavior, compute normalized risk signals, and deliver explainable alerts for developers, ecosystem operators, dashboards, and community monitoring workflows.

Quantir is an existing DeFi and on-chain risk monitoring platform with live collectors, transaction monitoring, risk scoring, alert delivery, API/WebSocket interfaces, and explainability services. This proposal adapts the existing Quantir architecture to CKB-specific ecosystem signals rather than building a monitoring system from scratch.

Requested budget: $30,000 equivalent in CKB.
Estimated duration: 10 weeks.
Payment structure: milestone-based.

Project Motivation
CKB is a flexible and interoperable Layer 1 with a unique Cell model, xUDT/token capabilities, cross-chain potential, Bitcoin-related infrastructure, payment-channel development, and a growing application ecosystem. This flexibility is valuable, but it also makes ecosystem monitoring harder.

Developers and operators can inspect raw activity through explorers, dashboards, and individual tools, but there is no unified layer that turns ecosystem activity into structured, explainable risk signals. Important conditions such as unusual token flows, bridge-related stress, abnormal contract or cell activity, liquidity pressure, payment-channel anomalies, or DAO fund-flow risks may be noticed only after they become obvious.

Quantir aims to provide earlier and clearer visibility by converting fragmented public signals into normalized scores, alerts, and explanations.

Proposal Overview
Quantir will build a CKB-specific monitoring module focused on public ecosystem signals. The system will collect and normalize selected CKB activity, detect abnormal patterns, score risk conditions, and generate alerts that can be consumed by dashboards, bots, APIs, or ecosystem monitoring tools.

The proposed module will focus on:

CKB ecosystem activity monitoring.
xUDT/token-flow anomaly detection.
Bridge and cross-chain activity monitoring.
CKB DeFi and liquidity-risk signals.
Abnormal contract/cell activity detection.
DAO/community fund activity monitoring.
Fiber/payment-channel risk signals where public data is available.
API/WebSocket-ready alert outputs.
Human-readable explanations for risk events.
Validation examples and technical documentation.

This work will not modify CKB consensus, CKB-VM, core protocol code, or wallet infrastructure. It will operate as an external monitoring and intelligence layer using public or reviewable ecosystem signals.

Technical Approach
The implementation will reuse Quantir’s existing multi-service architecture and adapt it to the Nervos ecosystem.

Core components:

Data ingestion layer
Collects selected public CKB ecosystem signals, including token activity, contract/cell behavior, DAO-related activity, DeFi signals, bridge-related events, and other supported public data sources.

Signal normalization layer
Transforms raw activity into comparable risk features such as flow intensity, concentration, repeated address patterns, abnormal activity spikes, liquidity changes, and risk-score deltas.

Risk scoring layer
Computes normalized risk scores and score changes for monitored entities.

Strategy layer
Detects abnormal activity patterns and triggers alert conditions.

Explanation layer
Generates human-readable explanations describing why an alert was triggered, what evidence supports it, and what changed.

Delivery layer
Outputs structured alert payloads suitable for APIs, WebSocket streams, dashboards, and bots.

Example alert output:

Alert category: xUDT flow anomaly
Severity: medium
Risk score: 71
Reason codes: sudden transfer spike, repeated address pattern, abnormal concentration
Evidence: transaction hashes, token identifier, addresses, timestamps
Explanation: “This token activity was flagged because transfer frequency increased sharply while repeated address patterns and concentrated flows appeared within the same monitoring window.”

Deliverables
CKB-specific monitoring scope and architecture document.
Public signal taxonomy for CKB ecosystem risk.
Structured alert schema.
CKB-aware ingestion prototype.
Risk scoring and anomaly detection logic.
Explainable alert generation.
API/WebSocket-ready output format.
Reference consumer or integration example.
At least 5 alert categories.
At least 10 sample alert scenarios.
Setup guide and testing documentation.
Final validation report.

Key Performance Indicators
At least 5 CKB-specific risk categories documented.
At least 10 sample alert scenarios produced.
Working prototype that generates structured CKB ecosystem alerts.
Alerts include severity, score, reason codes, evidence, and explanation.
Reference consumer can read or display alert outputs.
Documentation allows reviewers or developers to understand and test the prototype.
At least 3 validation examples completed.
Final report delivered to the Nervos community.

Milestones and Timeline
Total duration: 10 weeks.

Milestone 1: Scope, CKB Signal Taxonomy, and Architecture
Timeline: Weeks 1-2
Funding requested: $6,000 equivalent in CKB

Deliverables:
CKB-specific monitoring scope.
Public data-source mapping.
Risk category taxonomy.
Initial alert schema.
Technical architecture document.
Implementation plan.

Success criteria:
At least 5 risk categories are defined.
Initial alert schema is complete.
Data-source assumptions and technical scope are documented.

Milestone 2: Ingestion Prototype and Normalized Risk Signals
Timeline: Weeks 3-5
Funding requested: $9,000 equivalent in CKB

Deliverables:
CKB-aware ingestion prototype.
Normalized signal generation.
Initial scoring logic.
Sample alert generation.
Basic test coverage for core signal processing.

Success criteria:
Prototype can process selected public CKB ecosystem signals.
Structured alerts are generated from sample or public data.
At least 5 alert categories are implemented in sample form.

Milestone 3: Explainable Alerts and Integration Outputs
Timeline: Weeks 6-8
Funding requested: $8,000 equivalent in CKB

Deliverables:
Explanation logic for alert events.
API/WebSocket-ready alert format.
Reference consumer or integration example.
Sample documentation for external consumers.

Success criteria:
Alerts contain severity, score, evidence, reason codes, and explanation.
Reference integration can consume alert outputs.
Documentation explains how ecosystem tools can use the outputs.

Milestone 4: Validation, Documentation, and Final Delivery
Timeline: Weeks 9-10
Funding requested: $7,000 equivalent in CKB

Deliverables:
At least 3 validation examples.
At least 10 sample alert scenarios.
Final setup guide.
Testing guide.
Final technical report.
Public or reviewable repository with schemas, prototype code, examples, and documentation.

Success criteria:
Reviewers can inspect or run the prototype.
All milestone deliverables are documented.
Final report summarizes results, limitations, and recommended next steps.

Budget
Total funding requested: $30,000 equivalent in CKB.

Budget breakdown:

Engineering and CKB-specific integration: $12,000
Risk signal design and scoring logic: $5,000
API/WebSocket-ready outputs and reference integration: $4,000
Validation, testing, and documentation: $4,000
Infrastructure, data access, storage, and monitoring: $3,000
Grant reporting and contingency: $2,000

Payment structure: milestone-based.
Suggested initial payment: 20% of total budget, with the remaining amount distributed after milestone review.

Team
The project will be delivered by the Quantir core team.

Ilya Berdar — Senior Blockchain Developer / Project Lead
Responsible for technical architecture, CKB integration scope, risk engine adaptation, grant communication, and final delivery.

Andriy Boichuk — Senior Software Developer
Responsible for backend services, data ingestion, infrastructure, normalization logic, tests, and deployment workflows.

Alex Grishenko — Senior Software Developer
Responsible for alert schemas, explanation outputs, reference integration, documentation, validation examples, and product implementation.

Relevant Links
Quantir landing page: https://landing.quantirintelligence.com/
Quantir app: https://app.quantirintelligence.com/
Quantir GitHub repository: https://github.com/quantirintelligence/quantir-risk-engine

Long-Term Plan
If the pilot is successful, Quantir can expand CKB ecosystem monitoring to additional applications, bridges, tokens, DAO fund flows, DeFi systems, and payment-channel infrastructure. The long-term goal is to provide an explainable risk intelligence layer that helps the Nervos ecosystem improve visibility, resilience, and integration readiness.

Additional Notes
Quantir’s differentiator is that it combines monitoring, scoring, explainability, and alert delivery in one workflow. It does not only show charts or raw events; it translates ecosystem behavior into actionable, interpretable, machine-readable outputs.

This proposal is implementation-focused and designed to deliver reusable monitoring infrastructure for the Nervos ecosystem.

u/kevtam515 — 10 days ago

From Polycrypt:

Cross-chain DeFi between Ethereum and CKB is coming and is powered by Perun!

There will be liquidity pools on both chains with an integrated AMM. You will be able to deposit CKB or ETH and earn yield from cross-chain swaps.

We built smart contracts on both Ethereum and CKB that hold liquidity pools. You deposit assets on whichever chain you are on, earning fee revenue as soon as users swap assets between the chains, using the liquidity you provided.

Unlike most cross-chain bridges, no validator committees or trusted relays needed. Swaps are secured by Perun, our formally verified OSS state channel protocol. No additional setup or trust into intermediaries required. Swaps are settled on ETH and CKB smart contracts.

The AMM handles pricing, Perun channels handle settlement, and the contracts make sure LPs get their principal back plus fees. You deposit and earn. More updates are coming soon!

reddit.com
u/kevtam515 — 14 days ago

The latest devlog summary here. Ckeck the full devlog here for more details

https://github.com/nervosnetwork/ckb/discussions/5191

Latest updates of CKB from the engineering side:
Another month of refining the core and pushing optimizations, including improved CKB-VM ARM64 performance and ML-DSA work to help prepare for post-quantum standards.
Also strengthening CKB-VM with a new differential testing framework to validate future optimizations.

Other updates:
- AI Tooling: Added SKILL for AI agents in ckb-debugger to streamline script debugging
- Connectivity: Continued QUIC support for Tentacle to provides faster handshakes and better resilience against connection migration
- Governance: Multiple DAO Treasury designs & voting directions under discussion
- Maintenance: Upgraded toolchain to 1.95.0 and synced ckb-musl with upstream

CKB DAO Treasury Design & Voting Research

research on the CKB DAO Treasury design and voting settlement, with multiple directions under active discussion:

  • Option 1DAO-Bound Voting with Off-Chain State

Explores a governance model where voting power is bound to Nervos DAO deposits, while proposal state, voting records, and tally data are maintained off-chain and committed on-chain through verifiable state roots.

This direction focuses on improving scalability while keeping governance state verifiable.

  • Option 2: Experimental MVP Implementation

Built an experimental MVP to validate core DAO Treasury workflows and voting-related transaction construction. Details see: https://github.com/chenyukang/ckb/blob/dao-treasury/dao-treasury

  • Option 3: Rollup-inspired Voting Settlement

Explores a rollup-inspired approach for voting settlement, where voting data is batched and compressed into verifiable state updates.

This direction focuses on improving settlement efficiency while preserving on-chain verifiability under CKB’s UTXO model.

Key Question Identified & Follow-Up Research

How to handle on-chain settlement for the voting process. Continued follow-up research based on the design discussions:

  • Evaluation of CKB partial transaction design based on the newly proposed voting architecture.
  • A zkVM-based solution for voting.
u/kevtam515 — 15 days ago