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.
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?
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.
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.
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.
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.
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)
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!
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
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.
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.
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.