Web Push و Email Notification Delivery

Provider درخواست را قبول کرده؛ آیا learner واقعاً چیزی دریافت کرده؟

یک reminder تکلیف برای Web Push در queue است. learner بعداً permission پوش را revoke می‌کند، اما fallback ایمیل هنوز مجاز است. یک push قدیمی‌تر از provider پاسخ پذیرش گرفته، ولی هیچ evidence قابل‌اعتماد از delivery به end user نداریم. اگر سیستم همهٔ این وضعیت‌ها را در sent=true جمع کند، دیگر نمی‌تواند push لغوشده را suppress کند، event قبلی را UNKNOWN_DELIVERY نگه دارد و fallback مجاز را بدون duplicate بسازد.

در این درس Notification Consent, Dispatch & Delivery Evidence Matrix v1 را می‌سازیم. intent، purpose، channel permission، endpoint/address validity، preference version، dispatch identity، provider acceptance، delivery/bounce/complaint evidence، suppression، retry budget، fallback و final certainty باید stateهای مستقل بمانند.

قاعدهٔ اصلی: permission فقط attempt را مجاز می‌کند؛ provider acceptance فقط transport evidence است؛ delivery certainty فقط با evidence واقعی delivery قوی‌تر می‌شود.

مخاطب: مهندس learning platform، طراح notification service، reliability engineer، product/privacy reviewer و QA. غیرهدف: اثبات read شدن پیام، ساخت consent از روی نیاز محصول، یکی‌گرفتن DKIM با inbox delivery، یا retry کردن بعد از تغییر preference بدون recompute.

جایگاه درس و مرز مالکیت

MKN-022 فقط مالک Web Push و Email Notification Delivery است. prerequisite فریز‌شده MKN-021 است. MKN-021 مالک contributor/editorial governance و MKN-023 مالک AI Tutor grounding/evaluation است؛ این درس outcome آنها را جذب نمی‌کند.

مسیر foundation با field map و یک mutation هدایت‌شده کار می‌کند. مسیر repair اولین state نامعتبر را isolate می‌کند و فقط gate مربوط را rerun می‌کند. مسیر experienced دربارهٔ retry، suppression، fallback و observability تصمیم می‌گیرد بدون اینکه provider response را به یک success flag تبدیل کند.

Checkpointها: F1 مرز و یک non-goal؛ F2 تشخیص push queued بعد از revocation؛ F3 بازسازی dispatch بعد از rotation endpoint، تغییر preference version و temporary email failure.

مدل ذهنی: intent → eligibility → idempotent dispatch → evidence → bounded final state

ترتیب مرجع:

notification intent → purpose + current preference → channel permission/validity → idempotent dispatch → provider evidence → delivery/bounce/complaint evidence → suppression/retry/fallback → final state

این لایه‌ها را collapse نکن. notification ممکن است authorized ولی هنوز queued نشده باشد؛ queued باشد ولی قبل از dispatch suppress شود؛ provider آن را بپذیرد ولی delivery نامعلوم بماند؛ temporary failure و retryable باشد؛ permanent bounce شود؛ یا به‌خاطر complaint suppress شود. retry و fallback به همین تفاوت‌ها وابسته‌اند.

قرارداد پایه: هر fact که می‌تواند send را باطل کند version/state مستقل دارد

Dimensionهای فریز‌شده: notification_intent_id, channel, purpose, consent_state, permission_state, push_subscription_ref, subscription_expiry, email_address_ref, preference_version, template_version, dispatch_id, idempotency_key, provider_message_id, queued_at, accepted_at, delivery_signal_at, bounce_class, complaint_state, suppression_state, revocation_state, retry_count, retry_budget, fallback_channel, dkim_state, unknown_delivery.

Invariantها:

1. dispatch باید به current preference version bind شود، نه نسخهٔ زمان queue.
2. push permission و subscription validity در زمان dispatch دوباره check می‌شوند؛ revocation future attempt را suppress می‌کند.
3. logical dispatch یک idempotency identity پایدار دارد؛ retry نباید به notification دوم تبدیل شود.
4. provider acceptance بدون delivery signal معتبر، DELIVERED نیست.
5. DKIM authentication evidence است، نه inbox placement، read receipt یا engagement.
6. permanent bounce یا complaint طبق policy channel را suppress می‌کند؛ transient failure فقط retry budget را مصرف می‌کند.
7. fallback هم current preference/permission و هم policy صریح لازم دارد؛ urgency محصول revocation را override نمی‌کند.
8. evidence ناقص در UNKNOWN، HOLD یا INSUFFICIENT_EVIDENCE می‌ماند.

توضیح عمیق: استانداردها دقیقاً چه چیزی را ثابت می‌کنند؟

