Post

Couldn't resist looking back at firehose optimization after getting STAR-lite mostly working. Looks like 3x firehose bandwidth reduction is achievable with implicit MST + previous-commit cache of CIDs per repo.

fig (aka:[phil])@bad-example.com

i think there's a mostly-unexplored design space here between massive client fan-out and point-to-point links. eg. i want to run my own relay, but not from home, and ideally not with the full weight of multiple full subscribeRepos coming into my home.

1 repost34 likes

with a few more hours of data, zstd 9 compression, bigger output bundles (marginal improvement) (neat that you currently only need a 200K-entry cache to get ~90% hit rate on DIDs)

(the cid cache hit rate is really around 65% (it's computing against all cids, not potentially-cacheable cids), and you can actually get it to almost 90% with a different cache approach (LRU instead of last-commit), but keeping the client's cache in sync would be way harder/messier.)

fig (aka:[phil])@bad-example.com

bad news and good news intuition was right: nearly 90% of MST CIDs in the firehose are rebroadcasts of recently-emitted CIDs. bad: an LRU cache needs to be kind of big to get a high hit ratio (128 entries = 4.5KB/repo) good: keeping CIDs from the prev commit only yields 60–70% hit ratio

tbh 3x (after zstd!) isn't as dramatic as i was hoping. might still be worth it for keeping homelab ingress under control a bit longer, but it's very far from a jetstream-level win.

But Jetstream lacks verification while it seems like STAR-lite does? That's a huge benefit in my book and I'm curious if it makes sense for operators to offer endpoints. I can imagine Northsky using it within our ecosystem when we need to operate a bare metal relay and want to verify

oh yeah this is keeping the full lossless firehose. i'm just greedy and was hoping for more haha. if the network is going to grow two more orders of magnitude, then this buys *time*, but won't prevent anyone close to limits from needing to make bigger changes. but growth isn't fast rn and bw is $$

Any CID that exists in the MST could be expressed as a path through the tree, i.e. a sequence of small integers describing which child node to choose at each step, to take you from the root to that CID. I bet this issmaller than encoding the full CID, and means you don't need a separate cache.

would be! but gotta assume the client isn’t keeping the full MST around (inductive proofs are where it’s at) …and to recover the original firehose you’d need to keep a full network mirror