Reviving MSN Messenger’s I-Buddy USB Accessory

Some of our esteemed readers were not yet out of diapers back in 2013 when Microsoft decided to put MSN Messenger out to pasture, but the memories that this instant messenger’s (IM) interface and notification sounds have left are hard to erase. This also includes some of the weirdest accessories that this IM spawned, such as the USB-connected i-Buddy. Recently [Rayly Retro] got his mittens on a new-in-box one to revive alongside an era-appropriate Windows 7 PC.

What the i-Buddy gets you is the ability to light up the head in seven different colors, twist the torso and flap the butterfly wings, all of which can correspond to certain events in the MSN IM or for more general notifications, as set by software running on the connected PC. Interestingly, this i-Buddy is recognized by Windows as a USB HID, so no special driver is needed. A range of ways to program it exist too, including a .NET-based library from back when it was still being sold for around $20.

Although the MSN Messenger network’s servers have long since been dumped into an e-waste dumpster over at Microsoft HQ, an alternative exists in the form of the Escargot service using which a range of official clients can work again.

In the video it’s demonstrated how to create a user account with the Escargot site and how to patch the messenger – here Window Live Messenger 2009 – before signing in. With that step completed, getting the i-Buddy up and running is next. This took a lot of struggling, since the version of the i-Buddy software that comes with the device didn’t like Windows 7 much. Fortunately an old forum post led to a download of version 2.10, using which the gadget jumped to life, happily lighting up and flapping its wings.

Continue reading “Reviving MSN Messenger’s I-Buddy USB Accessory”

When A Favicon Becomes The Entire Website

Putting hidden data in places where few expect it can be a fun hobby or even a professional career. In the case of [Tim Wehrle] it’s just the former. His most recent project in this area uses a favicon image for storing a HTML-based website and rendering its contents within the browser after the favicon has been downloaded.

To pull this off, a very basic HTML page was turned into a series of UTF-8 encoded bytes that were then declared to be a standard PNG image. The original 208 byte payload plus 4-byte PNG header only used part of a 9×9 pixel favicon. With a larger favicon image as typically used you could thus easily store more data, whether as visual noise like here or a bit more hidden.

Of course there’s a catch, and in this case it’s the Typescript code to unpack the bytes from the “image” and render them; you have to load that separately. But still, in these days of all-singing, all-dancing websites that take forever to render, it’s refreshing to see what you can do with so few bytes that they fit in a favicon.

As for the purpose of such an approach, that’s left as an exercise for the reader, but you’re more than welcome to take a poke at the GitHub project and the demonstration site..

 

How Search Engines Enabled Finding Needles In A WWW-Sized Haystack

When the World Wide Web surged into existence during the 1990s, we were introduced to the problem of how to actually find something in this ever-ballooning construction zone that easily outpaced even the fastest post-WW2 urban sprawl. Although domain names provided a way to find servers using DNS rather than having to mash in IP addresses, you still somehow had to know the relevant URL.

A range of solutions were thought up over time, ranging from printed Yellow Pages type guides, to online curated lists of resources, as well as things like web rings where one website would link to a relevant similar website. This was the time when word-of-mouth was also very relevant, with people proudly announcing their own website on Geocities or other hosting service.

Search engines already existed long before the WWW became the hot new thing during the 1990s, but it was the WWW that would really push them to their limits. As anyone who used search engines for the WWW can attest, they had many issues. Often you’d end up using multiple search engines to find something, and despite fierce competition between web search engines to become the starting page for their browser, actually finding things on the WWW remained a tough problem.

Since a web search engine ‘just’ has to index the WWW and match a search query against the results, why was this such a hard problem that persisted until Google apparently cracked the code?

Continue reading “How Search Engines Enabled Finding Needles In A WWW-Sized Haystack”

Remembering The Tech We Lost With A Virtual Graveyard

Although 1999 might still feel like yesterday for some of us, in the world of technology the intervening years are practically an eternity. New websites, applications and devices pop up all the time, only to die off just as fast again for a variety of reasons. Amidst such chaos it’s always good to take a breather and reflect on all that we have lost, such as on the virtual graveyard that [Burak Ozdemir] created with hand-written obituaries and only the classiest of 90s-era web design.

