What I find frustrating is that I cannot read or write SMS or iMessages on my computer (I don't use OSX). I'm not going to be that person who asks all their contacts to message them using some new app. Can this service really interface with iMessage somehow? I thought it was locked down by Apple.

I'm guessing it'll somehow have to scrape the macOS client, with obvious implications. There is no way they'll manage to integrate with the servers directly.

> There is no way they'll manage to integrate with the servers directly.

Of course they will be able to do that. It's 100% possible.

How, if the client authentication key is implemented in Apple's hardware?

At least the device serial number is already used as part of iMessage authentication (it needs to be spoofed to work on Hackintoshes as far as I've read), and Apple has secure hardware that can easily support actual attestation in all of their recent devices.

> How, if the client authentication key is implemented in Apple's hardware?

It isn’t.

Ok, maybe I should have been more precise:

Authentication already involves an Apple-specific hardware property (i.e. the serial number), demonstrating Apple's dislike for third-party clients.

It would be trivial for them to introduce a more effective means of client attestation (e.g. FairPlay DRM, which is alreadypart of every iOS and macOS device).

I certainly hope I'm wrong about this (I'd love to see a third-party client for iMessage), but I'm pessimistic.

Messages.app has a SQLite database that that be queried, I'm imagining they're building off of that.

Looks like Matrix is really taking off - this is the third "unified messaging interface" app on HN this week.

Texts runs completely locally and isn't based on Matrix. It uses a custom protocol designed in house more suited for bridging. All platform integrations have been developed from the ground up as well.

How do you know?

How could it be more suited to bridging than Matrix which had bridging in mind since it's existence?

Good to know, and very cool that it works for iMessage, but using a proprietary protocol for bridging when all of the competitors are using a standardized one that is likely to grow in functionality much faster than yours may not be the best choice.

Which platforms are actually supported? I didn't find that on the landing page. Seems like an interesting product if it works on linux and with Signal etc.

BUT: Stating "Privacy first." as a goal and then requiring to sign up with google is … inconsistent at least (I get that it's easier though).

There is a link underneath that allows you to fill in a form with your email

Thx, I must have missed it (it admittedly is very small ^^)!

There's so many of these but all are in "early access" phase...seems like they haven't figured out how to do iMessages integration and it's just a nicely designed UI with no real product.

+1, the real challenge here isn't UI design, it's integrating with several messaging services that are actively preventing being integrated in such a way.

Texts is a live product (landing page has a real screenshot) and it does support iMessage on Mac by connecting to the official process. We've done the most extensive research on it afaik.

How are you integrating? What is the "official process" mentioned? As far as I know, there are no Apple APIs built for these integrations.

Are you just connecting to the local SQLite database?

Official Messages app/process. And we do connect to the SQLite for reading stuff.

Oh as in interacting with the app? I looked a while back to see if it was AppleScript-able but seemed to be no longer supported. Are you using something else? Or are there actually APIs in MacOS to hit?

All these messaging startups are really dug in on the idea that nobody uses SMS. I guess that's fine depending on which bubble you live in, but the company who cracks that case stands to gain a lot. And yes, I know there are parts of the world who never use SMS. There are other large parts who do and they have money too.

There's an SMS bridge for Matrix right now, and has been for awhile. Caveats are that I have only seen the Android client when browsing F-Droid, and I haven't tried it myself yet. All the other bridges I do use (Whatsapp, Telegram), however, have been top notch

FWIW, this looks like it's macOS only so far, and by integrating with iMessage it would support SMS as well (at least for iPhone users that have forwarding to iMessage enabled).

Wow how much was that domain name?!

Earlier alternate -> https://valyr.io/

Planned support for also Email (first priority), SMS, Signal, matrix, etc

details? Advantages over Beeper and this one?

Where are they all coming from suddenly? curious

This one has been in dev since over a year ago I think but yeah I have no idea where all the new ones are coming from!

My biggest concern is the notifications. I already have problems with multi-device notifications while using directly the messaging platforms (Telegram, FB Messenger, etc.), I think that adding an extra layer on top would make the notifications even less stable (getting same notification on multiple devices even after reading the message, not getting notifications on some devices, not receiving messages, etc.)

Advantage over Beeper? HN: https://news.ycombinator.com/item?id=25848278

Sign up for your service based on a screenshot and a few blurbs?

"Sign Up" goes straight to logging in with Google, which is pretty jarring since it doesn't even mention Google on the button.

Signal is conspicuously absent from the list of supported platforms...

Signal integration is in alpha, not launched to users yet.

There's no open API which is a problem when things are E2E encrypted.

Neither is there for iMessage or WhatsApp.

Most WhatsApp clients rely on scraping the websocket channel used by the official web client, but that requires your phone to be online to send and receive new messages.

I'm assuming iMessage scraping happens on macOS, requiring your mac to be online as well.

Pidgin fork?