{ "base_url": "https://talk.nervos.org", "generated_at": "2026-05-01T17:58:05.347488+00:00", "since": "2026-04-30T17:58:01.053220+00:00", "until": "2026-05-01T17:58:01.053220+00:00", "window_hours": 24, "topics": [ { "topic_id": 10199, "title": "Cellora — designing a production indexing and query service for CKB (feedback welcome)", "slug": "cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome", "url": "https://talk.nervos.org/t/cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome/10199", "created_at": "2026-04-22T15:33:26.290000+00:00", "last_posted_at": "2026-05-01T16:57:21.842000+00:00", "category_id": 32, "tags": [ "CKB", "Nervos-项目动态", "dapp", "testnet" ], "posters": [ "Original Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24101, "post_number": 6, "topic_id": 10199, "topic_title": "Cellora — designing a production indexing and query service for CKB (feedback welcome)", "topic_slug": "cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome", "author": "matt_ckb", "created_at": "2026-05-01T16:37:52.751000+00:00", "updated_at": "2026-05-01T16:37:52.751000+00:00", "reply_to_post_number": 4, "url": "https://talk.nervos.org/t/cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome/10199/6", "content_text": "ArthurZhang:\nFor tx inclusion proofs, the practical first step is likely not Flyclient, but exposing CKB’s existing get_transaction_proof / verify_transaction_proof path through Cellora. That lets clients verify that a transaction is committed under a particular block header, rather than merely trusting Cellora’s indexed result.\nWithout the Flyclient proof, I have trouble seeing how the client can verify that the block header returned from Cellora has been included in the chain. Am I missing something?", "content_html": "\n

Without the Flyclient proof, I have trouble seeing how the client can verify that the block header returned from Cellora has been included in the chain. Am I missing something?

", "like_count": 0, "quote_count": 1 }, { "post_id": 24102, "post_number": 7, "topic_id": 10199, "topic_title": "Cellora — designing a production indexing and query service for CKB (feedback welcome)", "topic_slug": "cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome", "author": "ArthurZhang", "created_at": "2026-05-01T16:57:21.842000+00:00", "updated_at": "2026-05-01T16:57:42.986000+00:00", "reply_to_post_number": 6, "url": "https://talk.nervos.org/t/cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome/10199/7", "content_text": "Yes, agreed. I was following Antismart’s staged framing here.\nI meant that get_transaction_proof / verify_transaction_proof is useful for the step-2 property: tx-to-header verification. It does not by itself prove that the returned header is canonical.\nThe full trust minimisation later on still needs Flyclient, a local node, or another trusted header source.", "content_html": "

Yes, agreed. I was following Antismart’s staged framing here.

\n

I meant that get_transaction_proof / verify_transaction_proof is useful for the step-2 property: tx-to-header verification. It does not by itself prove that the returned header is canonical.

\n

The full trust minimisation later on still needs Flyclient, a local node, or another trusted header source.

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10220, "title": "Pckt: A Friendly Way to Send CKB | pckt：一种友好的发送 CKB 的方式", "slug": "pckt-a-friendly-way-to-send-ckb-pckt-ckb", "url": "https://talk.nervos.org/t/pckt-a-friendly-way-to-send-ckb-pckt-ckb/10220", "created_at": "2026-04-30T18:38:17.768000+00:00", "last_posted_at": "2026-05-01T15:55:22.939000+00:00", "category_id": 32, "tags": [ "CKB", "Nervos-项目动态", "appchain", "dapp" ], "posters": [ "Original Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24083, "post_number": 1, "topic_id": 10220, "topic_title": "Pckt: A Friendly Way to Send CKB | pckt：一种友好的发送 CKB 的方式", "topic_slug": "pckt-a-friendly-way-to-send-ckb-pckt-ckb", "author": "RobaireTH", "created_at": "2026-04-30T18:38:17.876000+00:00", "updated_at": "2026-04-30T18:48:46.936000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/pckt-a-friendly-way-to-send-ckb-pckt-ckb/10220/1", "content_text": "pckt is a red-packet style CKB app. A sender seals CKB into a single on-chain packet cell, shares a link, and recipients claim from that packet until it is exhausted or expires. If the packet expires before all claims are taken, the sender can reclaim the remainder\nimage1405×892 127 KB\nFor now, this is a solo-built project. I have tried to keep the architecture small, inspectable, and easy to maintain without requiring a large ops or protocol team.\nProblem and Solution\nThe problem\nSending tokens on-chain is usually transactional, but not ceremonial. Red packets are social. They are meant to be shared into a group, opened by multiple recipients, and claimed with a sense of timing, surprise, and urgency.\nMost wallet transfer flows do not capture that behavior well. They support “send X to Y,” but not:\none sender, many recipients\npartial sequential claiming\ntime-gated opening\n“claim by link” behavior\nreclaiming unclaimed balance after expiry\nThe solution\npckt models the packet as a single live CKB cell governed by a custom lock script. Instead of keeping packet state off-chain, every claim consumes the packet cell and produces its next version. That lets the chain remain the source of truth while the frontend and backend make the experience feel native.\nHosted solution: https://sendpckt.robaireth.dev\nRepo: GitHub - RobaireTH/pckt: The friendliest way to send CKB · GitHub\nThe core user flow is:\nSender seals a packet on-chain.\nSender shares a claim link.\nRecipients claim against the packet cell.\nThe packet shrinks as claims happen.\nIf claims are exhausted, the packet terminates.\nIf time expires first, the sender can reclaim the remainder.\nTechnical Approaches and Design Decisions\n1. One contract, one packet cell\nThe main design decision is that a packet is not an account, and it is not a backend object. It is a single live cell with explicit, serialized state.\nThat gives a few advantages:\neasier audit surface than a larger state machine\nno server custody\nclaims are naturally serialized by cell consumption\neach state transition is verifiable from chain history\n2. Frontend signs the social flow, backend indexes the chain\nimage805×1018 97.9 KB\nimage1425×798 103 KB\nThe system is split into three parts:\nContract: Rust CKB lock script for claim and reclaim paths\nFrontend: React + TypeScript app using CCC to build and sign transactions\nBackend: Rust + Axum + SQLite indexer and UX helper\nThe backend is intentionally non-authoritative. It does not hold keys, does not create truth, and can be replaced. Its role is to index packet state, provide sender/claimer views, short links, and live UX data.\n3. Claim links put the secret in the fragment\nThe claim secret lives in the URL fragment, not in backend storage. That means the browser can hold the secret client-side while the backend only sees the public short-link target. This is an important design boundary: the server helps with UX, but it should not become a custody or secret-management layer.\n4. Testnet-first, with deliberate constraints\nI explicitly kept this testnet-first and avoided pretending every mode is ready for production. In particular:\nreclaim exists on-chain and is now wired into the UI\nsender naming is currently backend-stored and convenience-oriented, not yet decentralized identity\nthe “lucky split” mode is constrained by payout math and safety concerns\nCKB Ecosystem Relevance\npckt is relevant to CKB because it leans into what cells are good at:\nexplicit state\ncomposable lock logic\nsequential consumption and recreation\ncustom social/financial flows without custodial middleware\nI believe it’s of benefit to the wider ecosystem as it is a good initiative to introduce people to the Nervos CKB by bringing in centuries old traditions onchain. A simple sharing of love!\nimage1282×1211 207 KB\nDeployment Architecture\nCurrent deployment shape:\nFrontend: Vite app deployed separately\nBackend: Fly.io app\nDatabase: SQLite on Fly volume\nChain target: CKB testnet (Pudge)\nThe backend runs as:\npacket indexer\npacket/query API\nshort-link service\nprice helper\nrelay endpoint for signed transactions\nThe frontend is configured by environment variables with:\ntestnet RPC URL\nactive contract code hash\ncontract outpoint\nbackend URL\nSecurity Considerations\n1. Self-custody\nFunds are locked on-chain. The backend never has authority to move them.\n2. Non-authoritative backend\nThe backend is replaceable and should be treated as UX infrastructure, not a trust anchor. It’s even the contract that rejects multiple claims, not the backend.\n3. Claim secret handling\nThe claim secret sits in the URL fragment so it is not automatically sent to servers. This avoids a major class of accidental backend custody.\n4. Reorg and index correctness\nThe backend includes reorg handling and block-hash rollback logic because packet state derived from chain history must survive reorgs cleanly.\n5. Explicitly bounded feature set\nI do not want unsafe “it sort of works” behavior around payout math or reclaim timing. Where a mode looks questionable, I prefer to restrict it until it is clean.\nWhy I Don’t Like the Maths Behind Lucky Splits For Now\nI do not dislike the idea of lucky splits. I dislike the current math and operational risk profile of lucky splits in this implementation.\nThe problem is: once you move from fixed shares to random shares, you need to guarantee that:\neach claim remains above minimum live-cell capacity\nenough capacity is reserved for future claims\nthe final claim and reclaim paths still behave safely\nthe user-facing preview matches what on-chain logic will actually allow\nThat is easy to get subtly wrong.\nIn practice, lucky mode becomes a product-security problem, not just a product-design problem. If the random lower bound is too low, you can create unclaimable outputs. If the reservation math is too optimistic, you can strand capacity. If frontend prediction diverges from contract math, users get misleading expectations.\nFor now, I prefer the stricter stance:\nfixed and timed-fixed remain usable\nlucky mode is something I would only re-enable once I am satisfied that the lower-bound math, reservation rules, and UI expectations are all aligned\nI would rather disappoint users with a disabled mode than lock them into a half-correct one.\nMaintenance Plan\nI plan to use this Talk Nervos thread itself as part of the maintenance loop.\nSpecifically:\nI will post updates there as features or fixes land\nI will note contract redeploys and testnet config changes here\nI will use the thread to surface known limitations honestly\nI will treat user reports in the thread as a lightweight public changelog and maintenance channel\nThe near-term maintenance priorities are:\nstabilize sender/claimer UX\nkeep reclaim flow reliable and understandable\ntighten profile/name semantics\nrevisit lucky split math only when it is safe\ncontinue testnet usage before thinking seriously about mainnet\nClosing\npckt is an attempt to build something small, social, and unmistakably native to CKB’s cell model. It is not trying to be a generic wallet feature (Though it can be). It is trying to make a familiar ritual feel right on-chain.\nIf that resonates, I’d love feedback moat importantly on whether the identity layer should remain simple or move toward a more formal DID-based model later.\nZH\npckt 是一个类似红包的 CKB 应用。发送者将 CKB 封装成一个链上数据包，分享一个链接，接收者可以从该数据包中认领代币，直到数据包耗尽或过期。如果数据包在所有代币被认领之前过期，发送者可以重新认领剩余的代币。\nimage1405×892 127 KB\n目前，这是一个由我独立开发的项目。我努力保持架构的简洁、易于检查和维护，无需庞大的运维或协议团队。\n问题与解决方案\n问题\n链上发送代币通常是交易性的，但缺乏仪式感。红包则具有社交性。它们应该被分享给一群人，由多个接收者打开，并以一种带有时机感、惊喜感和紧迫感的方式认领。\n大多数钱包的转账流程都无法很好地体现这种行为。他们支持“向 Y 发送 X”，但不支持：\n一个发送方，多个接收方\n部分顺序声明\n时间门控开启\n“通过链接声明”行为\n过期后回收未声明余额\n解决方案\npckt 将数据包建模为由自定义锁定脚本控制的“单个活跃 CKB 单元”。数据包状态并非保存在链下，而是每次声明都会消耗数据包单元并生成其下一个版本。这使得链始终保持真实性，同时前端和后端提供原生体验。\n托管解决方案：https://sendpckt.robaireth.dev\n代码库：GitHub - RobaireTH/pckt: The friendliest way to send CKB · GitHub\n核心用户流程如下：\n发送方在链上密封数据包。\n发送方共享声明链接。\n接收方针对数据包单元进行声明。\n随着声明的进行，数据包会逐渐缩小。\n如果所有请求权都已用尽，则数据包终止。\n如果时间先到期，发送方可以重新获取剩余的请求权。\n技术方案和设计决策\n1. 一个合约，一个数据包单元\n主要的设计决策是：数据包不是账户，也不是后端对象。它是一个具有明确序列化状态的“单个活动单元”。\n这带来了一些优势：\n比大型状态机更容易审计\n无需服务器托管\n声明自然地按单元消耗进行序列化\n每个状态转换都可以从链历史记录中验证\n2. 前端对社交流进行签名，后端对链进行索引\nimage805×1018 97.9 KB\nimage1425×798 103 KB\n该系统分为三个部分：\nContract：用于声明和回收路径的 Rust CKB 锁定脚本\nFrontend：使用 CCC 构建和签名交易的 React + TypeScript 应用\nBackend：Rust + Axum + SQLite 索引器和 UX 辅助工具\n后端有意设计为非权威。它不持有密钥，不创造真理，并且可以被替换。它的作用是索引数据包状态，提供发送方/声明方视图、短链接和实时用户体验数据。\n3. 声明链接将密钥放在片段中\n声明密钥存储在 URL 片段中，而不是后端存储中。这意味着浏览器可以在客户端持有密钥，而后端只能看到公开的短链接目标。这是一个重要的设计边界：服务器有助于用户体验，但不应成为密钥保管层或密钥管理层。\n4. 测试网优先，并设定了明确的限制\n我特意坚持测试网优先的原则，避免假装所有模式都已准备好用于生产环境。具体而言：\n资金回收功能已上线，并集成到用户界面中\n发送者名称目前存储在后端，仅供方便使用，尚未实现去中心化身份\n“幸运平分”模式受限于支付算法和安全问题。\nCKB 生态系统相关性\npckt 与 CKB 的相关性在于它充分利用了 Cell 的优势：\n显式状态\n可组合的锁逻辑\n顺序消费和再利用\n无需托管中间件的自定义社交/金融流程\n我相信这对整个生态系统都有益处，因为它是一个很好的举措，通过将几个世纪以来的传统引入链上，向人们介绍 Nervos CKB。这是一种简单的分享！\nimage1282×1211 207 KB\n部署架构\n当前部署结构：\n前端：独立部署的 Vite 应用\n后端：Fly.io 应用\n数据库：Fly 卷上的 SQLite 数据库\n目标链：CKB 测试网 (Pudge)\n后端运行方式如下：\n数据包索引器\n数据包/查询 API\n短链接服务\n价格辅助工具\n已签名交易的中继端点\n前端通过环境变量配置，包括：\n测试网 RPC URL\n活动合约代码哈希值\n合约输出点\n后端 URL\n安全注意事项\n1. 自保\n资金锁定在链上。后端无权移动资金。\n2. 非权威后端\n后端是可替换的，应该被视为用户体验基础设施，而不是信任锚点。甚至拒绝多个声明的也是合约，而不是后端。\n3. 声明密钥处理\n声明密钥位于 URL 片段中，因此不会自动发送到服务器。这避免了一类主要的意外后端保管风险。\n4. 重组和索引正确性\n后端包含重组处理和区块哈希回滚逻辑，因为从链历史中派生的包状态必须在重组后保持完好。\n5. 明确限定的功能集\n我不希望在支付计算或回收时间方面出现不安全的“勉强能用”的行为。如果某个模式看起来有问题，我倾向于限制它，直到它变得安全为止。\n为什么我目前不喜欢幸运分割背后的数学原理\n我并不反对幸运分割的想法。我不喜欢当前实现中“幸运拆分”的数学原理和操作风险。\n问题在于：一旦从固定份额改为随机份额，就需要保证：\n每次认领都保持在最低活跃单元容量之上\n为未来的认领预留足够的容量\n最终认领和赎回路径仍然安全\n用户预览与链上逻辑实际允许的情况相符\n这一点很容易出现细微的错误。\n实际上，“幸运模式”会演变成产品安全问题，而不仅仅是产品设计问题。如果随机下限设置得太低，可能会导致无法认领的输出结果。如果预留计算过于乐观，则可能导致资源闲置。如果前端预测与合同计算存在偏差，则会产生误导性的预期。\n目前，我倾向于采取更严格的立场：\n固定模式和限时固定模式仍然可用\n只有在我确信下限计算、预留规则和用户界面预期都一致后，我才会重新启用“幸运模式”。\n我宁愿禁用该模式让用户失望，也不愿让他们使用一个半真半假的模式。\n维护计划\n我计划将此 Talk Nervos 讨论帖本身作为维护流程的一部分。\n具体来说：\n我会在此发布新功能或修复的更新\n我会在此记录合约重新部署和测试网配置变更\n我会在此帖中如实说明已知的限制\n我会将帖子中的用户报告视为一个轻量级的公开变更日志和维护渠道\n近期维护重点如下：\n稳定发送方/领取方的用户体验\n保持回收流程的可靠性和易懂性\n完善个人资料/名称语义\n仅在安全的情况下重新审视幸运拆分算法\n在认真考虑主网之前，继续使用测试网\n结束语\npckt 旨在构建一个小型、社交化且与 CKB 的 cell 模型完美契合的原生应用。它并非旨在成为一个通用的钱包功能（尽管它也可以做到）。它的目标是让熟悉的仪式感在链上自然流畅地呈现。\n如果这引起了您的共鸣，我非常希望收到反馈，尤其希望了解身份层是否应该保持简单，还是应该在未来转向更正式的基于 DID 的模型。", "content_html": "
\n

pckt is a red-packet style CKB app. A sender seals CKB into a single on-chain packet cell, shares a link, and recipients claim from that packet until it is exhausted or expires. If the packet expires before all claims are taken, the sender can reclaim the remainder

\n
\n

\"image\"
image1405×892 127 KB

\n

For now, this is a solo-built project. I have tried to keep the architecture small, inspectable, and easy to maintain without requiring a large ops or protocol team.

\n

Problem and Solution

\n

The problem

\n

Sending tokens on-chain is usually transactional, but not ceremonial. Red packets are social. They are meant to be shared into a group, opened by multiple recipients, and claimed with a sense of timing, surprise, and urgency.

\n

Most wallet transfer flows do not capture that behavior well. They support “send X to Y,” but not:

\n\n

The solution

\n

pckt models the packet as a single live CKB cell governed by a custom lock script. Instead of keeping packet state off-chain, every claim consumes the packet cell and produces its next version. That lets the chain remain the source of truth while the frontend and backend make the experience feel native.

\n

Hosted solution: https://sendpckt.robaireth.dev
\nRepo: GitHub - RobaireTH/pckt: The friendliest way to send CKB · GitHub

\n

The core user flow is:

\n
    \n
  1. \n

    Sender seals a packet on-chain.

    \n
    2. \n
  2. \n

    Sender shares a claim link.

    \n
    3. \n
  3. \n

    Recipients claim against the packet cell.

    \n
    4. \n
  4. \n

    The packet shrinks as claims happen.

    \n
    5. \n
  5. \n

    If claims are exhausted, the packet terminates.

    \n
    6. \n
  6. \n

    If time expires first, the sender can reclaim the remainder.

    \n
    7. \n
\n

Technical Approaches and Design Decisions

\n

1. One contract, one packet cell

\n

The main design decision is that a packet is not an account, and it is not a backend object. It is a single live cell with explicit, serialized state.

\n

That gives a few advantages:

\n\n

2. Frontend signs the social flow, backend indexes the chain

\n

\"image\"
image805×1018 97.9 KB

\n
\"image\"
image1425×798 103 KB

\n

The system is split into three parts:

\n\n

The backend is intentionally non-authoritative. It does not hold keys, does not create truth, and can be replaced. Its role is to index packet state, provide sender/claimer views, short links, and live UX data.

\n

3. Claim links put the secret in the fragment

\n

The claim secret lives in the URL fragment, not in backend storage. That means the browser can hold the secret client-side while the backend only sees the public short-link target. This is an important design boundary: the server helps with UX, but it should not become a custody or secret-management layer.

\n

4. Testnet-first, with deliberate constraints

\n

I explicitly kept this testnet-first and avoided pretending every mode is ready for production. In particular:

\n\n

CKB Ecosystem Relevance

\n

pckt is relevant to CKB because it leans into what cells are good at:

\n\n

I believe it’s of benefit to the wider ecosystem as it is a good initiative to introduce people to the Nervos CKB by bringing in centuries old traditions onchain. A simple sharing of love!
\n

\"image\"
image1282×1211 207 KB

\n

Deployment Architecture

\n

Current deployment shape:

\n\n

The backend runs as:

\n\n

The frontend is configured by environment variables with:

\n\n

Security Considerations

\n

1. Self-custody

\n

Funds are locked on-chain. The backend never has authority to move them.

\n

2. Non-authoritative backend

\n

The backend is replaceable and should be treated as UX infrastructure, not a trust anchor. It’s even the contract that rejects multiple claims, not the backend.

\n

3. Claim secret handling

\n

The claim secret sits in the URL fragment so it is not automatically sent to servers. This avoids a major class of accidental backend custody.

\n

4. Reorg and index correctness

\n

The backend includes reorg handling and block-hash rollback logic because packet state derived from chain history must survive reorgs cleanly.

\n

5. Explicitly bounded feature set

\n

I do not want unsafe “it sort of works” behavior around payout math or reclaim timing. Where a mode looks questionable, I prefer to restrict it until it is clean.

\n

Why I Don’t Like the Maths Behind Lucky Splits For Now

\n

I do not dislike the idea of lucky splits. I dislike the current math and operational risk profile of lucky splits in this implementation.

\n

The problem is: once you move from fixed shares to random shares, you need to guarantee that:

\n\n

That is easy to get subtly wrong.

\n

In practice, lucky mode becomes a product-security problem, not just a product-design problem. If the random lower bound is too low, you can create unclaimable outputs. If the reservation math is too optimistic, you can strand capacity. If frontend prediction diverges from contract math, users get misleading expectations.

\n

For now, I prefer the stricter stance:

\n\n

I would rather disappoint users with a disabled mode than lock them into a half-correct one.

\n

Maintenance Plan

\n

I plan to use this Talk Nervos thread itself as part of the maintenance loop.

\n

Specifically:

\n\n

The near-term maintenance priorities are:

\n
    \n
  1. \n

    stabilize sender/claimer UX

    \n
    2. \n
  2. \n

    keep reclaim flow reliable and understandable

    \n
    3. \n
  3. \n

    tighten profile/name semantics

    \n
    4. \n
  4. \n

    revisit lucky split math only when it is safe

    \n
    5. \n
  5. \n

    continue testnet usage before thinking seriously about mainnet

    \n
    6. \n
\n

Closing

\n

pckt is an attempt to build something small, social, and unmistakably native to CKB’s cell model. It is not trying to be a generic wallet feature (Though it can be). It is trying to make a familiar ritual feel right on-chain.

\n

If that resonates, I’d love feedback moat importantly on whether the identity layer should remain simple or move toward a more formal DID-based model later.

\n
\n

ZH

\n
\n

pckt 是一个类似红包的 CKB 应用。发送者将 CKB 封装成一个链上数据包，分享一个链接，接收者可以从该数据包中认领代币，直到数据包耗尽或过期。如果数据包在所有代币被认领之前过期，发送者可以重新认领剩余的代币。

\n

\"image\"
image1405×892 127 KB

\n

目前，这是一个由我独立开发的项目。我努力保持架构的简洁、易于检查和维护，无需庞大的运维或协议团队。

\n

问题与解决方案

\n

问题

\n

链上发送代币通常是交易性的，但缺乏仪式感。红包则具有社交性。它们应该被分享给一群人，由多个接收者打开，并以一种带有时机感、惊喜感和紧迫感的方式认领。

\n

大多数钱包的转账流程都无法很好地体现这种行为。他们支持“向 Y 发送 X”，但不支持：

\n\n

解决方案

\n

pckt 将数据包建模为由自定义锁定脚本控制的“单个活跃 CKB 单元”。数据包状态并非保存在链下，而是每次声明都会消耗数据包单元并生成其下一个版本。这使得链始终保持真实性，同时前端和后端提供原生体验。

\n

托管解决方案：https://sendpckt.robaireth.dev

\n

代码库：GitHub - RobaireTH/pckt: The friendliest way to send CKB · GitHub

\n

核心用户流程如下：

\n
    \n
  1. \n

    发送方在链上密封数据包。

    \n
    2. \n
  2. \n

    发送方共享声明链接。

    \n
    3. \n
  3. \n

    接收方针对数据包单元进行声明。

    \n
    4. \n
  4. \n

    随着声明的进行，数据包会逐渐缩小。

    \n
    5. \n
  5. \n

    如果所有请求权都已用尽，则数据包终止。

    \n
    6. \n
  6. \n

    如果时间先到期，发送方可以重新获取剩余的请求权。

    \n
    7. \n
\n

技术方案和设计决策

\n

1. 一个合约，一个数据包单元

\n

主要的设计决策是：数据包不是账户，也不是后端对象。它是一个具有明确序列化状态的“单个活动单元”。

\n

这带来了一些优势：

\n\n

2. 前端对社交流进行签名，后端对链进行索引

\n

\"image\"
image805×1018 97.9 KB

\n

\"image\"
image1425×798 103 KB

\n

该系统分为三个部分：

\n\n

后端有意设计为非权威。它不持有密钥，不创造真理，并且可以被替换。它的作用是索引数据包状态，提供发送方/声明方视图、短链接和实时用户体验数据。

\n

3. 声明链接将密钥放在片段中

\n

声明密钥存储在 URL 片段中，而不是后端存储中。这意味着浏览器可以在客户端持有密钥，而后端只能看到公开的短链接目标。这是一个重要的设计边界：服务器有助于用户体验，但不应成为密钥保管层或密钥管理层。

\n

4. 测试网优先，并设定了明确的限制

\n

我特意坚持测试网优先的原则，避免假装所有模式都已准备好用于生产环境。具体而言：

\n\n

CKB 生态系统相关性

\n

pckt 与 CKB 的相关性在于它充分利用了 Cell 的优势：

\n\n

我相信这对整个生态系统都有益处，因为它是一个很好的举措，通过将几个世纪以来的传统引入链上，向人们介绍 Nervos CKB。这是一种简单的分享！

\n

\"image\"
image1282×1211 207 KB

\n

部署架构

\n

当前部署结构：

\n\n

后端运行方式如下：

\n\n

前端通过环境变量配置，包括：

\n\n

安全注意事项

\n

1. 自保

\n

资金锁定在链上。后端无权移动资金。

\n

2. 非权威后端

\n

后端是可替换的，应该被视为用户体验基础设施，而不是信任锚点。甚至拒绝多个声明的也是合约，而不是后端。

\n

3. 声明密钥处理

\n

声明密钥位于 URL 片段中，因此不会自动发送到服务器。这避免了一类主要的意外后端保管风险。

\n

4. 重组和索引正确性

\n

后端包含重组处理和区块哈希回滚逻辑，因为从链历史中派生的包状态必须在重组后保持完好。

\n

5. 明确限定的功能集

\n

我不希望在支付计算或回收时间方面出现不安全的“勉强能用”的行为。如果某个模式看起来有问题，我倾向于限制它，直到它变得安全为止。

\n

为什么我目前不喜欢幸运分割背后的数学原理

\n

我并不反对幸运分割的想法。我不喜欢当前实现中“幸运拆分”的数学原理和操作风险。

\n

问题在于：一旦从固定份额改为随机份额，就需要保证：

\n\n

这一点很容易出现细微的错误。

\n

实际上，“幸运模式”会演变成产品安全问题，而不仅仅是产品设计问题。如果随机下限设置得太低，可能会导致无法认领的输出结果。如果预留计算过于乐观，则可能导致资源闲置。如果前端预测与合同计算存在偏差，则会产生误导性的预期。

\n

目前，我倾向于采取更严格的立场：

\n\n

我宁愿禁用该模式让用户失望，也不愿让他们使用一个半真半假的模式。

\n

维护计划

\n

我计划将此 Talk Nervos 讨论帖本身作为维护流程的一部分。

\n

具体来说：

\n\n

近期维护重点如下：

\n
    \n
  1. \n

    稳定发送方/领取方的用户体验

    \n
    2. \n
  2. \n

    保持回收流程的可靠性和易懂性

    \n
    3. \n
  3. \n

    完善个人资料/名称语义

    \n
    4. \n
  4. \n

    仅在安全的情况下重新审视幸运拆分算法

    \n
    5. \n
  5. \n

    在认真考虑主网之前，继续使用测试网

    \n
    6. \n
\n

结束语

\n

pckt 旨在构建一个小型、社交化且与 CKB 的 cell 模型完美契合的原生应用。它并非旨在成为一个通用的钱包功能（尽管它也可以做到）。它的目标是让熟悉的仪式感在链上自然流畅地呈现。

\n

如果这引起了您的共鸣，我非常希望收到反馈，尤其希望了解身份层是否应该保持简单，还是应该在未来转向更正式的基于 DID 的模型。

", "like_count": 0, "quote_count": 0 }, { "post_id": 24088, "post_number": 2, "topic_id": 10220, "topic_title": "Pckt: A Friendly Way to Send CKB | pckt：一种友好的发送 CKB 的方式", "topic_slug": "pckt-a-friendly-way-to-send-ckb-pckt-ckb", "author": "Yeti", "created_at": "2026-04-30T21:26:58.163000+00:00", "updated_at": "2026-04-30T21:26:58.163000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/pckt-a-friendly-way-to-send-ckb-pckt-ckb/10220/2", "content_text": "Hi @RobaireTH, I’m not trying to put your project down here, but just wanted to bring up that something very similar (in concept at least) has already been developed a couple of years ago by a member here @yixiu.ckbfans.bit.\nhttps://joygift.cc/", "content_html": "

Hi @RobaireTH, I’m not trying to put your project down here, but just wanted to bring up that something very similar (in concept at least) has already been developed a couple of years ago by a member here @yixiu.ckbfans.bit.

\n

https://joygift.cc/

", "like_count": 0, "quote_count": 0 }, { "post_id": 24089, "post_number": 3, "topic_id": 10220, "topic_title": "Pckt: A Friendly Way to Send CKB | pckt：一种友好的发送 CKB 的方式", "topic_slug": "pckt-a-friendly-way-to-send-ckb-pckt-ckb", "author": "RobaireTH", "created_at": "2026-05-01T02:18:46.170000+00:00", "updated_at": "2026-05-01T02:18:46.170000+00:00", "reply_to_post_number": 2, "url": "https://talk.nervos.org/t/pckt-a-friendly-way-to-send-ckb-pckt-ckb/10220/3", "content_text": "Thanks @Yeti for brinnging this up., and, yeah, I don’t taje ut as putting the project down.\nI checked out JoyGift and could see there’s overlap across concepts (wrapping of gift, splits and reclaim policies). JoyGift is JoyID Oriented/native while what I’m exploring with pckt is a more contract-centric and self-custodial model where the packet itself is treated as an on-chain state object, claims/reclaims are explicit chain transitions, and the backend is intentionally non-authoritative.\nWhile I acknowledge this, I will like to not see it as ‘the same project already exists’ but as a real use case builders in the ecosystem found worth exploring on CKB.\nOnce again, I appreciate the pointer. I will look more closely at JoyGift and learn from their implementation. Seems they got the lucky splits right while I’m still sitting at math. @yixiu.ckbfans.bit ,kudos", "content_html": "

Thanks @Yeti for brinnging this up., and, yeah, I don’t taje ut as putting the project down.

\n

I checked out JoyGift and could see there’s overlap across concepts (wrapping of gift, splits and reclaim policies). JoyGift is JoyID Oriented/native while what I’m exploring with pckt is a more contract-centric and self-custodial model where the packet itself is treated as an on-chain state object, claims/reclaims are explicit chain transitions, and the backend is intentionally non-authoritative.

\n

While I acknowledge this, I will like to not see it as ‘the same project already exists’ but as a real use case builders in the ecosystem found worth exploring on CKB.

\n

Once again, I appreciate the pointer. I will look more closely at JoyGift and learn from their implementation. Seems they got the lucky splits right while I’m still sitting at math. @yixiu.ckbfans.bit ,kudos \":flexed_biceps:\"

", "like_count": 0, "quote_count": 0 }, { "post_id": 24092, "post_number": 4, "topic_id": 10220, "topic_title": "Pckt: A Friendly Way to Send CKB | pckt：一种友好的发送 CKB 的方式", "topic_slug": "pckt-a-friendly-way-to-send-ckb-pckt-ckb", "author": "Yeti", "created_at": "2026-05-01T06:46:59.328000+00:00", "updated_at": "2026-05-01T06:46:59.328000+00:00", "reply_to_post_number": 3, "url": "https://talk.nervos.org/t/pckt-a-friendly-way-to-send-ckb-pckt-ckb/10220/4", "content_text": "Hi mate, yeah, I’m happy someone is going to carry this concept forward, I like it.\nI used Joygift a lot when the Joyid Telegram was really active, mostly with people outside the CKB ecosystem so it was a great way to introduce new users to CKB by gifting them tokens and the gamified ‘race’ to claim the gifts made it fun!\nAlso, because of CKB’s storage requirements, I think this sort of thing could be used in some interesting marketing ways to entice users outside of CKB to take part in things like token airdrops and DOB mints where they also need small amounts of CKB to store these assets.", "content_html": "

Hi mate, yeah, I’m happy someone is going to carry this concept forward, I like it.

\n

I used Joygift a lot when the Joyid Telegram was really active, mostly with people outside the CKB ecosystem so it was a great way to introduce new users to CKB by gifting them tokens and the gamified ‘race’ to claim the gifts made it fun!

\n

Also, because of CKB’s storage requirements, I think this sort of thing could be used in some interesting marketing ways to entice users outside of CKB to take part in things like token airdrops and DOB mints where they also need small amounts of CKB to store these assets.

", "like_count": 0, "quote_count": 0 }, { "post_id": 24099, "post_number": 5, "topic_id": 10220, "topic_title": "Pckt: A Friendly Way to Send CKB | pckt：一种友好的发送 CKB 的方式", "topic_slug": "pckt-a-friendly-way-to-send-ckb-pckt-ckb", "author": "joshyates1980", "created_at": "2026-05-01T15:55:22.939000+00:00", "updated_at": "2026-05-01T15:55:22.939000+00:00", "reply_to_post_number": 4, "url": "https://talk.nervos.org/t/pckt-a-friendly-way-to-send-ckb-pckt-ckb/10220/5", "content_text": "Yes, introducing CKB with pckt would be a great addition to the Nervos ecosystem whereas most of my CKB gifts through Joy had their limitations (for personal reasons), but pckt appears to have a more solid approach and the clean UI finishes off a nice polish.", "content_html": "

Yes, introducing CKB with pckt would be a great addition to the Nervos ecosystem whereas most of my CKB gifts through Joy had their limitations (for personal reasons), but pckt appears to have a more solid approach and the clean UI finishes off a nice polish.

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10224, "title": "Feature Preview: `moves` in CellScript", "slug": "feature-preview-moves-in-cellscript", "url": "https://talk.nervos.org/t/feature-preview-moves-in-cellscript/10224", "created_at": "2026-05-01T15:34:27.229000+00:00", "last_posted_at": "2026-05-01T15:34:27.304000+00:00", "category_id": 49, "tags": [ "CKB-VM", "CellScript" ], "posters": [ "Original Poster, Most Recent Poster" ], "recent_posts": [ { "post_id": 24098, "post_number": 1, "topic_id": 10224, "topic_title": "Feature Preview: `moves` in CellScript", "topic_slug": "feature-preview-moves-in-cellscript", "author": "ArthurZhang", "created_at": "2026-05-01T15:34:27.304000+00:00", "updated_at": "2026-05-01T17:25:17.156000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/feature-preview-moves-in-cellscript/10224/1", "content_text": "Hi, community,\nThank you again for the feedback after last week’s early CellScript preview: CellScript: A DSL for cell-based contracts.\nThe comments were genuinely useful, especially around one boundary: protocol verification logic vs. business workflow.\nThis post is a current 0.13 direction update focused on state transitions, written to match what the implementation supports today.\nState should be visible. Transitions should be explicit. Compiler magic should not mutate your Molecule evidence layout behind your back.\nWhat CellScript is trying to model\nOn CKB, a contract validates a transaction-level transformation: input cells are consumed, output cells are created, and the script checks whether that transformation is allowed.\nSo in CellScript, an action is a protocol verifier case, not a UI step and not a business workflow task.\nExamples of protocol verbs:\naccept: live offer → filled offer\ncancel: live offer → cancelled offer\nclaim: open receipt → claimed receipt\nrelease: locked asset → released asset\n0.13 syntax: explicit state as data\nState is explicit in the resource data:\nenum OfferState {\nCreated,\nLive,\nFilled,\nCancelled,\nExpired,\n}\nresource Offer {\nstate: OfferState,\nseller: Bytes32,\nbuyer: Bytes32,\nprice: u128,\n}\nImportant: enum order gives encoding identity, not lifecycle destiny.\nLive, Filled, Cancelled are names of variants, not an implied linear flow.\n0.13 transition model: declared graph + action-level moves\nIn current implementation, allowed edges are declared explicitly:\nstate_machine OfferFlow for Offer.state {\nLive -> Filled by accept;\nLive -> Cancelled by cancel;\nLive -> Expired by expire;\n}\nThen each action binds to one edge with moves in the action header:\naction accept(input: Offer)\nmoves input.state Live -> Filled\n{\nconsume input\ncreate Offer {\nstate: OfferState::Filled,\nseller: input.seller,\nbuyer: tx.signer(),\nprice: input.price,\n}\n// explicit guards/invariants\n// require ...\n}\nAnother action can bind another edge:\naction cancel(input: Offer)\nmoves input.state Live -> Cancelled\n{\nconsume input\ncreate Offer {\nstate: OfferState::Cancelled,\nseller: input.seller,\nbuyer: input.buyer,\nprice: input.price,\n}\n// explicit guards/invariants\n// require ...\n}\nThis keeps transition intent close to the verifier case that justifies it.\nWhat require is for (and why it still matters)\nmoves is narrow: it encodes the state edge.\nrequire remains the main tool for proof obligations such as:\nauthorization (signed_by(...), signer checks)\nfield preservation / anti-tamper invariants\nnumeric bounds and timing constraints\ncross-cell relationships and conservation checks\nIn short:\nmoves = transition edge\nrequire = guards and invariants\nBoth are needed.\nWhat this design intentionally avoids\nCurrent direction is explicitly not:\nhidden lifecycle field injection\nautomatic Molecule layout mutation\nschema-hidden workflow machinery\n“business process engine” semantics in the verifier DSL\nCKB cell data is verifier evidence. Keeping the data surface explicit is a core auditability goal.\nPerformance posture\nmoves is intended to be low-overhead and predictable.\nIt should compile to straightforward transition validation, without hidden runtime workflow machinery.\nTo stay precise: we should avoid claiming cycle-equivalence to any specific handwritten pattern in all cases, because generated checks may include transition/range validation around consumed/created state.\nDirection: explicit, transparent, cost-conscious.\n0.13 direction summary\nFor 0.13, the working direction is:\nexplicit enum-based state fields in cell data\nexplicit transition graph declaration (state_machine Type.field { ... })\naction-level moves binding one verifier action to one declared edge\nexplicit require guards/invariants\nno hidden state injection\nno Molecule layout mutation\nno general business workflow DSL\nState is data. Transition is policy. Guard is proof.\nThis is still a preview direction, not final doctrine.\nIf you have a real CKB protocol where this model causes major boilerplate or audit friction, I would really like to see that example.", "content_html": "

Hi, community,

\n

Thank you again for the feedback after last week’s early CellScript preview: CellScript: A DSL for cell-based contracts.
\nThe comments were genuinely useful, especially around one boundary: protocol verification logic vs. business workflow.

\n

This post is a current 0.13 direction update focused on state transitions, written to match what the implementation supports today.

\n
\n

State should be visible. Transitions should be explicit. Compiler magic should not mutate your Molecule evidence layout behind your back.

\n
\n
\n

What CellScript is trying to model

\n

On CKB, a contract validates a transaction-level transformation: input cells are consumed, output cells are created, and the script checks whether that transformation is allowed.

\n

So in CellScript, an action is a protocol verifier case, not a UI step and not a business workflow task.

\n

Examples of protocol verbs:

\n\n
\n

0.13 syntax: explicit state as data

\n

State is explicit in the resource data:

\n
enum OfferState {\n    Created,\n    Live,\n    Filled,\n    Cancelled,\n    Expired,\n}\n\nresource Offer {\n    state: OfferState,\n    seller: Bytes32,\n    buyer: Bytes32,\n    price: u128,\n}\n
\n

Important: enum order gives encoding identity, not lifecycle destiny.
\nLive, Filled, Cancelled are names of variants, not an implied linear flow.

\n
\n

0.13 transition model: declared graph + action-level moves

\n

In current implementation, allowed edges are declared explicitly:

\n
state_machine OfferFlow for Offer.state {\n    Live -> Filled by accept;\n    Live -> Cancelled by cancel;\n    Live -> Expired by expire;\n}\n
\n

Then each action binds to one edge with moves in the action header:

\n
action accept(input: Offer)\n    moves input.state Live -> Filled\n{\n    consume input\n    create Offer {\n        state: OfferState::Filled,\n        seller: input.seller,\n        buyer: tx.signer(),\n        price: input.price,\n    }\n\n    // explicit guards/invariants\n    // require ...\n}\n
\n

Another action can bind another edge:

\n
action cancel(input: Offer)\n    moves input.state Live -> Cancelled\n{\n    consume input\n    create Offer {\n        state: OfferState::Cancelled,\n        seller: input.seller,\n        buyer: input.buyer,\n        price: input.price,\n    }\n\n    // explicit guards/invariants\n    // require ...\n}\n
\n

This keeps transition intent close to the verifier case that justifies it.

\n
\n

What require is for (and why it still matters)

\n

moves is narrow: it encodes the state edge.
\nrequire remains the main tool for proof obligations such as:

\n\n

In short:

\n\n

Both are needed.

\n
\n

What this design intentionally avoids

\n

Current direction is explicitly not:

\n\n

CKB cell data is verifier evidence. Keeping the data surface explicit is a core auditability goal.

\n
\n

Performance posture

\n

moves is intended to be low-overhead and predictable.
\nIt should compile to straightforward transition validation, without hidden runtime workflow machinery.

\n

To stay precise: we should avoid claiming cycle-equivalence to any specific handwritten pattern in all cases, because generated checks may include transition/range validation around consumed/created state.

\n

Direction: explicit, transparent, cost-conscious.

\n
\n

0.13 direction summary

\n

For 0.13, the working direction is:

\n\n
\n

State is data. Transition is policy. Guard is proof.

\n
\n

This is still a preview direction, not final doctrine.
\nIf you have a real CKB protocol where this model causes major boilerplate or audit friction, I would really like to see that example.

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10216, "title": "Streamlining the forum categories needs your testing and feedback", "slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216", "created_at": "2026-04-29T19:34:39.105000+00:00", "last_posted_at": "2026-05-01T13:00:28.841000+00:00", "category_id": 40, "tags": [], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24085, "post_number": 6, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "terrytai", "created_at": "2026-04-30T19:50:46.431000+00:00", "updated_at": "2026-04-30T20:36:43.584000+00:00", "reply_to_post_number": 2, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/6", "content_text": "@RetricSu 和 @janx （ @ArthurZhang 的问题也是相关的）都提到了 Development vs Applications & Ecosystem 的问题, 看来这组名字的确比较让人疑惑。我解释一下背后的初衷，然后我们再做选择。\nDevelopment 和 Applications & Ecosystem 在设计时的考虑是，Development 分类是承接所有开发相关的话题的，无论它是什么层次。所以可以大致理解为是按照受众来分的，比如典型的应该放在 Development 分类里的贴子：\nA Small Work to Make CKB Development Resources More Accessible\nIntroducing a Stealth Address Lock Script + Wallet Demo for CKB\nCellScript 0.1 - A DSL for Cell-Based Contracts\nxUDT Information Convention RFC\n而 Applications & Ecosystem 是针对使用者的分类， 这类事典型的应该放在此分类的话题：\nWallet not Syncing （用户求助，钱包同步不上）\nCan’t connect Ledger Nano X with Neuron wallet （用户报告：硬件钱包连不上）\nWhat wallet can I use in the United States for CKB? （用户咨询：在美国能用什么钱包）\nPassword error Neuron Wallet （用户求助：登录密码错误 ）\nNeuron wallet - seed phrase （用户求助：助记词找回）\n所以在这个分类方式的前提下，我们可以 brain storm 一对新名字？这里我给一些我觉得的可能：\nBuilding on CKB vs Using CKB\nBuilders vs Ecosystem\nBuild & Develop vs Use & Discuss\n又或者大家听了我的解释，会觉得原先的设计（Development vs Applications & Ecosystem）更好？只是需要更好的分类描述和指导。", "content_html": "

@RetricSu 和 @janx （ @ArthurZhang 的问题也是相关的）都提到了 Development vs Applications & Ecosystem 的问题, 看来这组名字的确比较让人疑惑。我解释一下背后的初衷，然后我们再做选择。

\n

Development 和 Applications & Ecosystem 在设计时的考虑是，Development 分类是承接所有开发相关的话题的，无论它是什么层次。所以可以大致理解为是按照受众来分的，比如典型的应该放在 Development 分类里的贴子：

\n\n

而 Applications & Ecosystem 是针对使用者的分类， 这类事典型的应该放在此分类的话题：

\n\n

所以在这个分类方式的前提下，我们可以 brain storm 一对新名字？这里我给一些我觉得的可能：

\n
    \n
  1. Building on CKB vs Using CKB
    2. \n
  2. Builders vs Ecosystem
    3. \n
  3. Build & Develop vs Use & Discuss
    4. \n
\n

又或者大家听了我的解释，会觉得原先的设计（Development vs Applications & Ecosystem）更好？只是需要更好的分类描述和指导。

", "like_count": 0, "quote_count": 0 }, { "post_id": 24086, "post_number": 7, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "terrytai", "created_at": "2026-04-30T19:57:13.437000+00:00", "updated_at": "2026-04-30T20:04:04.745000+00:00", "reply_to_post_number": 3, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/7", "content_text": "关于 Community Space 的反馈, 我比较认同，确实有这个问题。\n但你说的 DAOs 感觉有点窄和不准确，因为不一定都是 DAO, 可以是其他的 program, 比如更中心化的 grants 甚至是浮华都可以在这里开设子分类。\n目前认为 DAOs & Programs 可能更好。", "content_html": "

关于 Community Space 的反馈, 我比较认同，确实有这个问题。

\n

但你说的 DAOs 感觉有点窄和不准确，因为不一定都是 DAO, 可以是其他的 program, 比如更中心化的 grants 甚至是浮华都可以在这里开设子分类。

\n

目前认为 DAOs & Programs 可能更好。

", "like_count": 0, "quote_count": 0 }, { "post_id": 24087, "post_number": 8, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "terrytai", "created_at": "2026-04-30T20:22:51.851000+00:00", "updated_at": "2026-04-30T20:32:47.317000+00:00", "reply_to_post_number": 2, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/8", "content_text": "Theory & Design — 加密经济学与机制设计\n这一条反馈也很好，我也是先想到中文，然后反推英文的，的确有点抽象了。\n关于英文名，我这里也脑爆一下替代方案：\nCryptoeconomics & Mechanism Design\nCryptoeconomics & Protocol Design\nProtocol Research\nTokenomics & Protocol Design", "content_html": "
\n

Theory & Design — 加密经济学与机制设计

\n
\n

这一条反馈也很好，我也是先想到中文，然后反推英文的，的确有点抽象了。

\n

关于英文名，我这里也脑爆一下替代方案：

\n
    \n
  1. Cryptoeconomics & Mechanism Design
    2. \n
  2. Cryptoeconomics & Protocol Design
    3. \n
  3. Protocol Research
    4. \n
  4. Tokenomics & Protocol Design
    5. \n
", "like_count": 0, "quote_count": 0 }, { "post_id": 24093, "post_number": 9, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "yifenzi", "created_at": "2026-05-01T06:49:10.462000+00:00", "updated_at": "2026-05-01T07:02:32.153000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/9", "content_text": "关于设立“个人专贴”的建议\n借此论坛即将改版的契机，我建议设立“个人专贴”，对达到一定要求的会员开放，初期可以仅对公认的核心社区成员开放，然后慢慢放开\n“个人专贴”的定义:即某个贴子只属于某个人，只有他有发贴回贴权限，其他人为只读权限\n“个人专贴”的内容:开发者可以整理自己开发的相关项目或案例，一些新的思考或方向以及其他相关信息；非开发人员也可以发布自己的思考，以及提供一些点子供人参考，这也是一种参与和建设；项目方特别是新的项目方可以发布最新的公告信息或者对论坛成员特别的早期信息以吸引第一批用户和关注\n“个人专贴”的意义:提高部分高阶成员的归属感和荣誉感，更多的把价值沉淀在论坛，提高论坛在整个生态的软性竞争力\n“个人专贴”的方式:在某个分区下开辟一个特区，把所有个人专贴放入即可，个人专贴只是某个人能发贴和回复非版主权限(如果程序不支持这种设置，就只能启用子板块和对应的版主权限，这也一定程度可控)\n此计划投入少未知因素可控带来的利好可观，论坛管理团队可尝试看看效果", "content_html": "

关于设立“个人专贴”的建议

\n

借此论坛即将改版的契机，我建议设立“个人专贴”，对达到一定要求的会员开放，初期可以仅对公认的核心社区成员开放，然后慢慢放开

\n

“个人专贴”的定义:即某个贴子只属于某个人，只有他有发贴回贴权限，其他人为只读权限

\n

“个人专贴”的内容:开发者可以整理自己开发的相关项目或案例，一些新的思考或方向以及其他相关信息；非开发人员也可以发布自己的思考，以及提供一些点子供人参考，这也是一种参与和建设；项目方特别是新的项目方可以发布最新的公告信息或者对论坛成员特别的早期信息以吸引第一批用户和关注

\n

“个人专贴”的意义:提高部分高阶成员的归属感和荣誉感，更多的把价值沉淀在论坛，提高论坛在整个生态的软性竞争力

\n

“个人专贴”的方式:在某个分区下开辟一个特区，把所有个人专贴放入即可，个人专贴只是某个人能发贴和回复非版主权限(如果程序不支持这种设置，就只能启用子板块和对应的版主权限，这也一定程度可控)

\n

此计划投入少未知因素可控带来的利好可观，论坛管理团队可尝试看看效果

", "like_count": 0, "quote_count": 0 }, { "post_id": 24094, "post_number": 10, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "ArthurZhang", "created_at": "2026-05-01T10:32:02.796000+00:00", "updated_at": "2026-05-01T10:32:02.796000+00:00", "reply_to_post_number": 9, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/10", "content_text": "I quite like this direction, provided we keep its ambitions modest.\nOne small concern is that Nervos Talk is not yet suffering from the terrible curse of excessive traffic. So before we build too many elegant little rooms, we should probably make sure there are enough people in the house.\nTo me, a project log / builder log would work best as a lightweight continuity layer, not as a separate discussion silo. It could be used for milestones, design notes, progress updates, RFC links, test results, and retrospectives. But broader debate, support questions, grant discussion, governance discussion, and ecosystem feedback should still live in the normal public categories.\nIn other words, the log probably should not become a private chapel for one’s own project. It should be more like a well-kept index, changelog, and map, of a place that preserves context, then points people back to the actual rooms where conversation happens.\nThat would give long-running work a bit more memory, without further thinning out the already rather precious forum traffic.", "content_html": "

I quite like this direction, provided we keep its ambitions modest.

\n

One small concern is that Nervos Talk is not yet suffering from the terrible curse of excessive traffic. So before we build too many elegant little rooms, we should probably make sure there are enough people in the house.

\n

To me, a project log / builder log would work best as a lightweight continuity layer, not as a separate discussion silo. It could be used for milestones, design notes, progress updates, RFC links, test results, and retrospectives. But broader debate, support questions, grant discussion, governance discussion, and ecosystem feedback should still live in the normal public categories.

\n

In other words, the log probably should not become a private chapel for one’s own project. It should be more like a well-kept index, changelog, and map, of a place that preserves context, then points people back to the actual rooms where conversation happens.

\n

That would give long-running work a bit more memory, without further thinning out the already rather precious forum traffic.

", "like_count": 0, "quote_count": 0 }, { "post_id": 24096, "post_number": 11, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "yifenzi", "created_at": "2026-05-01T11:24:48.599000+00:00", "updated_at": "2026-05-01T11:24:48.599000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/11", "content_text": "一点关于“个人专贴”定位的补充\n已有的常规讨论是正常进行是主要承载形式，个人专贴是补充性的提炼性的总结性的\n如果把每个人在论坛的活动看作一本书，那么个人专贴就是书的封面和目录，更具体的说专贴一楼是封面，后面的是目录，可以随时修改让一楼甚至可以担当起“个人公告”的用途\n在论坛搜索个人账户也能找到相关信息，但一个是被动的零散的冰冷的，一个是主动的概括的带有情感的\n数量肯定需要控制，人手一个就失去了意义，“度”的把握需要在实践中来体现\n这个新角色的引入也可以看作在论坛管理版主和普通会员之外的关于社团治理的尝试", "content_html": "

一点关于“个人专贴”定位的补充

\n

已有的常规讨论是正常进行是主要承载形式，个人专贴是补充性的提炼性的总结性的

\n

如果把每个人在论坛的活动看作一本书，那么个人专贴就是书的封面和目录，更具体的说专贴一楼是封面，后面的是目录，可以随时修改让一楼甚至可以担当起“个人公告”的用途

\n

在论坛搜索个人账户也能找到相关信息，但一个是被动的零散的冰冷的，一个是主动的概括的带有情感的

\n

数量肯定需要控制，人手一个就失去了意义，“度”的把握需要在实践中来体现

\n

这个新角色的引入也可以看作在论坛管理版主和普通会员之外的关于社团治理的尝试

", "like_count": 0, "quote_count": 0 }, { "post_id": 24097, "post_number": 12, "topic_id": 10216, "topic_title": "Streamlining the forum categories needs your testing and feedback", "topic_slug": "streamlining-the-forum-categories-needs-your-testing-and-feedback", "author": "woodbury.bit", "created_at": "2026-05-01T13:00:28.841000+00:00", "updated_at": "2026-05-01T13:07:51.926000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/streamlining-the-forum-categories-needs-your-testing-and-feedback/10216/12", "content_text": "(post deleted by author)", "content_html": "

(post deleted by author)

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10221, "title": "Revamping and Refactoring the CKB Wallet Connection Experience: A Modular Compound Component for React Developers", "slug": "revamping-and-refactoring-the-ckb-wallet-connection-experience-a-modular-compound-component-for-react-developers", "url": "https://talk.nervos.org/t/revamping-and-refactoring-the-ckb-wallet-connection-experience-a-modular-compound-component-for-react-developers/10221", "created_at": "2026-04-30T19:28:31.062000+00:00", "last_posted_at": "2026-04-30T19:28:31.123000+00:00", "category_id": 49, "tags": [ "CKB", "wallet" ], "posters": [ "Original Poster, Most Recent Poster" ], "recent_posts": [ { "post_id": 24084, "post_number": 1, "topic_id": 10221, "topic_title": "Revamping and Refactoring the CKB Wallet Connection Experience: A Modular Compound Component for React Developers", "topic_slug": "revamping-and-refactoring-the-ckb-wallet-connection-experience-a-modular-compound-component-for-react-developers", "author": "Victor_Okenwa", "created_at": "2026-04-30T19:28:31.123000+00:00", "updated_at": "2026-05-01T15:51:31.639000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/revamping-and-refactoring-the-ckb-wallet-connection-experience-a-modular-compound-component-for-react-developers/10221/1", "content_text": "Hi everyone,\nThe developer experience when integrating wallets is often a trade-off between speed and control. Standard “plug-and-play” components are fast to implement but difficult to style and control, while building from scratch is time-consuming and error-prone.\nTo bridge this gap for the Nervos ecosystem, I have refactored the CKB Wallet Connect component. This revamp focuses on a Compound Component pattern, specifically designed for React and CCC (Common Chain Connector) developers who need a seamless balance between sophisticated UX and developer flexibility.\n\n\n\n\n
\n\n\n
\n\n\nWhat’s New?\nCompound Component Architecture\nInstead of a single, rigid , the component is now broken down into modular sub-components (e.g., ConnectWalltetButton, ConnectWalletInfoImage, ConnectWalletInfoAddress, ConnectWalletInfoBalance). This allows developers to rearrange the UI or wrap specific parts in custom logic without breaking the internal state management.\nCustom styling control\nThe ConnectWallet components comes with it’s own default styling, but styling can be easily changed or customized by the developer. Using the className prop on all the above listed components, developers who want custom styling can easily apply tailwind classes to any component as desired. This was made possible by clsx and tailwind merge.\nHuman-Readable Financial Data\nSmall details significantly impact user trust. The component now natively handles currency formatting, including standard comma separators for balances. This ensures that users see “1,000 CKB” rather than a raw, hard-to-read string of digits.\nUnified State via CCC\nBy leveraging the CCC, the component maintains a robust connection state while abstracting away the boilerplate. Developers can now focus on their application logic rather than the edge cases of wallet handshakes.\nA Loading State\nLeveraged the animate pulse class from tailwindcss to show loading state while user’s data and details is being fetched. Users can now know when details are being fetched.\nBalance Decimal Places Control\nDevelopers can choose what amount of digits to show after the decimal point using the decimalPlaces prop on the . Only values of 0-20 is allowed as the number of decimal places. 1,080.78090909 becomes 1,080.7809 when decimal places is set to 4.\nAddress Truncation and Characters Control\nDevelopers can control what amount of characters from a user’s address would be shown. The ConnectWalletInfoAddress can take in this optional props - endChars and frontChars. These are used to control the amount of character that would be shown before and after an ellipsis i.e. .... It has a default of 10 characters as front characters and 6 for end characters. For example becomes ckt1q...3enuqqeax4g0\nCurrency Visibility\nDevelopers can choose to show or not to show the CKB text behind the user’s Balance.\nUsing the withCurrency prop on the ConnectWalletBalance component. It defaults to true when not set, which means the CKB text would show behind the balance by default. Implementation example: .\nWhy This Matters\nFor Developers: It drastically reduces development time. You no longer have to choose between a “black box” component that ruins your design or a two-week custom build. You get the logic for free and the UI control you deserve.\nFor Users: The experience is smoother and more professional. Polished details like formatted balances and predictable modal behaviors make dApps feel production-ready and reliable.\nFor the Ecosystem: Standardization around high-quality, flexible UI components lowers the barrier to entry for new builders coming to Nervos.\nGetting Started\nCheck out the live Demo and code on: https://ckb-connect-kit.vercel.app/\nAlso Read the documentation on: revamp-ckb-connect-wallet/ARCHITECTURE.md at main · Victor-Okenwa/revamp-ckb-connect-wallet · GitHub\nI’m eager to hear your thoughts on this pattern. Would this modular approach help your current workflow? I’m open to feedback and looking forward to seeing how we can continue to improve the tooling for the CKB community.\nBest, Victor Okenwa.", "content_html": "

Hi everyone,

\n

The developer experience when integrating wallets is often a trade-off between speed and control. Standard “plug-and-play” components are fast to implement but difficult to style and control, while building from scratch is time-consuming and error-prone.

\n

To bridge this gap for the Nervos ecosystem, I have refactored the CKB Wallet Connect component. This revamp focuses on a Compound Component pattern, specifically designed for React and CCC (Common Chain Connector) developers who need a seamless balance between sophisticated UX and developer flexibility.

\n
        <ConnectWallet>\n              <ConnectWalletButton />\n\n              <ConnectWalletInfoContainer className=\"flex gap-1\">\n\n                <ConnectWalletInfoImage />\n\n                <div className=\"flex flex-col gap-2\">\n                  <ConnectWalletInfoBalance withCurrency={false} />\n                  <ConnectWalletInfoAddress frontChars={5} endChars={12} />\n                </div>\n              </ConnectWalletInfoContainer>\n           </ConnectWallet>\n
\n

What’s New?

\n
    \n
  1. \n

    Compound Component Architecture

    \n

    Instead of a single, rigid <ConnectButton/>, the component is now broken down into modular sub-components (e.g., ConnectWalltetButton, ConnectWalletInfoImage, ConnectWalletInfoAddress, ConnectWalletInfoBalance). This allows developers to rearrange the UI or wrap specific parts in custom logic without breaking the internal state management.

    \n
    2. \n
  2. \n

    Custom styling control
    \nThe ConnectWallet components comes with it’s own default styling, but styling can be easily changed or customized by the developer. Using the className prop on all the above listed components, developers who want custom styling can easily apply tailwind classes to any component as desired. This was made possible by clsx and tailwind merge.

    \n
    3. \n
  3. \n

    Human-Readable Financial Data

    \n

    Small details significantly impact user trust. The component now natively handles currency formatting, including standard comma separators for balances. This ensures that users see “1,000 CKB” rather than a raw, hard-to-read string of digits.

    \n
    4. \n
  4. \n

    Unified State via CCC

    \n

    By leveraging the CCC, the component maintains a robust connection state while abstracting away the boilerplate. Developers can now focus on their application logic rather than the edge cases of wallet handshakes.

    \n
    5. \n
  5. \n

    A Loading State
    \nLeveraged the animate pulse class from tailwindcss to show loading state while user’s data and details is being fetched. Users can now know when details are being fetched.

    \n
    6. \n
  6. \n

    Balance Decimal Places Control
    \nDevelopers can choose what amount of digits to show after the decimal point using the decimalPlaces prop on the <ConnectWalletInfoBalance decimalPlaces={4} />. Only values of 0-20 is allowed as the number of decimal places. 1,080.78090909 becomes 1,080.7809 when decimal places is set to 4.

    \n
    7. \n
  7. \n

    Address Truncation and Characters Control
    \nDevelopers can control what amount of characters from a user’s address would be shown. The ConnectWalletInfoAddress can take in this optional props - endChars and frontChars. These are used to control the amount of character that would be shown before and after an ellipsis i.e. .... It has a default of 10 characters as front characters and 6 for end characters. For example <ConnectWalletInfoAddressfrontChars={5}endChars={12} /> becomes ckt1q...3enuqqeax4g0

    \n
    8. \n
  8. \n

    Currency Visibility
    \nDevelopers can choose to show or not to show the CKB text behind the user’s Balance.
    \nUsing the withCurrency prop on the ConnectWalletBalance component. It defaults to true when not set, which means the CKB text would show behind the balance by default. Implementation example: <ConnectWalletInfoBalance withCurrency={false} />.

    \n
    9. \n
\n

Why This Matters

\n
    \n
  • \n

    For Developers: It drastically reduces development time. You no longer have to choose between a “black box” component that ruins your design or a two-week custom build. You get the logic for free and the UI control you deserve.

    \n
    • \n
  • \n

    For Users: The experience is smoother and more professional. Polished details like formatted balances and predictable modal behaviors make dApps feel production-ready and reliable.

    \n
    • \n
  • \n

    For the Ecosystem: Standardization around high-quality, flexible UI components lowers the barrier to entry for new builders coming to Nervos.

    \n
    • \n
\n

Getting Started

\n

Check out the live Demo and code on: https://ckb-connect-kit.vercel.app/
\nAlso Read the documentation on: revamp-ckb-connect-wallet/ARCHITECTURE.md at main · Victor-Okenwa/revamp-ckb-connect-wallet · GitHub

\n

I’m eager to hear your thoughts on this pattern. Would this modular approach help your current workflow? I’m open to feedback and looking forward to seeing how we can continue to improve the tooling for the CKB community.

\n

Best, Victor Okenwa.

", "like_count": 0, "quote_count": 0 } ] } ] }