W3C Push API. Push subscription یک delivery context بین user agent و push service است؛ endpoint، expiration احتمالی، Service Worker، refresh/deactivation و permission پوش را تعریف می‌کند. Working Draft جاری می‌گوید revocation permission باعث deactivation subscriptionهای مربوط می‌شود. این facts برای lifecycle معتبرند، ولی purpose، preference version، retry budget یا fallback policy MAKNOW را تعریف نمی‌کنند.

RFC 8030. Web Push application server، push service و user agent را جدا می‌کند. application server می‌تواند delivery request بدهد و push service پاسخ 201 Created بدهد. این پذیرش service است، نه اثبات delivery به user agent. پس provider accepted یک transport state است، نه learner-delivery claim.

DKIM / RFC 6376. DKIM با signature رمزنگاری‌شده اجازه می‌دهد signing domain مسئولیت یک message را claim کند. DKIM PASS به معنی inbox delivery، visibility، read یا اثر آموزشی نیست.

در نتیجه purpose taxonomy، consent/preference ledger، idempotency، retry budget، fallback precedence، suppression window، complaint handling و learner-facing policy همگی MAKNOW DESIGN هستند.

مثال‌های حل‌شده

مثال A — push accepted اما delivery نامعلوم

PREF-17 push و email fallback را مجاز می‌داند. permission granted است و PS-88 active است. D-PUSH-41 با key منطقی N-441|push|PREF-17 یک‌بار submit می‌شود. provider آن را accept می‌کند ولی delivery signal قابل‌اعتماد نداریم.

نتیجهٔ درست: accepted_at را نگه دار، unknown_delivery=true بماند و DELIVERED ننویس. retry فقط از policy و evidence transport می‌آید، نه از میل سیستم به success.

مثال B — revoke شدن permission بعد از queue

reminder ساعت 09:00 queued شده؛ learner ساعت 09:03 push را revoke می‌کند؛ worker ساعت 09:05 queue item را می‌خواند. worker باید current permission/preference را بخواند. push به SUPPRESSED_REVOKED می‌رود. queue-time permission authority ندارد.

اگر current preference ایمیل fallback را مجاز کند، dispatch جدید channel-specific و idempotent را از همان intent و preference version جاری بساز. stale push dispatch را reuse نکن و هر دو channel را صرفاً چون قبلاً eligible بوده‌اند ارسال نکن.

مثال C — temporary email failure

email fallback مجاز است. DKIM configured است و provider submission را می‌پذیرد، اما بعد temporary failure می‌دهد. dkim_state=PASS فقط authentication است. اگر retry_count کمتر از retry_budget باشد و complaint/suppression نداشته باشیم، همان logical email dispatch را idempotently retry کن. وقتی budget تمام شد، stop/escalate کن؛ dispatch جدید برای دورزدن budget نساز.

Failure modeهای رایج

• sent=true بلافاصله بعد از provider acceptance؛ queue، acceptance و delivery را یکی می‌کند.
• استفاده از permission snapshot زمان queue؛ preference/revocation جدید نادیده گرفته می‌شود.
• retry با idempotency key جدید؛ uncertainty را به duplicate risk تبدیل می‌کند.
• fallback به‌عنوان override؛ opt-out یا suppression جاری را نادیده می‌گیرد.
• DKIM-as-delivery؛ authentication را inbox evidence جا می‌زند.
• تشخیص غلط transient/permanent bounce؛ retry یا suppression اشتباه می‌شود.
• complaint ignored؛ sendهای بعدی ادامه پیدا می‌کنند.
• subscription rotation ignored؛ endpoint stale retry می‌شود.
• coercion of unknown؛ نبود receipt به DELIVERED تبدیل می‌شود.

Alternativeها و trade-offها

At-most-once در برابر retry. at-most-once duplicate را کم می‌کند ولی در uncertainty delivery miss بیشتری می‌دهد. retry فرصت delivery را بالا می‌برد اما idempotency پایدار و budget محدود می‌خواهد.

Push-first در برابر intent ledger channel-independent. push-first ساده‌تر است اما orchestration را به channel خاص گره می‌زند. intent ledger verboseتر است ولی preference change، fallback و audit را روشن می‌کند.

Provider-specific receipt در برابر certainty portable. receipt provider-specific observability را بهتر می‌کند، اما قرارداد portable باید وقتی signal معادل ندارد UNKNOWN_DELIVERY را حفظ کند.

Fallback فوری در برابر delayed fallback. fallback فوری ممکن است duplicate بسازد؛ delayed fallback ممکن است ارزش زمانی را از دست بدهد. policy باید trigger، delay، permission recheck و cancellation rule را مشخص کند.

