How this actually runs
Written for the person deciding whether to depend on us, because the architecture is the argument. There is very little between a validator broadcasting a shred and your socket receiving it, and that is the whole point.
Receiving
We take delivery of shreds from multiple independent upstreams at the network edge in Frankfurt. The same shred usually arrives more than once, from different sources at slightly different times. We keep the first copy and discard the rest, which means the feed is never slower than its best source on a given packet.
Forwarding
A relay holds the list of active destinations and forwards each deduplicated packet to every one of them, unmodified, from 64.130.40.90. Nothing is decoded and nothing is buffered. The forwarding path does as little as possible on purpose, because the less it does the less it can add.
Granting and revoking access
A destination becomes active only after it proves it controls its own address, and it stops being active the moment its term ends. Both of those live in the delivery system rather than in this website, which matters more than it sounds: expiry is enforced by a loop running next to the relay, so a customer stops receiving data on time even if this site is down, mid deploy, or broken.
We built it that way round deliberately. Revocation should not depend on the least reliable component in the system.
What we do to keep it steady
Several sources, always
The same shred reaches us from more than one upstream, so a single source degrading is something you are unlikely to ever notice.
First copy wins
Deduplication on arrival means the feed runs at the speed of its fastest source on every individual packet.
Expiry next to the relay
Access is granted and revoked by a loop running beside the forwarder, so entitlements stay correct even while this website is mid deploy.
A short path
Nothing decodes, nothing buffers, nothing queues. The fewer moving parts between the validator and your socket, the less there is to go wrong.
When you need us
Email sam@shredstream.sh and an engineer who works on this system answers you. Not a ticket queue, not a bot, and not somebody reading from a script. That is a deliberate advantage of staying small, and it is one of the reasons people move to us.
If you want to measure us yourself, the methodology page sets out exactly how to run a fair comparison against any other feed, so you can see the result on your own hardware rather than take anybody’s word for it.