<!--
hoody-pipe Subskill (http)
Auto-generated by Hoody Skills Generator
Generated: 2026-05-06T18:39:30.707Z
Model: mimo-v2.5-pro + fixer:z-ai/glm-5.1
Mode: http


Tokens: 4948

DO NOT EDIT MANUALLY - Changes will be overwritten on next generation
-->

# hoody-pipe Subskill

## Overview

### What is Hoody Pipe?

Hoody Pipe is a real-time data streaming service that enables direct data transfer between senders and receivers through named pipe paths. Unlike traditional file storage or message queues, Hoody Pipe operates with **zero server-side storage** — data flows directly from sender to receiver in real-time.

### When to Use Hoody Pipe

| Use Case | Description |
|----------|-------------|
| **File Transfer** | Send files between machines without intermediate storage |
| **Real-time Streaming** | Stream data (logs, metrics, video) from source to consumer |
| **One-time Data Transfer** | Move configuration, secrets, or artifacts between systems |
| **Browser Upload** | Use the web interface to send files/text to a pipe path |
| **Cross-system Communication** | Bridge data between different environments or networks |

### How It Fits Into Hoody Philosophy

Hoody Pipe embodies the Hoody principle of **ephemeral, stateless services**:

- **No persistence**: Data is never stored on the server — it streams directly between endpoints
- **Zero configuration**: No queues, topics, or storage buckets to manage
- **Instant provisioning**: Create any pipe path on-the-fly by simply using it
- **Automatic cleanup**: When connections close, the pipe path ceases to exist
- **Secure by default**: Access through Hoody's authenticated proxy system

### Service Architecture

```
┌─────────────┐         ┌─────────────────┐         ┌─────────────┐
│   Sender    │ ──────► │   Hoody Pipe    │ ──────► │  Receiver   │
│  (POST/PUT) │         │  (No Storage)   │         │    (GET)    │
└─────────────┘         └─────────────────┘         └─────────────┘
```

The receiver blocks until a sender connects. Once paired, data streams directly through.

---

## Common Workflows

### Workflow 1: Basic File Transfer (curl)

Transfer a file from Machine A to Machine B using a named pipe path.

**Step 1: Start Receiver (Machine B)**

Begin listening on a pipe path. The request blocks until data arrives.

```
# Machine B: Listen for incoming data on path "mydata"
curl -s \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/mydata" \
  -o received_file.bin
```

**Step 2: Send File (Machine A)**

Send the file to the same pipe path. The receiver immediately begins receiving.

```
# Machine A: Send file to path "mydata"
curl -s \
  -X POST \
  -T local_file.bin \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/mydata"
```

**Step 3: Verify Transfer**

```
# Machine B: Check received file
ls -la received_file.bin
md5sum received_file.bin
```

### Workflow 2: Text/Message Streaming

Send text data or messages through a pipe path.

**Sender:**

```
curl -s \
  -X POST \
  -H "Content-Type: text/plain" \
  -d "Hello from the sender!" \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/messages"
```

**Receiver:**

```
curl -s \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/messages"
```

Output:
```
Hello from the sender!
```

### Workflow 3: Using PUT Alias for File Transfer

PUT is an alias for POST. Since curl's `-T` flag defaults to the PUT method, this alias allows `-T` uploads without specifying `-X POST`.

```
# Send using PUT (equivalent to POST)
curl -s \
  -T myfile.txt \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/data"

# Receiver (same as always)
curl -s \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/data"
```

### Workflow 4: Browser-Based Upload (Web Interface)

Access the Hoody Pipe web interface for browser-based file/text uploads.

**Step 1: Open Web Interface**

```
GET https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe
```

This returns an HTML page with a form for sending files or text to any pipe path.

**Step 2: Fill Form and Submit**

- Enter the target pipe path
- Select a file or type text content
- Submit to send data to the pipe

### Workflow 5: No-JavaScript Upload Form

```
GET https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/noscript
```

**Query Parameters:**

| Parameter | Description |
|-----------|-------------|
| `path` | Pre-fill the pipe path in the form |

Example with pre-filled path:

```
GET https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/noscript?path=mydata
```

### Workflow 6: Get Usage Help

Retrieve built-in usage instructions with curl examples tailored to your service instance.

```
curl -s \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/help"
```

Returns plain text with curl examples using the server's own URL (derived from Host header).

### Workflow 7: Health Check

Verify the service is running and healthy.

```
curl -s \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/health"
```

**Important**: Only `/api/v1/pipe/health` is valid. A bare `/health` returns 404.

---

## Advanced Operations

### Multi-Step Workflow: Piped Data Processing

Chain commands to send processed data through a pipe.

**Sender (Machine A) — Compress and Send:**

```
tar czf - /data/directory | \
  curl -s \
    -X POST \
    -H "Content-Type: application/gzip" \
    -T - \
    "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/backup"
```

**Receiver (Machine B) — Receive and Extract:**

```
curl -s \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/backup" | \
  tar xzf - -C /restore/directory
```

### Multi-Step Workflow: Database Dump Transfer

Transfer a database dump between systems.

**Sender:**

```
pg_dump mydb | \
  curl -s \
    -X POST \
    -H "Content-Type: application/sql" \
    -T - \
    "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/dbdump"
```

**Receiver:**

```
curl -s \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/dbdump" | \
  psql mydb_restored
```

### Error Recovery Patterns

**Pattern 1: Receiver Timeout**

If the receiver times out waiting for a sender:

```
# Receiver with explicit timeout
curl -s \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/mydata"

# If timeout occurs, simply retry
curl -s \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/mydata"
```

**Pattern 2: Sender Before Receiver**

If the sender connects before the receiver, the sender blocks until a receiver connects. This is safe — no data is lost.

```
# Sender starts first (blocks until receiver connects)
curl -s \
  -X POST \
  -T data.bin \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/mydata"

# Receiver connects later — transfer begins immediately
curl -s \
  "https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu/api/v1/pipe/mydata" \
  -o data.bin
```

**Pattern 3: Connection Interruption**

If a transfer is interrupted, restart both sender and receiver. There is no partial state to recover — the pipe path is ephemeral.

### Performance Considerations

| Consideration | Recommendation |
|---------------|----------------|
| **Timeout** | Use `--max-time` to prevent indefinite blocking |
| **Large Files** | Use `-T` for streaming; avoid buffering entire file in memory |
| **Compression** | Compress before sending to reduce transfer time |
| **Path Naming** | Use unique, descriptive paths to avoid conflicts |
| **Concurrent Transfers** | Each path supports one sender-receiver pair at a time |

### CORS and Browser Access

Cross-origin requests are supported without additional configuration.

---

## Quick Reference

### Base URL Pattern

```
https://{projectId}-{containerId}-pipe-{serviceId}.{node}.containers.hoody.icu
```

### Key Behaviors

- **No storage**: Data streams directly; nothing persists on server
- **Blocking**: Both sender and receiver block until paired
- **Ephemeral paths**: Paths exist only during active connections
- **One-to-one**: Each path supports one sender-receiver pair
- **Headers forwarded**: Original request headers are passed to receiver