STと違って、iMastはプッシュ通知専用のアクセストークンを端末ごとに取得する方式を取っています。バックアップ/エクスポートを考慮すると、この方式はプッシュ通知関連の情報を丸ごとエクスポートの対象外として扱えるので明瞭で良いのでしょう。

WebPush自体は暗号化の仕組みを備えているのですが、WebPushでブラウザに送れるデータ長の最大よりFCMでアプリに送れるデータ長の最大の方が25%くらい短いのでそのままアプリに転送することはできません。
アプリサーバ上で暗号を解除してデータ量を削減するか、もしくはデータを丸ごと無視してトリガーのみをアプリに送るかしないといけません。
前者はセキュアとは言い難いのでSTは後者にしてます。ただしアプリ側でもREST APIで読み直す事になるので通知が多い&端末が多いとrate limitの問題が出ます。解決してません。
タンスに購読リクエストを投げる時に必要な鍵ペアの生成もアプリ側でやるといいんでしょうけど、上記の選択で迷ってたんで、今はまだアプリにハードコードした公開鍵をタンスに送ってますね。そのためアプリサーバではメッセージの詳細を無視してることを証明する術がありません…。

@kedama 15分おきにREST APIで通知を読むだけの最も素朴なやつですね。Googleなど外部のサーバにデータを渡したくないからだそうです。https://github.com/tuskyapp/Tusky/issues/793

方式としては他にもアプリサーバにアクセストークンを渡して通知ストリームを読ませてからFCMでアプリに投げるとかあります。Tootdonや昔のSTはそうやってました

@kedama 試してないけど、聞いた話ではTuskyはWebPushに対応してません。アプリ側で定期的にチェックするPull通知チェックだと思います。Androidの制限で15分間隔

QRコード決済はアプリの画面を表示する必要があるので、広告を表示する機会が多い。位置情報どころか決済相手の情報まで利用した広告をばんばん出せる。企業側にはメリット多いよね。
コンビニでビールを買ったらライバル社の銘柄のクーポンや、生活習慣病むけの保険の広告がついてくる世界。

既に安定したシェアがあり、企業による利用データの取り扱いが大人しい交通系ICカードが派手なキャンペーンや営業活動をやる意義はないな。
ユーザの金の流れを記録して保険会社と提携して儲けようというなんとかペイがキャンペーンうちまくるのは理解できる。

@kedama タンスから直接FCMやmozillaに投げてるのはWebブラウザーのPWAへのWebPushだったりしませんかねー。
あとはデータメッセージだけじゃなくて通知メッセージを送って、ユーザがそれをタップした時点で初めてアプリに送られるスタイルのもありますけど。

@kedama FCMにアプリを登録したら、FCM用のキーをつけてFCMにリクエスト投げるとアプリにデータメッセージが届くの。
で、そのキーは誰にも渡せないからタンスからは一旦アプリサーバにWebPushなげてもらって、アプリサーバからFCMに投げ直すの。

ちなMastodonのアクセストークンはプッシュ通知でスコープが増えてるので、サーバとアプリの両方が対応する前に取得したアクセストークンではプッシュ通知は届きません。またマストドンはアクセストークンごとにプッシュ通知の送り先を一つしか設定できないので、設定のバックアップからの復元などでは取りあえず使えてもトークンを更新しないとプッシュ通知が届かない事があります。また、同一クライアントIDと同一ユーザに対して一意のアクセストークンが生成されるので、複数の端末でクライアントIDを再利用する設計のアプリでは1端末しかプッシュ通知を受け取れません。

@kedama
アプリサーバに保持したFCMキーを使わないとFCMデータメッセージの送り先をアプリにできないじゃん？

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

https://github.com/tootsuite/mastodon/issues/11285 雑に投げた