Tether：LinuxでiPhoneのiMessage・SMS・通知を実現

Appleの庭の壁を少しずつ削っている作者に最大限の賛辞を送ります。

私は15年間iPhoneを使ってきましたが、これまでWindowsのiTunesでしかバックアップできませんでした（Macは絶対に買わないので）。

Appleが相互運用性を拒否するのは、犯罪的と言ってもいいくらいです。もっと良い選択肢があればいいのにと思います。

iMessage統合のセキュリティ面はどうなっているのでしょうか？なぜiOSは、同じユーザーとしてサインインした正当な認証済みデバイスであることをAppleに証明していないデバイスに、Bluetooth経由でiMessageデータを送信するのでしょうか？

これはすべて、iPhone（または他のデバイス）上のブローカーアプリがデータを送受信することで可能になっています。

最初に見出しを読んだときは、中間者なしでAppleエコシステムに直接統合されるのかと思いました。それは信じられないほど素晴らしいことですが、ほぼ完全に不可能だと思います。

KDE Connectを数年使っているユーザーとして、特にスマホとラップトップのスリープ時などに再接続が必要で、常にうまくいくわけではないことを知っています。しかし、Androidではクリップボード同期、通知、SMS、通話、リモートコントロール、メディア再生コントロールなど、すべてを実現しています。作者がこれほど立派な努力をされたのは、iOSの制限によるものでしょう。

つまり、LinuxエコシステムはAndroidと直接の関係がなくても、より良い垂直統合を実現しているということです。

これは明白な質問かもしれませんが、OpenBubblesと同じものを使っているのでしょうか？OpenBubblesの良いところは、Appleのサーバーに直接フックするので、スマホとの接続が不要なことです。

リンクされているblueferryのドキュメントは素晴らしいです。2020年に、HNのコメントに触発されて、Bluetooth Message Access Profile（MAP）で接続されたiPhoneを介してLinuxでiMessageを送受信するプロキシを書くことを検討しました。メッセージの送受信はできましたが、ドキュメントの「Group metadata side channel」セクションで言及されている問題に遭遇しました。受信トレイのbMessagesにはメッセージの発信元が含まれていましたが、受信者が含まれていませんでした。MAP標準では「含まれるべき（shall）」とされているにもかかわらずです（22ページ参照）。ANCSを知らなかったので、そのチャネルを使うことは思い浮かびませんでした。メッセージがどのようなコンテキストで送信されたかを判断する方法がなければスレッド化ができないため、追求する価値はないと判断しました。

グループメッセージが最大の問題で、それが原因で諦めましたが、他にもいくつか問題がありました：

- 共有リンクが「Website: Short description (example.com)」と表示され、URLが含まれていませんでした

- 画像がまったく表示されませんでした

blueferryがこれらの制限にどう対処しているか、見てみるかもしれません。

[blueferry doc] https://github.com/erikwb/blueferry/blob/main/PROTOCOL.md

[inspiration] https://news.ycombinator.com/item?id=23411520#23413394

[Bluetooth MAP standard] https://www.bluetooth.com/specifications/specs/message-acces...

うわあ、これはBlueBubblesブリッジを介して送信するよりもはるかに優れていますね。これが本当に機能するなら、寄付します！素晴らしいプロジェクトです！