Notifications are not working

[dmatora]

No description provided.

[avarayr]

Thanks for raising this issue. Notifications are still work in progress

[dmatora]

Are they missing proper configuration or just not supposed to be working yet?

[avarayr]

Are they missing proper configuration or just not supposed to be working yet?

The bulk of the actual logic behind notifications is done, i just need to tie it all together. I'm working on it right now!

[avarayr]

@dmatora I've updated the repo with several changes. You should be able to pull the pre-build docker image following the instructions.

Notifications should be working now. Check out the new GIF demo in the README

[dmatora]

Hey, great job! I've never seen 1 click ClaudFlare forwarding setup before.
And now when I click test notification I can see one (in Chrome it even works on localhost, on iPhone it works via PWA)
But I don't get notifications when AI finishes generating message, so it's still not really working :)

[dmatora]

Saw process.env.VERCEL_URL in the code and decided to try deploying it to vercel.
Deployment went find, but app is not working.
UI loads but fails calling backend.
/api/trpc/chat.all throws http 500

___          ______                
    / _ \         | ___ \               
   / /_\ \ ___ ___| |_/ / __ _ ___  ___ 
   |  _  |/ __/ _ \ ___ \/ _` / __|/ _ \
   | | | | (_|  __/ |_/ / (_| \__ \  __/
   \_| |_/\___\___\____/ \__,_|___/\___|
realtime database
Unhandled Rejection: [Error: EROFS: read-only file system, mkdir './suaveui.acebase'] {
  errno: -30,
  code: 'EROFS',
  syscall: 'mkdir',
  path: './suaveui.acebase'
}
Unhandled rejection: [Error: EROFS: read-only file system, mkdir './suaveui.acebase'] {
errno: -30,
code: 'EROFS',
syscall: 'mkdir',
path: './suaveui.acebase'
}
Node.js process exited with exit status: 128. The logs above can help with debugging the issue.

[dmatora]

I saw body: 'the VAPID credentials in the authorization header do not correspond to the credentials used to create the subscriptions.\n', in the logs and figured what the issue was. Database had old subscription. I removed data.db from suaveui.acebase, restarted app and configured it from scratch and notifications are finally working!

[dmatora]

Well, maybe not working so well.
Current solution wouldn't work without internet connection, right?

[avarayr]

I saw body: 'the VAPID credentials in the authorization header do not correspond to the credentials used to create the subscriptions.\n', in the logs and figured what the issue was. Database had old subscription. I removed data.db from suaveui.acebase, restarted app and configured it from scratch and notifications are finally working!

Ah, great catch. Btw, you won't see notifications from chats while the chat screen is visible on the screen. It's intended mostly for slow generations, for example using a 200B model with very low token per second, and you get a notification when the message is finished.

(I'm still figuring this out because seems like iphone specifically doesn't properly signal the user having the view closed or being on another app)

Yes, notifications will not work offline. This is a core limitation of how Push notifications work.

Basically, your device opens a passive keep-alive socket to Google/Apple push server, and it listens for new data. To my knowledge there's no way to self host the push server.

We were blessed to have VAPID standard to break away from Google/apple walled garden around push notifications, since originally push notifications from apps that were not approved by Google/Apple was impossible.

[dmatora]

I've just tested this and it worked offline

import React, { useState, useEffect } from 'react';

const NotificationTest: React.FC = () => {
  const [permission, setPermission] = useState<NotificationPermission>('default');
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    setPermission(Notification.permission);
  }, []);

  const requestPermission = async () => {
    try {
      const result = await Notification.requestPermission();
      setPermission(result);
      setError(null);
    } catch (err) {
      setError(`Error requesting permission: ${err}`);
    }
  };

  const sendNotification = () => {
    if (permission === 'granted') {
      try {
        new Notification('Test Notification', {
          body: 'This is a test notification sent from React.',
          icon: '/favicon.ico' // Предполагается, что у вас есть favicon.ico в public директории
        });
        setError(null);
      } catch (err) {
        setError(`Error sending notification: ${err}`);
      }
    } else {
      setError('Permission not granted. Please request permission first.');
    }
  };

  return (
    <div className="container mx-auto p-4 max-w-md">
      <h1 className="text-2xl font-bold mb-4">React Notification Test</h1>
      <div className="mb-4">
        <button
          onClick={requestPermission}
          className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded mr-2"
        >
          Request Permission
        </button>
        <button
          onClick={sendNotification}
          className="bg-green-500 hover:bg-green-700 text-white font-bold py-2 px-4 rounded"
        >
          Send Notification
        </button>
      </div>
      <p className="mb-2">Current permission: <strong>{permission}</strong></p>
      {error && <p className="text-red-500">{error}</p>}
      <div className="mt-4 text-sm">
        <p>Browser: {navigator.userAgent}</p>
        <p>Notification API supported: {"Notification" in window ? "Yes" : "No"}</p>
        <p>Current protocol: {window.location.protocol}</p>
      </div>
    </div>
  );
};

export default NotificationTest;

[avarayr]

@dmatora that's a fully offline client-side notification API.
Yes in theory that will work, but here's the challenge. We want the user to be able to close/minimize the app (on their iPhone) and do other things while the slow generation is happening.

Using your approach, we need to make sure that while the app is in background, the JavaScript is still being executed to periodically check whether we received the full response from the backend.

I'm afraid Android/iPhone decide to suspend apps while they're in the background, so we won't be able to check whether the generation has finished, and therefore we won't be able to send the client-side notification.

[dmatora]

it would at least work on desktop, where I mainly chat with ai anyway

[avarayr]

it would at least work on desktop, where I mainly chat with ai anyway

Good point. I'll have to figure out how to give the user a choice between fully offline client side notifications, and push notifications using Google/Apple servers.

[dmatora]

one way would be to check if client is a desktop, but simple desktop toggle would also work (with a info tip)

[dmatora]

I would still check how background js throttling affects it on desktop

[dmatora]

Would be nice to be able to serve over https with self signed certificate, something like

const https = require('https');
const selfsigned = require('selfsigned');

const attrs = [{ name: 'commonName', value: 'localhost' }];
const pems = selfsigned.generate(attrs, { days: 365 });

const server = https.createServer({
  key: pems.private,
  cert: pems.cert
}, (req, res) => {
  res.writeHead(200);
  res.end('Hello, HTTPS world!');
});

server.listen(443, () => {
  console.log('HTTPS server running on port 443');
});

this make running offline server so much easier

[avarayr]

Would be nice to be able to serve over https with self signed certificate, something like

const https = require('https');
const selfsigned = require('selfsigned');

const attrs = [{ name: 'commonName', value: 'localhost' }];
const pems = selfsigned.generate(attrs, { days: 365 });

const server = https.createServer({
  key: pems.private,
  cert: pems.cert
}, (req, res) => {
  res.writeHead(200);
  res.end('Hello, HTTPS world!');
});

server.listen(443, () => {
  console.log('HTTPS server running on port 443');
});

this make running offline server so much easier

Ah nice.. I'm currently use hono to serve the backend (src/server/hono.ts)

I'll see how I can integrate self signed to make a seamless https connection.

[avarayr]

Just from preliminary research, it looks like PWA/Service worker might not work using self signed certificates.

[dmatora]

Well it does have issues. In safari PWA won't load. In Chrome when I launch PWA I have to approve certificate each time, which redirects me from app to Chrome, and once approved I have to click open in app to move it back. It's messy but I can't think of other solution for working offline (except developing proper desktop app - I've asked BoltAI to add notifications and author said he will think about it)

But unlike push notifications, local notifications work even from page.
So PWA is not really mandatory, just a way to separate app from 100 tabs and 5-10 chrome windows

[dmatora]

Well, at some point I got tired of reapproving self issued certificate and issued let's encrypt certificate for personal domain pointing to local network Ip, got it validated via dns txt entry and got nginx reverse proxy running, pointing to local network running suaveui instance

[avarayr]

Well, at some point I got tired of reapproving self issued certificate and issued let's encrypt certificate for personal domain pointing to local network Ip, got it validated via dns txt entry and got nginx reverse proxy running, pointing to local network running suaveui instance

Nice! I suggest to look into setting up Tailscale and pointing your domain to the local Tailscale address to have private access to your instance when not connected to your home network. That's currently my setup.