Show HN: Messages for Macintosh – a classic Mac iMessage client | Hacker News Reader

Show HN: Messages for Macintosh – a classic Mac iMessage client

github.com

211 pointscamhenlin47 comments

I built an application for interacting with Apple iMessages on classic Macintosh systems via a modern Mac. I've tested the software on System 2.0 through System 6.0.8, but it should work on Macintoshes running up to MacOS 9.2.2.

In addition to the github repository, I wrote an introduction blog post about it here: https://henlin.net/2022/02/26/Introducing-Messages-for-Macin.... I've also outlined the development workflow on to other posts at https://henlin.net/2021/12/03/a-simplified-guide-to-developm... and https://henlin.net/2022/02/26/Messages-for-Macintosh-Develop....

Let me know if you have any questions or decide to try it out on your Macintosh, I'd love to hear about it.

I've thought about hooking into messages w/ a running mac before... Do you have a high level description of your approach? I looked in the iMessage GraphQL Server server repo for docs but didn't see anything obvious...

On a quick investigation I noticed you are reading the sqlite db... but it wasn't super clear how you send/receive messages?

I’m doing polling the Messages SQLite database to detect receiving new messages, and and using built in Messages scripting capabilities to send messages. See here: https://github.com/CamHenlin/imessagegraphqlserver/blob/main...

classic Mac coder here -- some experiments might show.. that software development is not bad for this 25 year old system.. the user experience is calm, cool and collected IMHO. But anyone with an interest in graphics will find that even with later "faster" models of Mac, the JPEG and PNG decompression will be amazingly slow compared to modern times. That is not to say that plenty of interesting and modern software will not be useable - it is.. rather the sheer math and bit-movement involved in quick JPEG decompression might come as a shock to phone users of today. Overall, very supportive of "OS archeology" here.

Also modern cryptography. I remember reading somewhere that some old computers are so slow with it that the server times out before the client has a chance to complete the key exchange algorithm.

M68k may be slow, but a g3 ppc will be fast enough.

An impressive proof-of-concept.

The UI elements look rather odd. What's the rationale for using a custom immediate-mode UI library instead of using the Mac's native forms and toolbox routines for them?

Sure, I felt like having a simple immediate mode library would make UI programming on old Macs a lot easier. I still think that’s true after getting the UI library working and having used it for a project. I wrote a blog post explaining my reasoning here as well: https://henlin.net/2021/12/21/Introducing-Nuklear-for-Macint...

It makes a lot of sense and toolbox programming is a pain - it was quite low-level in its day too. The downside is the you end up with an app that runs on classic MacOS but doesn't look anything like a classic MacOS app. I think that's a problem somewhat inherent in the platform - the system-provided GUI programming model was primitive but users cared about the look/feel of the UI just as much if not more than now.

I'm not sure I'd agree that the Mac toolbox is primitive. Reflowing forms to reflect a resizable window wasn't a common technique at the time; Macs had a predictable screen size and DPI. Abstracting the layout of a form from code via a resource was a very forward-thinking approach for the day. Among other advantages, fiddling with ResEdit was very empowering for users who might not even have access to the source code of an application!

It's not really primitive by intent but it's quite primitive in reality because of the drastic constraints on the original target platform. So yes, things like resources are a place where intent and implementation are relatively close but much of the rest of it isn't. Consider that System 6/7 are of the same vintage as Nextstep and the Nextstep model is still in very wide practical use today.

Probably familiarity and ease of development.

Is there a proper API for Apple imessage such that I can create imessages from the command line ?

I send SMS with 'curl' commands using my twilio credentials ...

Can I do something similar with imessage ?

I've seen a few random libraries/hacks/topics on GitHub. I can't say how outdated or if any are functional.

https://github.com/btroo/messaging-vis

https://github.com/topics/imessage

https://github.com/drbh/power-message

https://github.com/wtfaremyinitials/osa-imessage

I even have some older projects in this space:

https://github.com/CamHenlin/imessageclient

https://github.com/CamHenlin/iMessageWebClient

https://github.com/CamHenlin/iMessageModule

Not curl, but https://github.com/open-imcore/barcelona may be of interest (I believe you might have to disable SIP and AMFI though). The Matrix-iMessage bridge uses and I find it to work quite reliably and quickly.

You can write it in applescript

https://stackoverflow.com/questions/11812184/how-to-send-an-...

Unfortunately, there's no way other than what the author used.

Not even through a third party like Twilio

