Falco
12. November 2022 um 17:44
1
Ab heute ermöglicht die Discourse Chat-Benachrichtigung Benutzern, direkt in der Benachrichtigung selbst zu antworten
Die Benutzeroberfläche hierfür ist je nach Betriebssystem unterschiedlich, da sie in das native Benachrichtigungssystem integriert ist.
Wenn alles gut läuft, wären mögliche nächste Schritte für diese Funktion:
Unterstützung für Inline-Reaktionen hinzufügen
Inline-Antworten als „Antwort auf“ an die Nachricht senden, auf die geantwortet wird
Unterstützung für Inline-Antworten für Themen/Beiträge hinzufügen
Fehlerbehandlung beim Senden von Inline-Antworten, seien es Netzwerk- oder Geschäftslogikfehler.
i18n der Antwortschaltfläche und des Platzhalters
26 „Gefällt mir“
Dies ist eine großartige Ergänzung. Ich war so verwirrt, als ich dachte: „Wow, ein dynamisches Beispielbild, das meinen Benutzernamen anzeigt“, und dann feststellte, dass es nur ein Screenshot meines Benutzernamens war.
Ich liebe es, wie schnell sich diese Chat-Funktion entwickelt – ich kann es kaum erwarten, bis der richtige Zeitpunkt gekommen ist, um sie unserer Community hinzuzufügen. So sehr ich Discord auch liebe, aus unserem geschäftlichen Anwendungsfall heraus möchte ich wirklich keine weitere Plattform verwalten und meine Benutzer darauf aufteilen.
Eine schöne Funktion wäre es, eine oder mehrere Chat-Nachrichten auszuwählen und sie in ein Thema auszulagern.
9 „Gefällt mir“
darkpixlz
12. November 2022 um 22:45
6
Wann wird die iOS-Unterstützung erfolgen? Ich muss immer noch eine Drittanbieter-App verwenden, um sofortige Push-Benachrichtigungen mit Inhalt zu erhalten.
2 „Gefällt mir“
Falco
12. November 2022 um 23:02
7
Keine Ahnung, das liegt an Apple. Wir implementieren nach dem offenen Webstandard und es funktioniert auf jedem Betriebssystem, das die Spezifikation implementiert, wie Windows, Android, Chrome OS usw. Man kann hoffen, dass Apple WebPush im Jahr 2023 richtig implementiert, aber wir können nur hoffen.
15 „Gefällt mir“
Falco
11. Mai 2026 um 20:12
8
Das war eine Weile kaputt, und ich habe die Unterstützung dafür auf eine robustere Weise wieder hinzugefügt
main ← chat-push-quick-reply
merged 03:36PM - 29 Apr 26 UTC
**Previously**, the "Reply" action on chat web push notifications was silently b… roken — the service worker's chat URL regex stopped matching when chat routes moved to `/chat/c/:slug/:id`, and the chat-specific code lived in core with no thread support, URL encoding, or error handling.
**In this update**, generalize the core service worker into a plugin-extensible action registry, move chat reply handling into the chat plugin with proper thread/encoding/fallback support, and convert single-emoji replies into reactions on the source message (falling back to a regular message post on any failure).
## Architecture
Core (`app/views/static/service-worker.js.erb`) now exposes:
```js
self.registerNotificationActionHandler(action, handler);
```
Push payloads can carry `actions` (Web Notifications API format) and `action_data` (an arbitrary object surfaced to the handler at `event.notification.data.actionData`). The click handler dispatches by `event.action` name and falls back to the existing focus-or-open behavior when no handler matches or a handler throws.
`PushNotificationPusher` forwards `actions` / `action_data` when present.
The chat plugin owns its own service worker (`plugins/chat/assets/javascripts/service-worker.js`), registered via `register_service_worker`. It registers a `chat-reply` handler that:
1. Fetches a CSRF token.
2. If the reply is a single emoji grapheme (detected via `Intl.Segmenter`, with a `\p{Extended_Pictographic}` regex fallback), `PUT`s to `/chat/:channel_id/react/:message_id`.
3. Otherwise — or if the reaction request fails — `POST`s to `/chat/:channel_id` with proper `URLSearchParams` encoding and the source `thread_id` if present.
4. If everything fails, opens the channel so the user can retype.
`Chat::Notifier.push_notification_reply_action(chat_message, user)` builds the payload in the user's locale with `channel_id`, `message_id`, and optional `thread_id`.
`Chat::MessageReactor#react!` resolves raw Unicode via `Emoji.unicode_replacements[emoji] || emoji` before validation, so smartwatch quick-reply chips (which send raw Unicode like `👍🏽` or ZWJ sequences) just work. Existing shortcode callers are unaffected.
## Why this matters
Smartwatch notification UIs expose a single "reply" affordance with canned chips that include short text and emoji. The user can't choose between "send as message" and "react"; they tap a chip and a string comes through. Treating a single-grapheme pictographic reply as a reaction matches user intent on the watch UX without any new product surface.
## Test plan
- [ ] On a chat-enabled site, subscribe to web push notifications.
- [ ] Have another user post a message that mentions you, or a watched channel message.
- [ ] On the resulting OS notification, confirm a "Reply" action button appears.
- [ ] Type a text reply and submit — verify it posts as a message in the right channel/thread.
- [ ] Submit a single emoji (e.g. 👍 or 👍🏽 with skin tone) — verify it lands as a reaction on the source message instead of posting a message.
- [ ] Submit a ZWJ sequence (e.g. 👨👩👧) — verify it lands as a reaction (or falls back to message post if not in the emoji DB).
- [ ] Sign out / let session expire and submit a reply — verify the channel opens as a fallback rather than silently failing.
- [ ] Watch via Wear OS / watchOS quick-reply chips and confirm the same behavior end-to-end.
Jetzt erfassen wir auch Antworten, die nur aus einem einzelnen Emoji als Reaktion bestehen, und unterstützen Chat-Threads! .
5 „Gefällt mir“
Wow! Das ist wirklich toll! Gibt es Pläne, das auch für Themen umzusetzen?
1 „Gefällt mir“
