socket

README

Syncthing Socket

A netcat-like client/server utility that allows two endpoints to communicate bi-directionally even when both are behind a NAT, leveraging the public **Syncthing Relay Network** and **Global Discovery Directory**.

Key Features

• P2P NAT Traversal: Automatically attempts to punch holes through NATs using WebRTC ICE DataChannels. Seamlessly falls back to Syncthing's global public relay network if a direct connection is impossible.
• End-to-End Encryption: Automatically establishes a secure end-to-end tunnel using TLS 1.3.
• Cryptographic Device Verification: Identifies and authenticates endpoints by hashing their TLS certificates to generate unique Syncthing Device IDs, preventing man-in-the-middle attacks.
• Global Discovery: Server registers itself dynamically in the Syncthing global announce directory (discovery.syncthing.net), allowing clients to look up and connect to the server using only its Device ID.
• Interactive Shell: Built-in pseudo-terminal (PTY) shell mode (-shell) natively replaces SSH, perfectly forwarding terminal sizes for interactive tools like vim or htop.
• Remote Command Execution: Execute an arbitrary command for each connection and pipe its input/output over the tunnel (--command).
• SOCKS5 Proxy: Built-in multiplexed remote SOCKS proxy (-socks).
• Netcat-style: Pipes standard input (stdin) and standard output (stdout) bi-directionally between endpoints.
• Remote LUKS Unlock: Unlock an encrypted root filesystem during early boot on a machine that cannot accept inbound connections, by piping the passphrase to it on demand. See Unlocking an Encrypted Disk at Boot.

---

Compilation

You can build the binary using:

go build -o syncthing-socket main.go

---

Usage

1. Start the Server

Start the server listening on the Syncthing relay network. By default, it will dynamically choose a low-latency public relay from the pool, print the connection string, and announce itself to the Syncthing Global Discovery servers:

./syncthing-socket server

Example Output:

==================================================
Server Device ID: YGOV2KW-QIGHJYZ-BCA52RN-7EQTGY3-CQGARMC-3JVUWAA-BXHSKI5-ZRJSBQT
==================================================
Connected to Relay: relay://195.22.153.71:22067/?id=SPXEVID...
To connect, run:
  ./syncthing-socket client --relay "relay://195.22.153.71:22067/?id=SPXEVID..." YGOV2KW-QIGHJYZ-BCA52RN-7EQTGY3-CQGARMC-3JVUWAA-BXHSKI5-ZRJSBQT
Or simply:
  ./syncthing-socket client YGOV2KW-QIGHJYZ-BCA52RN-7EQTGY3-CQGARMC-3JVUWAA-BXHSKI5-ZRJSBQT@relay://195.22.153.71:22067/?id=SPXEVID...
==================================================
2026/07/11 13:16:33 Announcing availability to https://discovery-announce-v4.syncthing.net/v2/?nolookup...
2026/07/11 13:16:33 Successfully announced to https://discovery-announce-v4.syncthing.net/v2/?nolookup

Server Options:

