#Aims and reasoning
An interruption creates an obligation before a person has chosen to read. TalkCo should help people answer one another without turning availability, reaction counts, or notification badges into a demand for constant attention.
#Low by default, and never gamified
Broadcast channels are pull by default: people read their bounded feed when they choose. Conversations may notify because a message is addressed to someone. Neither surface uses engagement badges or a caught-up state that nudges someone to return.
Recipient control matters alongside interruption reduction: total suppression can create anxiety about missed obligations, while expectations of quick responses create pressure of their own (PielotRello2016, Horvitz2003, BarberSantuzzi2015).
#Reactions notify only when they are answers
A deliberate “got it”, “will reply later”, or yes/no/maybe answer may notify as a lightweight reply. Ordinary emoji reactions stay quiet by default. Broadcast feedback is author-private and never an interruption for other viewers; §05 defines conversation semantics.
#Priority is a sender's hint; the recipient always wins
Normal, high, and emergency are a working vocabulary for a sender's intention. They are not remote commands. The recipient decides which contacts, contexts, and conversations may interrupt in the current mode, and can change that choice at any time.
#A visible cost for crying wolf
High and emergency priority carry visible markers. Rough local history can make repeated use understandable without converting it into a hidden trust score or public reputation. Communities can agree on expectations, but recipients retain control.
#Priority budgets should not become math
A fixed monthly emergency allowance would fail during a crisis. TalkCo therefore favors understandable recipient rules over sender-side emergency tokens. No priority label should imply guaranteed arrival or that someone is obliged to respond.
#Modes are built on contexts, not closeness tiers
Focus, work, deep-work, sleep, social, and emergency-only modes use the contexts people already maintain (§03). They do not require scoring relationships or organizing every contact upfront.
Emergency exceptions are recipient-selected. One device may allow them while another remains silent. Useful controls stay shallow: current mode, context default, thread override, temporary mute, and review schedule.
#Rate-aware notification
Busy threads can be batched by visible rules. A finite review tray groups deferred interruptions by context and conversation, explains why they were held, and offers a direct adjustment. It is not another endless feed and does not rank obligations by predicted engagement.
“Delivered without interruption” feedback is optional and context-specific. It must not reveal a person's sleep, work schedule, or availability to everyone who can send a message.
#Protocol and architecture
#Delivery produces a local decision, not a remote instruction
A thread override may refine the recipient's policy; it cannot bypass a global prohibition unless the recipient explicitly created that exception. Sender priority is authenticated message data consumed by these rules. Network priority, if a provider exposes it, is a different mechanism and cannot prove social urgency.
| Seam | Likely candidate and status | Local responsibility |
|---|---|---|
| Pending items, deduplication, reasons, schedules | SQLite / rusqlite; provisional baseline | Persist decisions across restarts without creating engagement analytics. |
| Delivery and retries | Shared Rust/Tokio core plus selected carrier; implementation candidate | Own durable retry state; notification UI does not create a second delivery queue. |
| Cross-device preferences | Encrypted owner-only state; mechanism open | Sync account defaults while retaining device-specific suppression and OS control. |
| User-visible interruption | Android notification APIs and Apple UserNotifications; platform adapters | Respect user permission, categories, Focus/Do Not Disturb, and lock-screen privacy. |
| Wakeup service | APNs/FCM, UnifiedPush where supported, or pull; alternatives | Minimize payload and linkage; measure delay, battery, outage, and metadata. |
The tools inventory owns package qualification. Android's notification-channel API gives users control over channel behavior; TalkCo preferences cannot override those system choices.
#Variation — Opaque wakeup with local evaluation
Payloads should omit plaintext, sender names, channel names, and reusable context identifiers. Device tokens, timing, traffic size, and the wakeup-to-fetch relationship still leak information to some observers. The adapter must not silently switch a privacy-sensitive context to a direct fetch.
Opaque wakeups are a privacy-oriented candidate, not a proven timely-delivery solution. Apple documents that background notification delivery is not guaranteed; FCM documents delayed normal delivery in Doze and possible deprioritization of high-priority messages that do not produce visible notifications. The implementation must measure this tension on real devices before promising urgent interruption.
#Variation — Pull or an active permitted connection
This removes a push-provider dependency for that path and can fit desktop or local-network use. Mobile suspension, battery cost, and retrieval timing remain constraints. Both variations use the same policy engine; changing the wakeup mechanism must not change who may interrupt.
#A local explanation is not a presence oracle
The review tray records event references, the applied rule, the local mode, and the decision time. Sender-facing feedback, when enabled, reports only an allowed fact the client actually knows. “This client deferred interruption” does not prove whether another device notified, whether the operating system displayed an alert, or whether the person saw it. These facts must not be collapsed into “available” or “read”.
Prototype thresholds to test
| Situation | Initial experiment |
|---|---|
| One-to-one message | Notify unless recipient policy holds it. |
| Busy group | After 5 messages in 10 minutes, batch; test mention exceptions. |
| High priority in a busy thread | Surface once, then batch unless explicitly allowed. |
| Emergency | Apply recipient-selected exceptions and OS constraints. |
| Followed channel | Pull only; optional selected-channel digest. |
| Deferred review | User-chosen review moments with finite groups and visible reasons. |
These are test inputs, not protocol constants. Validate missed-obligation anxiety, interruption reduction, accessibility, time-zone changes, reboot behavior, and the effort required to adjust a noisy thread. Rough urgency history remains local and is not an automatic person score.
#Open Threads
- Priority vocabulary and expectations (OT-07-001). Test labels and markers without rigid emergency allowances or guaranteed-delivery implications.
- Mode defaults and UX. Test global/context/thread precedence and device differences with understandable exceptions.
- Bulk-review validation (OT-07-003). Tune thresholds, digest timing, mention behavior, and tray copy.
- Emergency-contact optionality (OT-07-006). Define recipient enrollment and narrowly scoped delivery-without-interruption feedback.
- Platform gate. Compare opaque push, active connections, and pull under suspension, Doze, outages, and each context's metadata budget.