peerline 0.1.0-alpha.18 → 0.1.0-alpha.20
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 +8 -3
- package/npm/peerline.js +15 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -4,7 +4,7 @@ Peerline is a terminal-first peer-to-peer file transfer tool.
|
|
|
4
4
|
|
|
5
5
|
It is built for the moments when you want to move files, folders, logs, build artifacts, or project snapshots directly between two machines without first uploading them to a cloud drive. One side opens a receive session, shares a human-friendly name and code, and the other side sends one or more paths. Peerline then tries to find the best route between the two peers and transfers the data with application-layer end-to-end encryption.
|
|
6
6
|
|
|
7
|
-
Peerline is not a sync service and it does not keep a permanent hosted copy of your files. It is closer to a
|
|
7
|
+
Peerline is not a sync service and it does not keep a permanent hosted copy of your files. It is closer to a terminal copy workflow: start a receiver, send one or more batches of paths, verify the transfer, and exit when you are done.
|
|
8
8
|
|
|
9
9
|
## Why Peerline Exists
|
|
10
10
|
|
|
@@ -18,7 +18,7 @@ Peerline is not a sync service and it does not keep a permanent hosted copy of y
|
|
|
18
18
|
|
|
19
19
|
Peerline has two roles:
|
|
20
20
|
|
|
21
|
-
- Receiver: runs `peerline recv`,
|
|
21
|
+
- Receiver: runs `peerline recv`, keeps listening for incoming transfers until you quit or the idle timeout expires, and prints a `name`, `code`, and direct endpoint.
|
|
22
22
|
- Sender: runs `peerline send`, points at the receiver by name/code or IP/code, and provides the files or folders to send.
|
|
23
23
|
|
|
24
24
|
For named transfers, the receiver publishes a short-lived descriptor keyed by the shared name and code. The sender derives the same lookup key, discovers candidate routes, and tries them in order. Peerline prefers direct LAN or public TCP endpoints first, then libp2p routes such as DCUtR and WebRTC TURN. Relay data fallback is available only when explicitly enabled.
|
|
@@ -76,7 +76,8 @@ peerline recv
|
|
|
76
76
|
name: frost-827
|
|
77
77
|
code: fig-mint-1234-5678
|
|
78
78
|
direct: 0.0.0.0:43117
|
|
79
|
-
waiting for
|
|
79
|
+
waiting for transfers over direct TCP or libp2p...
|
|
80
|
+
idle timeout: 10 min (change with --idle-timeout-minutes)
|
|
80
81
|
```
|
|
81
82
|
|
|
82
83
|
Send a file, multiple files, or a folder by name and code:
|
|
@@ -117,9 +118,11 @@ peerline recv [NAME_OR_CODE] [CODE] --port 43117
|
|
|
117
118
|
peerline recv [NAME_OR_CODE] [CODE] --overwrite
|
|
118
119
|
peerline recv [NAME_OR_CODE] [CODE] --no-tui
|
|
119
120
|
peerline recv [NAME_OR_CODE] [CODE] --allow-relay-fallback
|
|
121
|
+
peerline recv [NAME_OR_CODE] [CODE] --idle-timeout-minutes 30
|
|
120
122
|
```
|
|
121
123
|
|
|
122
124
|
`--port` starts the 5-port direct window; Peerline will try that port and the next four.
|
|
125
|
+
`--idle-timeout-minutes` defaults to `10`; set it to `0` to wait until you quit manually.
|
|
123
126
|
|
|
124
127
|
Sender options:
|
|
125
128
|
|
|
@@ -133,12 +136,14 @@ peerline send --name <name> --code <code> <path...>
|
|
|
133
136
|
```
|
|
134
137
|
|
|
135
138
|
Relay fallback must be enabled on both sides when you want Peerline to use relay data paths. Direct and hole-punched routes are attempted before relay fallback.
|
|
139
|
+
In the send TUI, a failed attempt stays on screen and offers `r` to retry the same send or `q`/Esc to quit.
|
|
136
140
|
|
|
137
141
|
## Current Status
|
|
138
142
|
|
|
139
143
|
- Direct IP send and receive works.
|
|
140
144
|
- Named discovery now uses HTTP rendezvous first, then Kademlia provider records, mDNS, DCUtR, relay fallback, and libp2p-webrtc's built-in ICE servers.
|
|
141
145
|
- Files, multiple files, and folders are archived with safe relative paths, BLAKE3 integrity checks, and streaming zstd/lzma compression support.
|
|
146
|
+
- Receivers stay open across multiple incoming transfers, with a configurable idle auto-exit.
|
|
142
147
|
- Conflicts default to non-overwrite behavior, with TUI-driven handling in the receiver flow.
|
|
143
148
|
- The receive side includes a modern terminal UI for identity, route state, and transfer progress.
|
|
144
149
|
- The workspace test suite and E2E coverage are in place.
|
package/npm/peerline.js
CHANGED
|
@@ -292,7 +292,20 @@ function executeBinary(binaryPath, argv = process.argv.slice(2), deps = {}) {
|
|
|
292
292
|
|
|
293
293
|
async function main(argv = process.argv.slice(2), deps = {}) {
|
|
294
294
|
const result = executeBinary(await resolveBinary(deps), argv, deps);
|
|
295
|
-
process.exit(result
|
|
295
|
+
process.exit(exitCodeForResult(result));
|
|
296
|
+
}
|
|
297
|
+
|
|
298
|
+
function exitCodeForResult(result) {
|
|
299
|
+
if (Number.isInteger(result?.status)) {
|
|
300
|
+
return result.status;
|
|
301
|
+
}
|
|
302
|
+
if (result?.signal === "SIGINT") {
|
|
303
|
+
return 130;
|
|
304
|
+
}
|
|
305
|
+
if (result?.signal === "SIGTERM") {
|
|
306
|
+
return 143;
|
|
307
|
+
}
|
|
308
|
+
return 1;
|
|
296
309
|
}
|
|
297
310
|
|
|
298
311
|
if (require.main === module) {
|
|
@@ -310,6 +323,7 @@ module.exports = {
|
|
|
310
323
|
downloadReleaseBinary,
|
|
311
324
|
ensureExecutable,
|
|
312
325
|
executeBinary,
|
|
326
|
+
exitCodeForResult,
|
|
313
327
|
copyBinaryToTemporaryLocation,
|
|
314
328
|
formatExecutionFallbackError,
|
|
315
329
|
isRetryableExecutionError,
|