Explore the risks and possibilities with a prompt for ChatGPT, Claude, or your agent.
Eivod was a peer-to-peer video-delivery startup associated with Carnegie Mellon, Project Olympus and YC Summer 2007. The surviving record is thin: a few institutional biographies establish the product category and origin, while YC supplies a founder list and inactive status.[1][2]
The likely technical thesis was clear for 2007. Viewers' upload capacity could reduce the server bandwidth required for on-demand video. What happened to the company is not documented. No observed source gives a shutdown date, buyer, customer, traction figure or founder account, and the current domain no longer identifies a video business.[3]
Carnegie Mellon identifies Matt Humphrey as a co-founder who developed Eivod with colleagues while in business school. A later university presentation dates the company to 2006 and calls it a video-delivery provider.[4] The university's 2016 event biography is more specific: Eivod was a peer-to-peer video-delivery company, the first Project Olympus PROBE, and later received YC funding.[1]
YC records a different founding team: Joe Damato, Wei An Wang and Bob Dimaggio. It does not list Humphrey or describe the product.[2] The sources may describe different team stages, but no observed document resolves the discrepancy.
The period explains the technical attraction. Video-on-demand concentrated delivery cost at the origin server. Microsoft Research analyzed whether viewers could redistribute the same video they were watching and found that peer assistance could sharply reduce server bandwidth under the right conditions.[5]
The research did not surface two reliable founder quotations about Eivod. Humphrey's later slide gives one terse lesson, "Think customer before you think tech," but it does not explain whether that judgment came from Eivod or another company.[4]
The only dependable product description is "peer-to-peer video delivery." In that model, viewers receive portions of a video from other viewers as well as the origin. Their upload bandwidth can reduce the provider's peak server traffic.
That simple description hides hard coordination. On-demand viewers start different videos at different times and seek to different positions. Peers leave without warning. A system has to find a nearby peer holding the needed segment, reconnect after failure, keep startup delay low and avoid turning its control network into a second bottleneck. Contemporaneous research identified asynchronous arrivals, fault recovery, quick joins and control overhead as the central design problems.[6]
No observed source shows Eivod's interface, deployment model, content relationships or whether it shipped beyond a prototype. Claims that it served a particular customer segment or used a specific protocol would be invention.
The likely buyer was a video publisher or delivery provider paying substantial bandwidth costs, but no Eivod source names a customer.
No company-specific market estimate survives. Peer-assisted VoD mattered because video traffic was expensive and growing, not because Eivod disclosed a serviceable market.
Eivod sat between conventional content-delivery networks and other peer-assisted systems. Its economic advantage required enough simultaneous viewers with spare upload bandwidth. Its operational burden was persuading publishers, viewers and networks to accept a client that redistributed traffic.
No pricing or revenue model was found. A plausible model would have charged publishers against bandwidth saved, but that is a rebuild hypothesis, not a historical fact. Funding beyond YC is also unknown.
Peer assistance works best when many viewers request the same material near the same time. A long catalog with scattered demand leaves fewer peers holding the right segment, pushing traffic back to the origin. The system therefore needed customer scale before it could reliably deliver its promised savings.
Publishers could integrate Eivod, but viewers supplied upload capacity and ISPs carried the peer traffic. Microsoft Research found that locality mattered because unmanaged peer exchange could create cross-ISP traffic.[5] The remedy would have required locality-aware routing, reliable clients and clear user consent, all before savings became predictable.
These mechanisms explain category risk, not Eivod's actual closure. No source connects them to a shutdown decision. The honest conclusion is that YC considers the company inactive and the product has no visible continuity, while the cause and date remain unverified.