Remembered are everything from instant messengers and social networks to web hosts and devices. Who still remembers their ICQ number? There was a good chance that you were also on GeoCities or similar web host back then too. Maybe you weren’t really into Google+, but some of us still have fond memories of its virtual hangouts that provided a connection to people around the world in a way not since replicated.

Not all of the entries are as well-known, of course, with not everyone remembering or ever having heard about services like Songza. A few rare entries on the list have punched a zombified hand through six feet of soil and shambled back into the daylight, such as the Pebble devices. Some entries are quite more recent, with many probably remembering Microsoft’s short-lived Tay that made clear that public chatbots need a lot of safety rigging, a lesson that was mostly remember by subsequent chatbots.

Although some things like forum signatures and personal homepages arguably still live on, the death of Clippy will definitely be mourned by many.

Your Browser Probably Lies To The Big Sites (Blame Chrome)

When you visit certain large sites in Firefox or Safari, the browser may detect your visit and change its behavior. It could be as simple as lying about its identity, or it may totally change how it renders the page. But according to a post by [Den Odell], this isn’t a conspiracy between browsers and big Internet — rather, it is a byproduct of Chrome’s dominance.

Here’s how it goes. Chrome puts out a new feature and everyone rushes to implement it on their site. Maybe the new code breaks other browsers. Maybe the other browser supports the feature, but the website doesn’t detect it correctly or is unaware. Maybe it just relies on some quirk of Chrome. Regardless, Firefox and Safari will change to match the site rather than mess up the user’s experience.

If you want to check it out, Firefox will show you what it does and let you disable specific fixes if you visit the about:compat URL. For Safari, you’ll have to read code from a file named quirks. Bugzilla tracks the fixes for Firefox, if you want more details.

Browsers are huge and complex so even niche browsers, today, usually use one of a handful of rendering engines. It seems that the question isn’t if a big company should control the way the web works. It is more a question of which one is currently dominating.

ESP32 Hosts A Public Website

If you wanted to host a website, you could use any one of a number of online services, or spin up a server on a spare computer at home. If you’re a bit more daring, you could also do what [Tech1k] did, and run one on an ESP32 microcontroller.

The site in question is available (or at least, should be) at HelloESP.com. The first revision ran entirely on an ESP32, serving pages from a SPIFFS filesystem. The device was also fitted with a BME280 environment sensor and an OLED screen. It had an uptime of 500 days before the board failed.

The site has since been relaunched, running on a board that is framed on [Tech1k]’s wall. It runs on an ESP32-WROOM-32D, paired with a BME280 again, along with a CCS811 CO2 and air quality sensor and a DS3231 RTC for accurate timekeeping. The ESP32 is setup to hold an outbound WebSocket to a Cloudflare worker, with the Worker routing HTTP requests to the site via that route. This avoids the need for port forwarding for the ESP32 to be visible to the outside world, and the Cloudflare Worker will also serve a static version of the page in the case of WiFi dropouts or other temporary failures.

It’s true that this isn’t a completely unheard of project—microcontrollers have been working as simple web servers for a long time now. Still, [Tech1k] did a great job of making this as robust as possible and more like a real functional webserver rather than just something that runs on a local network to serve up a config page. That’s worthy of note.

You can run webservers on all kinds of chips these days, even the Raspberry Pi Pico. If you’re doing web stuff on something weird, you know we always wanna hear about it on the tipsline!

Flying Cell Towers For Lower-Latency

When the inevitable Kessler Syndrome cascade sweeps Starlink and its competitors from Low Earth Orbit in what will doubtless be a spectacular meteor shower of debris, the people behind Sceye and its competitors are going to be laughing to the bank. That’s because they’re putting their connectivity rather lower than orbit — in the stratosphere, with high-altitude dirigibles.

The advantages are pretty obvious: for one, the dirigible isn’t disposable in the way the very-low-orbit satellites Starlink and its planned imitators use. For another, the time-of-flight for a signal to get to a dirigible 20 km up is less than a tenth of the time it takes to get 480 km up — and that affects latency. Thirdly, the High Altitude Platform System (HAPS) concept won’t require any special transmitters. Regular cellular modems using ordinary 4G and 5G bands and speeds are usable, which eliminates a big barrier to rollout.

Continue reading “Flying Cell Towers For Lower-Latency”