HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
x1colegal
USTP-Secure
Python2026–2026
x1colegal / USTP-Secure

USTP-Secure

Secure (with AEAD) version of USTP, called USTP-Secure (ustps://)

2Distinct people
4Mentions
0Explicit recommenders
14GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Secure (with AEAD) version of USTP, called USTP-Secure (ustps://)

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by day4 dated mentions

Observed mentions: 2026-06-08 11:54:35 UTC to 2026-06-20 00:04:45 UTC.

0122026-06-08 00:00:00 UTC to 2026-06-09 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 commentsJun 82026-06-09 00:00:00 UTC to 2026-06-10 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-10 00:00:00 UTC to 2026-06-11 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-11 00:00:00 UTC to 2026-06-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-12 00:00:00 UTC to 2026-06-13 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-13 00:00:00 UTC to 2026-06-14 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-14 00:00:00 UTC to 2026-06-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJun 142026-06-15 00:00:00 UTC to 2026-06-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-16 00:00:00 UTC to 2026-06-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-17 00:00:00 UTC to 2026-06-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-18 00:00:00 UTC to 2026-06-19 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2026-06-19 00:00:00 UTC to 2026-06-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-06-20 00:00:00 UTC to 2026-06-21 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsJun 20

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jun 82026-06-08 00:00:00 UTC2026-06-09 00:00:00 UTC211
Jun 92026-06-09 00:00:00 UTC2026-06-10 00:00:00 UTC000
Jun 102026-06-10 00:00:00 UTC2026-06-11 00:00:00 UTC000
Jun 112026-06-11 00:00:00 UTC2026-06-12 00:00:00 UTC000
Jun 122026-06-12 00:00:00 UTC2026-06-13 00:00:00 UTC000
Jun 132026-06-13 00:00:00 UTC2026-06-14 00:00:00 UTC000
Jun 142026-06-14 00:00:00 UTC2026-06-15 00:00:00 UTC000
Jun 152026-06-15 00:00:00 UTC2026-06-16 00:00:00 UTC000
Jun 162026-06-16 00:00:00 UTC2026-06-17 00:00:00 UTC000
Jun 172026-06-17 00:00:00 UTC2026-06-18 00:00:00 UTC000
Jun 182026-06-18 00:00:00 UTC2026-06-19 00:00:00 UTC110
Jun 192026-06-19 00:00:00 UTC2026-06-20 00:00:00 UTC000
Jun 202026-06-20 00:00:00 UTC2026-06-21 00:00:00 UTC110

What Hacker News says

4 sources
x1colegal·Jun 20, 2026Submission

Tell HN: Adding congestion control and retry tokens to a reliable UDP transport

I've been experimenting with USTP-Secure, a reliable UDP transport I've been building. The latest version adds: Optional congestion control Retry tokens to reduce amplification risk Optional cleartext + HMAC mode (integrity without encryption) Authenticated ACK/NACK packets One design choice I'm still thinking about is congestion control for an intentionally unordered reliable transport. Unlike TCP, USTPS doesn't enforce ordered delivery at the transport layer. Missing packets can be retransmitted selectively while newer packets continue flowing. I'm curious how others would approach congestion control for this kind of transport, and whether there are existing designs I should study beyond QUIC, RTP/SRT, and similar protocols. Project: https://github.com/x1colegal/USTP-Secure
3 points · Open discussion
x1colegal·Jun 8, 2026Submission

Show HN: Ustps (UDP Speedy Transmission Protocol Secure) and USSH

Hi HN, Over the last few days I've been building USTPS (UDP Speedy Transmission Protocol Secure), an experimental encrypted transport protocol built on top of UDP. The primary goal of USTPS is low-latency video streaming. A server can take a video source and expose it through a USTPS endpoint, while Linux and Android (Termux) clients receive the stream and expose it locally to applications such as VLC, mpv, and FFmpeg. Although streaming is the main focus, USTPS is not limited to media delivery. It can also be used for other reliable encrypted UDP-based applications, which is why I built USSH on top of it. Some of the main design differences compared to TCP-based transports are: - USTPS is reliable but unordered. - If packet N is lost, later packets can still be accepted and processed immediately. - Missing packets are recovered through s
Read the rest
elective retransmission. - Ordering is handled by the application layer when needed. This means the transport layer itself does not introduce Head-of-Line Blocking. The tradeoff is that applications which require ordering must implement reordering themselves. I consider this a reasonable tradeoff because it avoids forcing every application to pay the cost of transport-level ordering. For media player compatibility, the default USTPS client creates a local TCP endpoint at 127.0.0.1:1238. The client maintains a small reordering buffer (350 ms by default) to give retransmissions time to arrive before forwarding data to the local TCP stream. This allows existing software such as VLC, mpv, and FFmpeg to work without modification. USTPS currently provides: - Reliable delivery using ACKs and selective retransmissions - X25519 key exchange - AEAD encryption (AES-GCM and ChaCha20-Poly1305) - Optional unordered live output mode - Stream position metadata - Multi-client support - Local TCP compatibility output - No congestion control (currently intentional) While developing USTPS, I also built USSH, an SSH-like remote shell running entirely over USTPS. USSH uses the same unordered transport underneath, but the client reconstructs and orders terminal data before presenting it to the user. This prevents terminal corruption while still allowing the transport layer itself to remain unordered. USSH includes: - Interactive terminal sessions - PTY support - Password authentication - Host key verification (TOFU) - End-to-end encrypted communication through USTPS I'm currently using USSH from my Android phone through Termux to manage my VPS. The project is very young (less than a week old) and is primarily experimental and educational. I'm interested in feedback from people working on transport protocols, streaming systems, SSH implementations, QUIC, SCTP, and networking software. USTP-Secure: https://github.com/x1colegal/USTP-Secure USSH: https://github.com/x1colegal/USSH Internet-Drafts: USTPS Draft: https://datatracker.ietf.org/doc/draft-x1co-ustps/ USSH Draft: https://datatracker.ietf.org/doc/draft-x1co-ussh/ Questions, criticism, and suggestions are welcome.
13 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.