Using custom fonts on the web, other than the dozen or so standards faces, has been "the next big thing" for the past several years. We've been teased with the proposed ability to embed custom fonts into web pages since the CSS2 specification submitted in 1998. However, until a major font foundry or company (like Adobe or Microsoft) decides to release a new set of fonts for public use, we're probably out of luck.
sIFR, the brainchild of Shaun Inman, has filled the void. Mike Davidson and Mark Wubben have picked up the torch and run with the technology. sIFR 3.0 is currently in the works and addresses a bevy of issues, like consistent font tuning across platforms. However, sIFR is both a blessing and a curse. Since each instance of sIFR becomes an embedded Flash movie, excessive use of sIFR slows down page load. Basically, if you try to use sIFR for more than headlines, then it starts to become more of a problem. While everything is best in moderation, body copy could use a little love, too.
Most folks are waiting on the CSS3 @font-face module to gain traction, but it's wrought with the same issues as the CSS2 spec. Jon Tan covers the topic more thoroughly than I ever will on this blog, so I recommend reading his blog post Making Web Fonts Work. Essentially, it's come down to a Microsoft vs. Everyone Else issue again, with IE supporting .eot (Embedded Open Types) files and other browsers supporting .otf (OpenType Font) files.
Lastly, sIFR Lite, Facelift and Typeface.js are some other contenders. sIFR Lite is essentially just a reworking of sIFR, but object-oriented and only 3.7kb uncompressed. Sadly, each have their problems, but I'm keeping my eye on them.
It's possible we may see some kind of resolution with CSS3's @font-face in the next wave of browser updates, but it really all comes down to licensing. Until a standard is settled upon, we'll continue to bootstrap custom fonts onto the web.
Related: Read the Increase Your Font Stacks With Font Matrix article on 24 Ways and learn how to construct a "font stack."