We added optional client-side stream stamps end-to-end (create, storage, info, TS client), ensured legacy compatibility, and added configurable throttling for create/subscribe so the server is safer under load without changing DID authority semantics.

[MagnetosphereLabs]

Hello!

I normally make software for private clients but I've been looking to contribute to open source projects recently. My friend showed me your repo after the news about Discord came out. I hope the below updates help out even a little.

What we changed, from the original version, is basically a full pass on stream creation metadata, compatibility safety, and server hardening. The first big improvement is that stream/create can now accept an optional clientStamp and echo it back in the response, while still keeping streamDid as the real authority. So clients can attach a stable client side identifier when they create a stream, but the server model and DID authority didn’t get replaced or weakened. That means you get better offline/local first ergonomics without breaking the protocol’s trust model. You can point to the create handler and the request/response structs where that was wired in.

The second big change is that we didn’t just echo the stamp once and forget it, we added persistence and retrieval. The streams schema now includes client_stamp, storage writes it during stream creation, and stream/info returns it along with module info. There’s also a migration path so existing DBs can be upgraded safely with alter table ... add column client_stamp, and it gracefully tolerates the “already exists” case. Legacy streams continue to work, new streams can store stamp metadata, and clients can fetch that metadata later.

Third, we specifically protected compatibility (so old clients don’t break). Old create payloads should still deserialize, upgraded responses still deserialize in legacy client shapes, and both stream-info and stream-create compatibility behavior works as expected.

Fourth, we added reliability controls where your earlier notes flagged risk: stream/create and stream/subscribe_events now have per-actor throttling, configurable windows/limits, and active-subscription caps. The implementation also prunes stale actor state and tracks active subscription increments/decrements, so it’s not just a naive counter. This directly helps self-hosting stability and abuse resistance (especially under spammy connection/subscription behavior).

Fifth, on the TypeScript side, we closed the usability gap by making LeafClient.createStream() actually accept optional clientStamp and return it, instead of only exposing that support at the lower wire-type level. So app developers using the normal TS client API can now use the feature directly. The codec types and the high-level client method are aligned now.

And finally, changelog was updated with a clear record of what changed: the create/info API extensions, storage migration, compatibility guarantees, throttling, and TS client follow-through.

Thanks for all the cool projects you're working on, I can't wait to see what else you all build and I hope this is helpful!