fiberprobe 0.1.0 → 0.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +9 -5
- package/package.json +4 -4
package/README.md
CHANGED
|
@@ -1,8 +1,12 @@
|
|
|
1
|
-
#
|
|
1
|
+
# fiberprobe
|
|
2
2
|
|
|
3
3
|
A TypeScript SDK for Fiber Network Node (FNN) that answers the question every payment-channel application eventually asks: **will this payment actually go through?**
|
|
4
4
|
|
|
5
5
|
Built for the "Gone in 60ms" Fiber Network Infrastructure Hackathon, Category 2: Node, Routing & Diagnostics.
|
|
6
|
+
|
|
7
|
+
````bash
|
|
8
|
+
npm install fiberprobe
|
|
9
|
+
```
|
|
6
10
|
---
|
|
7
11
|
## The problem
|
|
8
12
|
|
|
@@ -10,7 +14,7 @@ Fiber, like Lightning, splits channel state into two categories. Total capacity
|
|
|
10
14
|
|
|
11
15
|
The result is that no RPC can honestly answer "can I pay this amount right now?" A `dry_run` flag exists on `send_payment`, but we tested it directly against live FNN v0.8.1 nodes and confirmed it does not help: dry-run sessions return `Created` immediately with no route detail, and are never queryable afterward, not even the instant after creation (`get_payment` returns `Payment session not found`). Whatever data a real router computes during a dry run is discarded, not surfaced.
|
|
12
16
|
|
|
13
|
-
Every wallet, checkout flow, and payment bot built on Fiber runs into this same wall. `
|
|
17
|
+
Every wallet, checkout flow, and payment bot built on Fiber runs into this same wall. `fiberprobe` is the SDK layer that solves it properly, and it does so two ways, because there are two different questions a developer actually needs answered.
|
|
14
18
|
|
|
15
19
|
## Two tiers, because one estimate isn't enough
|
|
16
20
|
|
|
@@ -54,7 +58,7 @@ None of these would have surfaced from reading documentation. They surfaced from
|
|
|
54
58
|
## Quick start
|
|
55
59
|
|
|
56
60
|
```ts
|
|
57
|
-
import { FiberClient, PaymentChecker } from '
|
|
61
|
+
import { FiberClient, PaymentChecker } from 'fiberprobe'
|
|
58
62
|
|
|
59
63
|
const client = new FiberClient('http://127.0.0.1:8227') // your FNN node's RPC address
|
|
60
64
|
const checker = new PaymentChecker(client)
|
|
@@ -186,7 +190,7 @@ Open `http://localhost:5173`. The Vite dev server proxies `/rpc-alice`, `/rpc-bo
|
|
|
186
190
|
|
|
187
191
|
Every wallet, merchant checkout, and payment bot that gets built on Fiber will hit the exact liquidity-visibility wall this SDK addresses, on day one of integration. Right now each of them would either reinvent this from scratch or ship with silent failure modes, exactly the kind of gap that makes a new payment network frustrating to build on.
|
|
188
192
|
|
|
189
|
-
`
|
|
193
|
+
`fiberprobe` is meant to be the layer that sits between `fnn`'s RPC and application code, so that question doesn't have to be solved twice. It's typed, it's tested against real infrastructure rather than assumptions from documentation, and the failures it caught along the way (five of them, detailed above) are the kind that would otherwise ship silently into production and degrade user experience the first time someone hits an edge case.
|
|
190
194
|
|
|
191
195
|
---
|
|
192
196
|
|
|
@@ -194,4 +198,4 @@ Every wallet, merchant checkout, and payment bot that gets built on Fiber will h
|
|
|
194
198
|
|
|
195
199
|
Category 2: Node, Routing & Diagnostics Infrastructure, "Gone in 60ms" Fiber Network Infrastructure Hackathon (July 2026).
|
|
196
200
|
|
|
197
|
-
Repository: `github.com/Linnnetteseven/
|
|
201
|
+
Repository: `github.com/Linnnetteseven/fiberprobe`
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "fiberprobe",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.1",
|
|
4
4
|
"description": "TypeScript SDK for Fiber Network Node (FNN) — typed RPC client, static route estimation, live HTLC-based liquidity probing, inbound capacity checks, and event-driven payment lifecycle.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "./dist/index.js",
|
|
@@ -33,11 +33,11 @@
|
|
|
33
33
|
],
|
|
34
34
|
"repository": {
|
|
35
35
|
"type": "git",
|
|
36
|
-
"url": "git+https://github.com/Linnnetteseven/
|
|
36
|
+
"url": "git+https://github.com/Linnnetteseven/fiberprobe.git"
|
|
37
37
|
},
|
|
38
|
-
"homepage": "https://github.com/Linnnetteseven/
|
|
38
|
+
"homepage": "https://github.com/Linnnetteseven/fiberprobe#readme",
|
|
39
39
|
"bugs": {
|
|
40
|
-
"url": "https://github.com/Linnnetteseven/
|
|
40
|
+
"url": "https://github.com/Linnnetteseven/fiberprobe/issues"
|
|
41
41
|
},
|
|
42
42
|
"author": "Linnette Mugwanja",
|
|
43
43
|
"license": "MIT",
|