پل experienced: notification delivery یک distributed evidence ledger است

در production، queue item باید intent ID، preference version، channel و logical idempotency identity را حمل کند. worker نسخهٔ stale preference را reject می‌کند. provider callback به‌عنوان evidence append می‌شود، نه destructive rewrite. bounce/complaint مستقل وارد suppression می‌شود. reconciler می‌تواند accepted-but-unknown، exhausted retry budget، stale endpoint و orphaned dispatch را کشف کند.

Metricها را هم جدا کن: intent created، eligible، attempted، provider accepted، reliable delivery signal، temporary failure، permanent failure، complaint، suppressed، unknown. یک delivery rate فقط وقتی معنی دارد که denominator و semantics evidence روشن باشد.

تمرین هدایت‌شده و مستقل

Guided. MKN-022-LAB1 را روی baseline اجرا کن و evidence matrix را پر کن. سپس mutation «revocation بعد از queue و قبل از dispatch» را اعمال کن و اولین field باطل‌شده و minimal safe action را نام ببر.

Independent. چهار case را تشخیص بده: provider acceptance به‌عنوان delivery؛ retry با idempotency key متفاوت؛ complaint ایمیل در حالی که fallback تعریف شده؛ و old push retry بعد از preference-version update. برای هرکدام decisive evidence، terminal state و امکان fallback را مشخص کن.

Transfer. subscription پوش rotate می‌شود و email provider بعد از preference update temporary failure می‌دهد. تصمیم را از current permission، preference version، endpoint جدید، provider evidence قبلی، retry_count/budget و fallback permission دوباره بساز. baseline label oracle نیست.

Verification و evidence

Lab کاملاً offline و synthetic است: fixtureهای JSON و ruleهای deterministic Python؛ بدون network، provider API، آدرس واقعی یا learner data. Lab current preference binding، push permission/subscription validity، idempotency reuse، جداسازی provider acceptance از delivery، مرز DKIM، bounce/complaint suppression، retry budget، fallback مجاز و transfer recomputation را می‌سنجد.

یک evidence row معتبر باید پاسخ بدهد: purpose چه بود؟ کدام preference version channel را مجاز کرد؟ permission زمان dispatch هنوز valid بود؟ endpoint/address جاری کدام بود؟ logical dispatch و idempotency key چه بود؟ provider دقیقاً چه چیزی را ثابت کرد؟ delivery معلوم است یا unknown؟ bounce/complaint داریم؟ suppression/revocation داریم؟ retry budget مانده؟ fallback الان مجاز است؟ چرا final state از این evidence قوی‌تر نیست؟

Assessment و gate انتقال

چهار assessment blocking:

1. مرز MKN-022 و یک non-goal مجاور را توضیح بده.
2. evidence matrix کامل baseline synthetic را بساز.
3. revocation بعد از queue و قبل از dispatch را diagnose و minimal repair را مشخص کن.
4. subscription rotation + preference-version update + temporary email failure را بدون duplicate recompute کن.

Transfer fail است اگر baseline verdict کپی شود، queue-time permission authority فرض شود، idempotency برای «دوباره امتحان کردن» عوض شود، provider acceptance/DKIM delivery فرض شود، یا fallback برخلاف preference/suppression جاری استفاده شود.

منابع، freshness و مرز authority

W3C — Push API https://www.w3.org/TR/push-api/ FACT: Working Draft جاری subscription، endpoint/expiration، refresh/deactivation، Service Worker relation و permission پوش را تعریف می‌کند و revocation را به deactivation subscription مرتبط می‌کند. مرز: purpose/preference/retry/fallback MAKNOW را تعریف نمی‌کند.

IETF RFC 8030 — Generic Event Delivery Using HTTP Push https://www.rfc-editor.org/info/rfc8030/ FACT: نقش‌های Web Push و delivery interactions را تعریف می‌کند. 201 Created از push service به‌تنهایی delivery به user agent را ثابت نمی‌کند. مرز: transport semantics است، نه communication policy learner.

IETF RFC 6376 — DKIM Signatures https://www.rfc-editor.org/info/rfc6376/ FACT: signing domain با cryptographic signature مسئولیت message را claim می‌کند. مرز: inbox placement، read یا engagement را ثابت نمی‌کند.

منابع در 2026-09-13 دوباره بررسی شدند. Push API را حداکثر تا 2027-01-15 یا زودتر در publication materially newer بازبینی کن؛ RFC status/errata را هم در همان cadence یا زودتر در update مهم بررسی کن. purpose taxonomy، preference/consent ledger، idempotency، retry budget، fallback و suppression policy و delivery-certainty vocabulary MAKNOW DESIGN هستند.