Falco
12 Novembro , 2022 17:44
1
A partir de hoje, a notificação do Discourse Chat permite que os usuários respondam diretamente na própria notificação
A interface para isso é diferente em cada sistema operacional, pois se integra ao sistema de notificação nativo.
Se tudo correr bem, os próximos passos possíveis para este recurso seriam:
Adicionar suporte para reações inline
Enviar respostas inline como “em resposta a” a mensagem à qual estão respondendo
Adicionar suporte para respostas inline para tópicos / posts
Lidar com erros ao enviar respostas inline, sejam erros de rede ou de lógica de negócios.
Internacionalização do botão de resposta e do placeholder
27 Curtiram
Esta é uma ótima adição. Fiquei tão confuso quando pensei: “Uau, uma imagem de exemplo dinâmica mostrando meu nome de usuário”, e depois percebi que era apenas uma captura de tela do meu nome de usuário.
Adoro a rapidez com que este recurso de chat está crescendo - mal posso esperar até o momento certo para adicioná-lo à nossa comunidade. Por mais que eu ame o Discord, do nosso caso de uso de negócios, eu realmente não quero ter outra plataforma para gerenciar e para fragmentar meus usuários.
Um bom recurso seria selecionar uma ou mais mensagens de chat e transformá-las em um tópico.
9 Curtiram
Quando o suporte ao iOS acontecerá? Ainda preciso de um aplicativo de terceiros para receber notificações push instantâneas com conteúdo também.
2 Curtiram
Falco
12 Novembro , 2022 23:02
7
Sem ideia, isso depende da Apple. Implementamos o padrão da web aberta e ele funciona em todos os sistemas operacionais que implementam a especificação, como Windows, Android, Chrome OS, etc. Pode-se esperar que, quando/se a Apple implementar o WebPush em 2023, eles o façam corretamente, mas tudo o que podemos fazer é esperar.
15 Curtiram
Falco
11 Maio , 2026 20:12
8
Isso estava quebrado por um tempo, e eu readicionei o suporte de forma mais 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.
Agora também capturamos respostas que consistem em um único emoji como reação e damos suporte a threads de chat! .
5 Curtiram
Uau! Isso é muito legal! Há planos de fazer o mesmo para tópicos?
1 Curtiu
gilles
16 Maio , 2026 09:32
10
Pequena pergunta: isso funciona na Apple?
Falco
16 Maio , 2026 16:02
11
