第82話で一件だけになったroom eventから、二つの通知窓が伸びていた。
一つは、senderと本文をそのまま見せるwide preview。
もう一つは、新しいメッセージとだけ知らせるsmall notice。
イトはwide previewを選んだ。
「内容が見えたほうが、すぐ返事できるから」
test tabletをロックし、ラボの机へ置く。
ユイがprivate roomへ次のeventを送った。
マコトへのサプライズは、青い望遠鏡。十八時まで秘密。
tabletが光る。
ロックを開けなくても、ユイの名前と本文が全部見えた。
そこへマコトが戻ってきた。
「青い望遠鏡？」
イトはtabletを伏せた。
もう遅かった。
正しいdeviceへ届いても、秘密は漏れた
通知のtargetは間違っていない。
イトのaccountに結び付いた、イトのtest tabletだ。
別roomへの誤配でもない。
それでも、ロック画面は端末の持ち主だけが見るとは限らなかった。
target account Ito
target app installation tablet-A
wrong device 0
lock-screen content leak 1
surprise preserved 0
ユイ
届く相手は合っていても、画面の前にいる人までは分からないんですね
イト
気づきやすくしたくて、本文を全部載せた。ぼくが見せてしまったんだ
マコト
見なかったことにする。でも、次の通知は別の秘密かもしれないよ
公開notification testまで、あと六十秒。
tableには三台のdeviceが並んでいる。
許可済みのcurrent tablet。
通知を拒否したphone。
appを入れ直す前のold tablet。
次は、誰にも本文を見せずに新着だけを知らせなければならない。
notificationは、message eventそのものではない
room historyにあるのはev-902。
sender、content、server timeは、chat server側に保存されている。
push notificationは、そのeventをもう一度別roomへ保存する仕組みではない。
appを閉じているinstallationへ、小さな合図を運ぶ別routeだ。
今回のremote notification routeを四つに分ける。
1. app server decides whether to request a notice
2. push service accepts or rejects the request
3. device OS applies permission and display settings
4. user sees, taps, dismisses, or ignores it一段目が成功しても、四段目まで終わったとは言えない。
providerがrequestをacceptedにしても、OSがbannerを表示した証明でも、本人が読んだ証明でもない。
電源、network、集中設定、通知channel、ロック画面設定、user actionは、その後に残る。
人の住所ではなく、app installationの宛先
push shelfには、三枚のregistration cardがあった。
一枚はcurrent tablet-A。
一枚は通知を拒否したphone-B。
もう一枚は、appを入れ直す前のold tablet-Aだった。
registration tokenを、人間そのものの永続住所とはみなさない。
同じaccountが複数installationを持つこともある。
appの再install、device変更、provider側の更新などで、registrationが変わることもある。
serverはcurrent registrationを安全に受け取り、accountやinstallationへ関連付け、invalid responseが返った古いものを送り先から外す必要がある。
tokenを画面やlogへ見せる識別名として使わない。
三つの鳴らし方
イトは、全文を出した失敗通知をtest boardへ残した。
その下へ、三枚の案を置く。
イト
A。ロック中でもsender、本文、画像previewを全部見せる。気づきやすさを優先する
イト
B。秘密を守るため、すべてのpushを止める。appを開くまで何も知らせない
イト
C。通知してよいinstallationだけへsmall noticeを送り、ロック中は本文を隠す。tap後にappが認証してeventを取りに行く
Aは、最初の失敗を繰り返す。
Bなら漏れないが、閉じたappの外から新着に気づけない。
Cでも、userが通知を許可していなければ表示を強制できない。
しかし、serverが本文をlock screenへ押し出さずに、新着の存在だけを知らせる余地がある。
Picoは三つの札へ触れない。
wide previewからこぼれた本文と、伏せられたtabletだけをcyan lightで照らしていた。
イトがwide previewを閉じた
イトはAのwide preview shutterを下ろした。
Bのall-stop switchには触れない。
Cのsmall notice gateを、自分の右手で開く。
app server側のfixtureも組み直した。
room event ev-902
recipient account Ito
room muted no
installation tablet-A current
notification mode generic on lock screen
payload event reference + generic noticeprivate message本文と画像本体はchat serverに残す。
push payloadには、今回のappがnotification tapを処理するためのevent referenceと、内容を明かさないsmall noticeだけを入れた。
payloadへ小量のdataを入れられるpush serviceはあるが、通知payloadをmessage databaseや秘密情報の保管庫にしない。
permissionは、serverのleverではなかった
三台のdeviceで、同じev-902を使ったclosed testを始める。
current tablet-Aでは、userが通知を許可している。
app内のroom muteはOFF。
device側のロック画面表示はprivate modeだ。
small noticeが一つだけ出た。
sender名も本文も画像も見えない。
次にphone-B。
app serverがrequestを作れても、OS側のnotification permissionは拒否されている。
表示は0。
serverが勝手に許可をONへ戻すことはできない。
最後にold tablet-A。
push serviceからinvalid registrationが返った。
イトは古いregistrationをcurrent device listから外し、同じ無効宛先へ送り続けるdrumを止めた。
tablet-A current provider accepted 1 / OS notice 1
phone-B denied provider request 1 / OS notice 0
tablet-A old provider rejected 1 / retired 1これは「通知が来ない」を一つの原因へまとめないための記録だ。
server suppression、provider rejection、OS permission、lock-screen visibility、user actionを別欄へ置く。
tapしてから、本文を取りに行った
current tablet-Aのロック画面には、小さなnoticeだけが残っている。
イトがtapする。
deviceはまずunlockを求めた。
unlock後、appが開き、current sessionを確認する。
そのsessionでroom-blueのev-902を取得できるか、serverがauthorizationを照合した。
そこで初めて、ユイの本文がapp内に出る。
lock-screen content leak 0
generic notice displayed 1
user tap 1
authenticated event fetch 1
message shown inside app 1notification表示とchat deliveryは同じreceiptではない。
noticeを見てもappを開かない人はいる。
tapしてもsessionが切れていれば、loginからやり直すことがある。
push serviceがacceptedを返しても、userが見た・読んだとは断定しない。
イトはsender側のread lampへ、notificationのaccepted signalをつながなかった。
呼び鈴では、本文を運べない相手
公開testのclockが0になった。
三台の結果は混ざらず、別々の欄に残っている。
秘密の本文は、ロック画面へ戻ってこなかった。
そこへ、廊下の郵便受けが一つ開いた。
appをinstallしていない相手へ、長い案内を送りたいというrequestだった。
手元にあるのは、push registrationではなくemail address。
small notice capsuleでは、本文を相手の受信箱へ運べない。
イトはgeneric noticeをtabletへ残し、長い本文の封筒を郵便routeの入口で止めた。
次回、ピコルート第84話。
イトは、宛先だけでメールを送れる？｜受信箱までの郵便路