Falco
(Falco)
12 Noviembre, 2022 17:44
1
A partir de hoy, la notificación de Discourse Chat permite a los usuarios responder directamente en la propia notificación
La interfaz de usuario para esto es diferente en cada sistema operativo, ya que se integra en el sistema de notificaciones nativo.
Smartwatch Android Wear OS
Android
Windows
Si todo va bien, los posibles próximos pasos para esta función serían:
Añadir soporte para reacciones en línea
Enviar respuestas en línea como “en respuesta a” al mensaje al que se está respondiendo
Añadir soporte para respuestas en línea para temas / publicaciones
Manejar errores al enviar respuestas en línea, ya sean errores de red o de lógica de negocio.
Internacionalización del botón de respuesta y del marcador de posición
26 Me gusta
Esta es una gran adición. Estaba tan confundido cuando pensé: “vaya, una imagen de ejemplo dinámica que muestra mi nombre de usuario”, y luego me di cuenta de que era solo una captura de pantalla de mi nombre de usuario.
Me encanta la rapidez con la que está creciendo esta función de chat; no puedo esperar al momento adecuado para añadirla a nuestra comunidad. Por mucho que me encante Discord, desde nuestro caso de uso empresarial, realmente no quiero tener otra plataforma que gestionar y en la que fragmentar a mis usuarios.
Una buena función sería poder seleccionar uno o varios mensajes de chat y convertirlos en un tema.
9 Me gusta
¿Cuándo ocurrirá la compatibilidad con iOS? Todavía tengo que usar una aplicación de terceros para recibir notificaciones push instantáneas con contenido también.
2 Me gusta
Falco
(Falco)
12 Noviembre, 2022 23:02
7
Ni idea, eso depende de Apple. Implementamos el estándar web abierto y funciona en todos los sistemas operativos que implementan la especificación, como Windows, Android, Chrome OS, etc. Se puede esperar que cuando/si Apple implementa WebPush en 2023 lo haga correctamente, pero solo podemos esperar.
15 Me gusta
Falco
(Falco)
11 Mayo, 2026 20:12
8
Esto estuvo roto durante un tiempo, y he vuelto a agregar soporte de manera más robusta
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.
Ahora también capturamos las respuestas que consisten en un solo emoji como reacción, y soportamos hilos de chat! .
5 Me gusta
¡Guau! ¡Esto es realmente genial! ¿Tienen planes de hacer lo mismo para los temas?
1 me gusta