For iMessage you can use Bitlbee and any IRC client.

No.

Does this mean we could write and iMessage client for Linux?

This has the same limitations of every other 3rd party iMessage client. It needs a companion app running on a Mac so that it can interface with iMessage running on that Mac. Basically it’s an iMessage proxy/client.

I would love to transition to a Linux for most things but I can’t give up the ability to text via my mac desktop. It’s so much faster and I barely suffer a context switch.

Having to stop and pick up my phone to type with my thumb is just agonizing. And not everyone I deal with is on slack.

There are obvious problems with bringing iMessage to other platforms (basically the standard for any proprietary platform).

But a few other issues are these various cryptographic ties to things like appleid etc, which are likely harder to deal with.

I believe old black hat demos from 5+ years ago when they found some protocol flaws were constructing the message content manually, but still sending them through the messages xpc service (which is afaik responsible for wrapping things in protocol goo)

There are other issues as well nowadays: all apple hardware for many years has been able to store keys in the Secure Enclave (or element? One is for crypto, one is for javacard, and I can never remember which), so there’d be a loss in security posture relative to apple hardware (I would put money on the SE/SEP being more secure than any hardware crypto wallet - it’s just you can’t unplug it, so you lose the very real security of an air gap)

With KDE Connect I can send SMS right from my desktop. It ain't iMessage, but I have maybe one or two contacts who use it anyways. Anyone who wants more features can message me on Telegram or Slack.

cplusplusfellow if your contacts transition to the likes of Signal [0], you can then message from phone or computer. They have software for Windows, Mac and Linux.

[0] signal.org

Given how long it's existed, I'm surprised no one has RE'd and written a compatible 3rd-party implementation.

I think the challenge is more related to extracting ever-changing encryption keys and trust models.

This package would be pretty trivial to port to Linux, and you could make some pretty large improvements running on a more modern system

The problem is you still have to have a Mac to do the actual work, but then the M1 mini is fast and reasonably priced so maybe could be set up with a cross compiler so you could have it doing something else useful rather than being (despite the price as a computer being reasonable) a very expensive messaging client :)

Obviously assuming linux is your main environment so a single Mac wouldn’t have additional use otherwise. If you did also run a Mac anyway having the proxy/forwarding to any machine you were working on would be super nice (similar to text forwarding to your desktop so you don’t need to get your phone all the time)

I miss Classic box art.

Yeah! I had a lot of fun gathering up lots of other Classic box art and designing the box art for this project!

Yeah, I appreciate a lot of digital distribution but there’s something nice about the packaging of old non-game software

This is awesome! I sort of want to dust off one of my old PPC Macs and try this out — tho I’d have to put MacOS 9 on it first (I think I’ve only got OS X on it). What a great/fun little project!

Cameron, that's awesome, congratulations. I'd love to read about the developing process in a blog post.

Now you just need a cool icon to go with your app. You already have the box art spot on

This is absolutely awesome, I cannot wait to install it on my mac color classic!!

Let me know how it goes! I’m really interested in hearing how it goes on some higher end equipment. I personally haven’t tried anything other than 68000-based systems

Very cool

Ok but why?

As with many such hobby projects it’s a “why not?”. Not every project must have some kind of serious “value”

Just 10 conversations? It would be better to use an IRC client against Bitlbee.

As for the irc client, use any.

You're perhaps missing the point of this.

It's clearly not meant to be something you'd use regularly. It looks like an excercise of "let me see if I can do this"

If you're arguing about practicality, then you've already missed the boat by a few decades if you're running on this ancient OS.

I’m not seeing where Bitlbee supports iMessage. Is a plug-in needed for that support?

Bitlbee supports libpurple (Pidgin) plugins. That's how I message over Telegram with sic (tiny IRC client) against Bitlbee to people using smartphones around.

OK, but iMessage isn’t Telegram. There are Matrix bridges that support iMessage to varying degrees of success/features, but I’m not sure if the Matrix feature via libpurple would support whatever bridges you have configured inside Matrix. It seems like a lot of additional work/hypotheticals for something that is just a fun proof of concept.

Certainly there’s a lot of opportunities for improvement here!

Yep. This looks a bit clunky. Any old/rusty irc client (even the ones for DOS and a 286) will connect to public bitlbee servers, where you have several. By typing up 'plugins' at its &bitlbee channel (not a typo), you will get the supported chat protocols on that server.

Reply on news.ycombinator.com