Looking for some nostalgia? Just published a new post:
Rebuilding #Windows Live Messenger, Part 2: Messenger on #macOS
https://vito.io/articles/2026-02-17-messenger-on-mac
#retrocomputing #reverseengineering #windowslivemessenger #microsoft #writing #blog #smallweb
@ge0rg oooof! That's ugly!
Thanks for the heads up! I'll take a look.
(Turing help me dealing with CSS again... hahahahahah)
@ge0rg Posts are fixed! I'll work on the home and other pages now :P
Again, thanks for the heads up! Totally disregarded narrow phones when writing the CSS :(
@vito
Really impressive work, both the chat protocol and the RLE decoding! So... will you make an XMPP proxy now to use the Live Messenger for modern IM?
And do you plan to do deeper technical write-ups? Asking for somebody who has unscrambled an obscure compression algorithm and created an API shim for an image uploading service, and blogged about it.
@ge0rg Thank you!!
I'm not sure about XMPP. I was thinking of something along OPAQUE + MLS, but I'm figuring out how to distribute history across devices (in background, that's not my main goal right now).
For now I'll just reimplement the UI on macOS for fun, that by itself will already be a challenge.
I do plan to continue writing! I just published the "formal" specification of the RLE format here: https://vito.io/articles/2026-02-19-the-specification
@vito
Wow, it's been a while since I've seen a LaTeX PDF in the wild.
If your server shim is using a common language, you probably can plug in an existing chat client library and connect to one of the existing networks. I suggested XMPP/Jabber because Jabber IDs have the same format as email addresses, and the presence modes look similar (it was created in 1999 after all), so a converter might be straight forward, and you could use your client to talk to existing communities.
@ge0rg I love LaTeX <3 hehehe
That's one of the options, but I'm not a big fan of how OMEMO works, and crypto/privacy is not optional. I'd love to allow non-tech-savvy folks to also use it, so I would need to hide that complexity somehow. That's why I'm thinking of rolling OPAQUE + MLS. That way the server can't even consider decrypting data, just routing it. Offline messages, for instance, could be temporarily stored, but never read by the server/operators.
@vito
Not a huge fan of OMEMO either, but for rather specific technical reasons.
A consequent from-scratch E2EE design would probably arrive in a different corner of Zooko's triangle (like Briar and friends?). With the original client however you'll have to do bridge-to-bridge encryption anyway, and use IDs similar to email addresses?
@ge0rg Emails would be a problem. But I thought about allowing people to register without one. We could assign a number or UUID and be done with it. Of course, that letting them know that if they lost their random ID, the account would also be gone. The same goes for the password, considering the full crypto.
I'm planning on using the original clients, though. The last version only works up to macOS Mojave. I'm aiming for a full rewrite. New engine, same look-and-feel of the old one.
@ge0rg Usernames aren't bad! That way we can ditch email addresses completely! I love it, will definitely keep that in mind, thank you for the suggestion!
Let me work out the UI, then I can spend some time on internals. BTW I was thinking of implementing the crypto portion in Rust, and FFI everything on all platforms. That way the "real" app only concerns with UI/network/etc. ✨
Vito Sartori (ヴィト) 🦊
Ge0rG