• --shell: Start a fully interactive PTY shell daemon (replaces SSH).
• --command "<cmd>": Spawn an arbitrary command (e.g. bash -c "<cmd>") for each incoming connection and pipe its standard input and output over the tunnel.
• --socks: Start a remote SOCKS5 proxy server.
• --seed <secret>: Deterministically generates a secure TLS certificate and Device ID from a secret password, so you don't need to copy-paste long Device IDs.
• --cert <path>: Custom TLS certificate path (default: empty, runs in-memory).
• --key <path>: Custom TLS key path (default: empty, runs in-memory).
• --relay <uri>: Specific relay URI, or a dynamic pool URL (default: dynamic+https://relays.syncthing.net/endpoint).
• --discovery <urls>: Comma-separated list of global announce directories.
• --direct-port <port>: Enable direct TCP connection listening on this port (0 to disable, default: 0).
• --authorized-clients <ids>: Comma-separated list of authorized client Syncthing Device IDs. When specified, only clients with matching Device IDs are allowed to connect; unauthorized clients are rejected post-handshake.
• --totp: Require Time-based One-Time Password (TOTP, RFC 6238) authentication for incoming connections. If --totp-secret is omitted, a secure base32 secret is automatically generated and an ASCII QR code is printed to stderr.
• --totp-secret <secret>: Base32-encoded TOTP secret key for authentication. Explicitly setting this flag automatically enables TOTP requirement.
• --log-level <level>: Logging level: trace, debug, info, warn, error (default: info).
• --log-format <format>: Logging format: auto, text, json, journald (default: auto).

---

2. Connect with the Client

You can connect to the server in three ways:

Option A: Dynamic Discovery Lookup (Recommended)

If you only know the Server's Device ID, the client will automatically query the global directory, resolve which relay the server is currently on, and connect to it:

./syncthing-socket client <SERVER_DEVICE_ID>

Option B: Combined Connection String

Connect directly using the connection string printed by the server:

./syncthing-socket client <SERVER_DEVICE_ID>@<RELAY_URI>

Option C: Bypassing Discovery via Flags

Specify the relay address manually via the --relay flag:

./syncthing-socket client --relay "<RELAY_URI>" <SERVER_DEVICE_ID>

Client Options:

• --shell: Put the local terminal in raw mode and connect to a remote --shell server.
• --socks <address>: Spin up a local SOCKS5 proxy on this address (e.g. 127.0.0.1:10800).
• --seed <secret>: Use the same passphrase as the server to auto-discover and connect without needing the Server Device ID!
• --cert <path> / --key <path>: Use a persistent certificate (default: generates a secure in-memory certificate).
• --discovery <url>: Custom discovery server URL for lookups (default: https://discovery-lookup.syncthing.net/v2/).
• --direct: Attempt direct P2P connections via WebRTC ICE (UDP NAT Hole Punching) and direct TCP before seamlessly falling back to relay. Set --direct=false to disable ICE and force relay connections (default: true).
• --totp <code>: 6-digit TOTP passcode for server authentication. If omitted when connecting to a TOTP-enabled server, the client will interactively prompt for the code on standard input.
• --log-level <level>: Logging level: trace, debug, info, warn, error (default: info).
• --log-format <format>: Logging format: auto, text, json, journald (default: auto).

---

Advanced: Interactive PTY Shell (SSH Replacement)

You can completely bypass the need for an external OpenSSH server by using the built-in PTY shell!

1. On the Server:

./syncthing-socket server --seed "my-secret" --shell

1. On the Client:

./syncthing-socket client --seed "my-secret" --shell

This spawns a remote bash session and pipes your raw local terminal directly into it. It natively supports tab-completion, vim, htop, and even transmits window resizing events (SIGWINCH) over a dedicated lightweight control stream so the remote UI always perfectly fits your screen.

---

Advanced: Remote Command Execution

If you want to just trigger a script, pipe data into a command, or build a simple authenticated remote execution API, you can use the --command flag.

On the Server:

./syncthing-socket server --seed "my-secret" --command "echo 'Processing data...'; cat - | grep error; echo 'Done!'"

On the Client:

echo "log data with error" | ./syncthing-socket client --seed "my-secret"

Note: By default, standard error (stderr) generated by the command is cleanly printed to the server's structured logs so it does not corrupt the data stream. If you wish to send stderr back to the client along with standard output, use standard shell redirection at the end of your command string: --command "your command 2>&1".

---

Utility: Deterministic Device IDs

If you are using the --seed flag instead of explicit TLS certificates, syncthing-socket mathematically derives unique cryptographic keys from your secret phrase. To prevent reflection attacks (where a malicious actor routes your client back to itself), the client and server intentionally use different cryptographic suffixes during derivation.

If you are curious what your Syncthing Device IDs will be for a given passphrase, you can use the id subcommand:

$ ./syncthing-socket id --seed "my-secret"
Server ID: DJOJMPR-MCPBCMH-GVVOJEX-HXWI7JU-L7OSTDV-TBD4ZJP-YSOFXQZ-PPFV5QD
Client ID: F34H6S5-62G6AIP-2G3VHTB-I5D35S6-6T4K5E6-RFL52E4-37C5T3S-7FLHFAQ

---

Using it as a Go library

Two small packages can be imported on their own. Both use only the standard library, so they do not pull in the CLI, WebRTC, or the Syncthing libraries:

• github.com/muelli/syncthing-socket/discovery: LookupRecord resolves a Device ID through Syncthing global discovery (DefaultURL) to its announced addresses and when it was last seen.
• github.com/muelli/syncthing-socket/identity: GenerateDeterministicCert derives the same certificates as --seed; append CertSuffixServer or CertSuffixClient to the seed for the respective end.

---

Unlocking an Encrypted Disk at Boot

The flagship use case. A server or VM with an encrypted root filesystem needs its LUKS passphrase before it can finish booting. But if it cannot accept inbound connections, you cannot SSH in to provide one. syncthing-socket inverts the direction: the booting machine dials out and you hand it the passphrase from your laptop.

• On the booting machine, the initramfs runs syncthing-socket client and hands the result to whatever is asking for the passphrase, without replacing the prompt. Under initramfs-tools that means writing into the same passfifo cryptsetup's own askpass reads from; under dracut it means answering systemd's password request as one more agent.
• On your laptop, you pipe the passphrase into syncthing-socket server when you want the machine to come up.

# Laptop, when you want the machine to boot:
printf %s 'your-luks-passphrase' | syncthing-socket server --seed "your-key-seed"

Like Clevis, it hooks the initramfs without replacing the passphrase prompt, so console entry, Clevis/Tang and TPM agents all keep working, as does cryptroot-unlock where that exists. Whichever key arrives first wins, and /etc/crypttab needs no changes.

Debian/Ubuntu packages install the pieces. Add the signed repository:

sudo curl -fsSL https://muelli.github.io/syncthing-socket/deb/KEY.gpg -o /etc/apt/keyrings/syncthing-socket.gpg

echo "deb [signed-by=/etc/apt/keyrings/syncthing-socket.gpg] https://muelli.github.io/syncthing-socket/deb stable main" | sudo tee /etc/apt/sources.list.d/syncthing-socket.list

Then install the integration matching your initramfs generator. dpkg -S /usr/sbin/update-initramfs says which you have: initramfs-tools or dracut, the latter being what Ubuntu 26.04 and later use. Installing the wrong one fails silently, so it is worth the one command.

sudo apt update && sudo apt install syncthing-socket syncthing-socket-luks-initramfs

sudo apt update && sudo apt install syncthing-socket syncthing-socket-luks-dracut

The full recipe (requirements, pairing modes and their threat models, /etc/crypttab wiring, fallbacks and gotchas) is in contrib/initramfs-luks/README.md.

---

Unlocking from an Android Phone

There is an Android app that does the laptop's half of the unlock, so the machine can boot with nothing but a phone in your pocket. Install it from the project's F-Droid repository:

https://muelli.github.io/syncthing-socket/fdroid/repo

Run syncthing-luks-setup on the machine, scan the QR code it prints (or type the same three values into the app), and from then on the phone offers a single Unlock button, guarded by your screen lock or fingerprint.

The unlock screen also says whether the computer looks like it is waiting, by reading how recently it announced itself to Syncthing's discovery servers. Green means it announced in the last couple of minutes; amber means the record is old, so it may already have booted; red means nothing is announcing yet. It is advice rather than a gate, and the button works in every state.

Re-pairing a phone

The seed lives in the LUKS2 header, so a replacement phone does not need the machine reconfigured. syncthing-luks-setup --reprint <device> reads the existing pairing back out and prints the same QR code; nothing changes, so no re-bind and no initramfs rebuild. A phone that still has the pairing can show it itself, under Pair another phone.

Unlocking more than one computer

The app holds exactly one pairing. That is deliberate: a profile picker is one more thing to get wrong at 3am in front of a machine that will not boot. To unlock a second computer, build a second copy of the app with its own application id. Android treats it as a separate app, so both install side by side with their own icons and their own stored pairing.

just android-apk com.github.muelli.syncthingsocket.office "LUKS Office"

The id must be unique per install and cannot be changed afterwards without reinstalling. The label is what appears under the icon, so make it name the machine. Everything else, including the signing key, is unchanged, so these variants update from the same repository if you publish them.

---

Advanced: Port Forwarding and Reverse Proxies

You can front your local SSH daemon (or any other TCP service) using syncthing-socket. This allows you to securely SSH into a machine behind a NAT.

1. On the Server (SSH Host)

Start the server with the --forward option pointing to your SSH port (usually 127.0.0.1:22). You should also specify --cert and --key so that your server keeps a persistent Device ID:

./syncthing-socket server --cert cert.pem --key key.pem --forward 127.0.0.1:22

The server will print its Device ID (e.g. SERVER_DEVICE_ID). It runs as a persistent daemon and forwards incoming connections to the local SSH port in separate goroutines, handling multiple concurrent sessions.

Support for PROXY Protocol V2 and UNIX Domain Sockets

You can forward traffic to TCP addresses or local UNIX domain sockets (e.g. /var/run/docker.sock or unix:///tmp/app.sock). If you are forwarding to a reverse proxy (like Nginx, Traefik, or HAProxy), you can enable the --proxy-protocol flag:

./syncthing-socket server --forward /var/run/docker.sock --proxy-protocol

This injects an HAProxy PROXY Protocol V2 header at the start of the forwarded stream, allowing compatible backend software to read the Client's original address. Furthermore, syncthing-socket embeds the client's cryptographically authenticated Syncthing Device ID into a custom TLV field (Type 0xEA), enabling native peer authentication at the reverse proxy layer!

2. On the Client

On the client machine, connect using standard SSH with the -o ProxyCommand flag:

ssh -o ProxyCommand="./syncthing-socket client <SERVER_DEVICE_ID>" user@ignored_host

Alternatively, add an entry to your local ~/.ssh/config file:

Host my-nat-server
    User your_username
    ProxyCommand /path/to/syncthing-socket client <SERVER_DEVICE_ID>

Then connect simply by running:

ssh my-nat-server

---

Advanced: Reverse Port Forwarding

You can expose a local service (e.g., a development web server) to the internet by routing traffic backward through a syncthing-socket server running on a public VPS. This acts exactly like SSH -R. You can use TCP addresses or UNIX domain sockets on either side!

1. On the Server (Public VPS):

# Listen on TCP port 8080 or a UNIX socket
./syncthing-socket server --seed my-secret --reverse-forward 0.0.0.0:8080
# Or: ./syncthing-socket server --seed my-secret --reverse-forward /tmp/remote.sock

2. On the Client (Local Machine):

# Forward incoming reverse tunnel traffic to local port 8000 or a UNIX socket
./syncthing-socket client --seed my-secret --reverse-forward 127.0.0.1:8000
# Or: ./syncthing-socket client --seed my-secret --reverse-forward /var/run/docker.sock

Now, anyone accessing http://<VPS-IP>:8080 (or connecting to the remote UNIX socket) will securely hit your local service. Under the hood, this uses yamux multiplexing over the P2P tunnel to handle multiple concurrent requests seamlessly!

---

Proxy Support

Both the server and client natively respect standard proxy environment variables to help bypass restrictive firewalls.

Supported Variables:

• SOCKS_PROXY (or socks_proxy): e.g. socks5://127.0.0.1:1080
• HTTP_PROXY (or http_proxy): e.g. http://proxy.corp.com:8080
• HTTPS_PROXY (or https_proxy)

How it works:

1. Discovery (HTTPS): Uses standard Go networking logic to route queries to discovery.syncthing.net via your specified HTTP_PROXY / HTTPS_PROXY.
2. Syncthing Relay Network (Raw TCP): Transparently dials out to the Syncthing Relay endpoints (relay://...) by tunneling the raw TCP traffic through either your specified SOCKS_PROXY or via an HTTP CONNECT tunnel if an HTTP_PROXY is provided.
3. Direct Connections (WebRTC ICE): STUN/TURN discovery queries are handled by Pion and may also route over supported proxies if configured in the environment. Direct P2P TCP hole punching attempts to establish a connection directly between peers (bypassing proxies if local).

Note: If both SOCKS and HTTP proxies are provided in the environment, SOCKS takes precedence for raw TCP routing to the Relay network.

---

Shell Completions

syncthing-socket natively supports generating auto-completions for Bash, Zsh, Fish, and PowerShell.

To load completions in your current shell session (e.g., Bash):

source <(syncthing-socket completion bash)

To permanently install them, read the help instructions for your specific shell:

syncthing-socket completion bash --help
syncthing-socket completion fish --help

---

Security Model

1. Relay Blindness: The relay server acts purely as a TCP proxy. It cannot decrypt or read any data sent through it.
2. E2E TLS 1.3: Once the relay session is joined by both client and server, they negotiate a direct TLS 1.3 handshake.
3. Peer Verification & Authentication:
   • The Client extracts the leaf certificate from the TLS handshake, hashes it to generate the server's Device ID, and compares it against the expected <SERVER_DEVICE_ID>. The connection is terminated immediately if they do not match.
   • The Server requests the client's certificate to verify and log the client's Device ID. If --authorized-clients is specified, the server validates the client Device ID post-handshake and immediately closes unauthorized connections.
   • If --totp is enabled on the server, an orthogonal challenge-response protocol requires the client to supply a valid Time-based One-Time Password (RFC 6238) before any application stream or tunnel is opened.

Documentation

Index

• Constants
• Variables
• func CopyWithTrace(dst io.Writer, src io.Reader, direction string) (written int64, err error)
• func Execute()
• func GenerateDeterministicCert(seed string) (tls.Certificate, error)
• func RunClient(ctx context.Context, opts ClientOptions) error
• type AuthChallenge
• type AuthResponse
• type AuthResult
• type ClientOptions
• type DiscoveryRecord
  • func LookupRecord(ctx context.Context, serverID string, discoveryServer string) (*DiscoveryRecord, error)
• type JournaldHandler
  • func (h *JournaldHandler) Enabled(ctx context.Context, level slog.Level) bool
  • func (h *JournaldHandler) Handle(ctx context.Context, r slog.Record) error
  • func (h *JournaldHandler) WithAttrs(attrs []slog.Attr) slog.Handler
  • func (h *JournaldHandler) WithGroup(name string) slog.Handler
• type RateLimitTransport
  • func (t *RateLimitTransport) RoundTrip(req *http.Request) (*http.Response, error)
• type ShellSession
• type SignalMessage
• type TextHandler
  • func (h *TextHandler) Enabled(ctx context.Context, level slog.Level) bool
  • func (h *TextHandler) Handle(ctx context.Context, r slog.Record) error
  • func (h *TextHandler) WithAttrs(attrs []slog.Attr) slog.Handler
  • func (h *TextHandler) WithGroup(name string) slog.Handler
• type WebRTCConn
  • func (c *WebRTCConn) Close() error
  • func (c *WebRTCConn) CloseWrite() error
  • func (c *WebRTCConn) LocalAddr() net.Addr
  • func (c *WebRTCConn) RemoteAddr() net.Addr
  • func (c *WebRTCConn) SetDeadline(t time.Time) error
  • func (c *WebRTCConn) SetReadDeadline(t time.Time) error
  • func (c *WebRTCConn) SetWriteDeadline(t time.Time) error

Constants

const (
	CertSuffixServer = identity.CertSuffixServer
	CertSuffixClient = identity.CertSuffixClient
)

Certificate seed suffixes. The two ends of a connection derive different identities from the same passphrase so that a peer cannot be reflected back onto itself; every derivation must go through one of these. They forward to package identity.

const DefaultAnnounceInterval = discovery.DefaultAnnounceInterval

DefaultAnnounceInterval is how often a long-running server refreshes its discovery record. It is deliberately lazy: the record outlives it comfortably, and these are shared public servers. It forwards to discovery.DefaultAnnounceInterval.

const DefaultDiscoveryURL = discovery.DefaultURL

DefaultDiscoveryURL is the Syncthing global discovery endpoint used to resolve a peer's Device ID to its current addresses. Exported so that other entry points into this package, the gomobile bridge in particular, use the same default as the CLI instead of passing an empty string, which produces a relative URL and fails every lookup.

It forwards to discovery.DefaultURL, which other programs can import on its own.

const LevelTrace = slog.Level(-8)

const UnlockAnnounceInterval = 60 * time.Second

UnlockAnnounceInterval is what a machine waiting in its initramfs uses instead.

The point is not to keep the record alive, which the lazy interval already does. It is that the record's "seen" timestamp is the only evidence anyone has that the machine is still waiting: discovery keeps a record for over an hour after the machine has stopped announcing, so at the default interval "seen" cannot distinguish a machine waiting right now from one that finished booting twenty minutes ago. Announcing this often makes "seen" mean what a key holder needs it to mean, and it only applies during the few minutes a machine actually sits at its prompt.

Variables

var Version = "dev"

Functions

func CopyWithTrace

func CopyWithTrace(dst io.Writer, src io.Reader, direction string) (written int64, err error)

CopyWithTrace performs io.Copy but logs all transferred bytes at TRACE level.

func Execute

func Execute()

func GenerateDeterministicCert

func GenerateDeterministicCert(seed string) (tls.Certificate, error)

GenerateDeterministicCert forwards to identity.GenerateDeterministicCert, which other programs can import without this package.

func RunClient

func RunClient(ctx context.Context, opts ClientOptions) error

Types

type AuthChallenge

type AuthChallenge struct {
	Type    string   `json:"type"`              // "auth_required" or "auth_ok"
	Methods []string `json:"methods,omitempty"` // e.g. ["totp"]
}

type AuthResponse

type AuthResponse struct {
	Type string `json:"type"`           // "auth"
	TOTP string `json:"totp,omitempty"` // 6-digit code
}

type AuthResult

type AuthResult struct {
	Status  string `json:"status"`            // "ok" or "error"
	Message string `json:"message,omitempty"` // Error details
}

type ClientOptions

type ClientOptions struct {
	// ServerID is the peer's Syncthing Device ID, optionally with an @relay suffix.
	ServerID string
	// Cert is this end's identity, usually derived from the shared seed.
	Cert tls.Certificate
	// RelayURI overrides discovery with a specific relay. Empty means resolve via
	// discovery, which is the normal case.
	RelayURI string
	// DiscoveryServer is the lookup endpoint. Empty yields a relative URL and fails
	// every lookup, so pass DefaultDiscoveryURL unless you mean something else.
	DiscoveryServer string
	// TryDirect attempts an ICE/WebRTC upgrade to a direct connection.
	TryDirect bool
	// Socks, if set, serves a local SOCKS5 proxy over the tunnel instead of piping.
	Socks string
	// Shell requests an interactive PTY instead of piping.
	Shell bool
	// ReverseForward forwards incoming reverse-tunnel traffic to this address.
	ReverseForward string
	// TOTPPasscode answers a server that requires RFC 6238 authentication.
	TOTPPasscode string
}

ClientOptions is everything RunClient needs.

A struct rather than a parameter list. The list had grown to nine values after the context, five of them strings and three of those routinely empty, so the call site read `RunClient(ctx, id, "", cert, url, true, "", false, "", "")` and a transposition between two adjacent strings would compile and quietly do the wrong thing. Named fields also make a later addition additive instead of shifting everything after it.

type DiscoveryRecord

type DiscoveryRecord = discovery.Record

DiscoveryRecord is what global discovery knows about a device. It is discovery.Record, kept under this name for existing callers.

func LookupRecord

func LookupRecord(ctx context.Context, serverID string, discoveryServer string) (*DiscoveryRecord, error)

LookupRecord fetches the full discovery record, timestamp included. It forwards to discovery.LookupRecord, which other programs can import without this package.

Unlike lookup() below it verifies the discovery server's certificate. lookup() is on the unlock path, where a custom or self-hosted discovery server is a supported setup and the peer is authenticated by its own certificate regardless of what discovery claims. This one is only ever pointed at the public endpoint.

type JournaldHandler

type JournaldHandler struct {
	// contains filtered or unexported fields
}

JournaldHandler writes structured logs to the systemd journal.

func (*JournaldHandler) Enabled

func (h *JournaldHandler) Enabled(ctx context.Context, level slog.Level) bool

func (*JournaldHandler) Handle

func (h *JournaldHandler) Handle(ctx context.Context, r slog.Record) error

func (*JournaldHandler) WithAttrs

func (h *JournaldHandler) WithAttrs(attrs []slog.Attr) slog.Handler

func (*JournaldHandler) WithGroup

func (h *JournaldHandler) WithGroup(name string) slog.Handler

type RateLimitTransport

type RateLimitTransport struct {
	http.RoundTripper
}

func (*RateLimitTransport) RoundTrip

func (t *RateLimitTransport) RoundTrip(req *http.Request) (*http.Response, error)

type ShellSession

type ShellSession interface {
	Read(p []byte) (n int, err error)
	Write(p []byte) (n int, err error)
	Close() error
	Wait() error
	Resize(rows, cols uint16) error
}

type SignalMessage

type SignalMessage struct {
	Type      string                   `json:"type"` // "offer", "answer", "candidate", "fallback"
	SDP       string                   `json:"sdp,omitempty"`
	Candidate *webrtc.ICECandidateInit `json:"candidate,omitempty"`
}

type TextHandler

type TextHandler struct {
	// contains filtered or unexported fields
}

TextHandler is the custom handler for console output.

func (*TextHandler) Enabled

func (h *TextHandler) Enabled(ctx context.Context, level slog.Level) bool

func (*TextHandler) Handle

func (h *TextHandler) Handle(ctx context.Context, r slog.Record) error

func (*TextHandler) WithAttrs

func (h *TextHandler) WithAttrs(attrs []slog.Attr) slog.Handler

func (*TextHandler) WithGroup

func (h *TextHandler) WithGroup(name string) slog.Handler

type WebRTCConn

type WebRTCConn struct {
	io.ReadWriteCloser
	// contains filtered or unexported fields
}

func (*WebRTCConn) Close

func (c *WebRTCConn) Close() error

func (*WebRTCConn) CloseWrite

func (c *WebRTCConn) CloseWrite() error

CloseWrite ends this side's transmission.

A WebRTC data channel has no half-close: per RFC 8831 section 6.7 the peer mirrors any stream reset it sees, so resetting tears down both directions. Callers must therefore only invoke this once they are actually done sending. A side that has sent nothing must stay quiet, or it destroys the direction it is still waiting to receive on.

The queued payload is drained before the reset so the peer reads it and *then* sees EOF. Close() cannot be used here: it also closes the PeerConnection, which aborts the SCTP association and discards data the peer has not read yet.

func (*WebRTCConn) LocalAddr

func (c *WebRTCConn) LocalAddr() net.Addr

func (*WebRTCConn) RemoteAddr

func (c *WebRTCConn) RemoteAddr() net.Addr

func (*WebRTCConn) SetDeadline

func (c *WebRTCConn) SetDeadline(t time.Time) error

func (*WebRTCConn) SetReadDeadline

func (c *WebRTCConn) SetReadDeadline(t time.Time) error

func (*WebRTCConn) SetWriteDeadline

func (c *WebRTCConn) SetWriteDeadline(t time.Time) error