@admins is it possible to have a label for PWA, please.
PWA is growing in importance after Apple recently opened Push notification for this technology.
3 Likes
( Seems like the best answer is the one at the bottom with VAPID keys and web-push )
Did not see a solution mentioned to the above, so resurrecting old thread to put a Push Notification server out there, and ask if there are any better ones being used so far?
Self-host push notifications which I have not yet tried:
But that seems to just abstract/wrap these:
Is this more than âvendorâ lock-in and an example of âOSâ lock-in? Would one need a different mobile OS to break out of Google/Apple/Amazon involvement?
Perhaps the other I removed in my original post ( ntfy ) is still appropriate in some way?
- ntfy - Android | UnifiedPush ( Installation - ntfy )
- GitHub - binwiederhier/ntfy: Send push notifications to your phone or desktop using PUT/POST
Seems like UnifiedPush perhaps? https://unifiedpush.org/
Or Notify Push from Nextcloud? GitHub - nextcloud/notify_push: Update notifications for nextcloud clients
Anyone have experience with Meteor PWAs and any of these or others?
Is it possible to just use WebSockets in some way and bypass third-parties that way, but keep a real-time connection while PWA is in background?
Seems like this could be a background-sync situation, mixed with notification permissions?
Or are VAPID keys being used such as in this example, directly with express or similar?
Going to update the reference implementation with the outcome of @jkuester walkthrough mixed with the VAPID approach, free of third-parties:
Will follow-up with Meteor adaptation of the linked approach unless someone has a better way.
Update: Got this working without third-parties and will post once polished up and used a bit.
Update: Weird detail but even with VAPID keys it seems most browsers still use their own third-party service?
Hi there,
I have some experience with Push and was wondering what are you trying to achieve. I understand this is about Push notifications :)) but what kind of Push notifications or what is the problem that needs to be solved?
activitree:push works 3 ways:
- on your existing Meteor as a simple package install,
- on your multi-project environment with a shared MongoDB and you select which servers you want as Push senders. (This is how I use it as I need multiple Notification generator platforms and few Push senders)
- It also works as a completely separate stand-alone server or cluster.
Only the first way is published in Atmosphere.
Here you can see the Message object supported by Firebase Cloud Messaging (FCM). I do not know how you can do this without a framework such as FCM. meteor-push/lib/server/notification.js at master ¡ activitree/meteor-push ¡ GitHub
Great question @paulishca
Judging by the code referenced, I think you see the problem I have, at an infrastructure privacy level. I notice you gestured to the underlying FQDNs that are generated as endpoints for each class of browser.
I am building Notifications into a PWA template based on Meteor and the goal is to replace text messages ( SMS ) as the most reliable ânotificationâ to summon a participant with a credential and login/session back to the application. Tied in importance to the goal is the priority of having no vendor-lock-in, and no third-party intermediaries. This should run as independently as possible, with the exception of the underlying cloud hosting provider, such as DigitalOcean only accommodating a Virtual Machine instance.
It must survive our design mandates, especially: No "necessary evils"
This is not intended to scale past a few dozen participants at first, and by the time it gets into even the hundreds, it will be refactored overall. That said, I do already have a multi-project infrastructure prepared.
It must be equally reliable on Desktop as Mobile, as a PWA. And all operating systems and all browsers, but at least Linux and Brave/Chrome, Windows and Brave/Chrome, Android and Brave/Chrome, and iOS and Safari.
( Looking at how ugly the Push Notifications are for Chrome-based applications, I might consider moving to Firefox just for that reason unless that can be overcome since they are that bad in Chrome 
)
This will work in coordination with the client/server/agent design pattern mentioned elsewhere which has been working great in initial real-world tests. So with that I have means to work through the scenarios you mentioned.
Right now the notifications seem to work, using web-push and VAPID keys, but on Firefox I notice the endpoints are a Mozilla FQDN and on Brave / Chrome they are a Google FDQN.
Right now browsers do not feel like âmy software installed on my computerâ but seem more like a public restroom interface. It would be great to make the browser at least more like my own toilet in my own bathroom at home. Maybe one day browsers can feel like my chair in my library. Or my spot on my sofa. Or my seat in my cockpit of my craft. Short of forking a browser it seems like it is going to be very hard to remove the third-parties at deeper and deeper levels. I just now noticed that includes push notifications. While I understand there need to be standards, and that at scale it is a serious situation to handle messaging queues, it does seem weird to be fundamentally unable to mind my own business at a design layer and not include the browser producer in the communications of participants using a browser.
I am looking forward to getting to the point of focused messaging by push notification to identify a specific location where participation is taking place, whether geographically or a particular login/session, versus pinging all sessions connected via PWA, and then scaling beyond dozens or hundreds if necessary, but right now it seems like the design mandates are failing more than the goal or specific priority.
I think you might be referring to the 3 notification objects. If yes, those are 3 vendors and not different browsers. The package is written for Cordova too so messages for IOS are interpreted differently than those for Android. The web messages are unified into a single API but various features of the message (when received) might be available or missing on certain browsers (e.g. add a RSVP inside the notification and respond from it instead of opening the app).
What I noticed in this community as well as in the very few video demos in Youtube, people use providers such as OneSignal. I asked OneSignal in the past and they could not ensure confidentiality in a signed contract.
With OneSignal - you send your content via a TLS-ed API but you know nothing about the further encryption. You also have no much control over your users.
With local packages such as activitree:push you send your messages over TLS to the âtowerâ and from there it hits the device. It is all encrypted in transit and it can be encrypted at rest within your Meteor platform and this is similar to what you would get from an email system.
Push vs SMS. SMS is still a good user identity carrier. You can have the same number on 2-3 devices but I guess most people would have those devices with them (Iphone + 4G Apple Watch). With Push, a user might have 10 different devices if he/she is using the app (PWA) on all of them. It might be a little hard to know to which device precisely to send an OTP.
If you want to experiment some more with FCM I am all in.
Some details on privacy here: āĻĢāĻžāĻ¯āĻŧāĻžāĻ°āĻŦā§āĻ¸ā§ āĻā§āĻĒāĻ¨ā§āĻ¯āĻŧāĻ¤āĻž āĻāĻŦāĻ āĻ¨āĻŋāĻ°āĻžāĻĒāĻ¤ā§āĻ¤āĻž | Firebase.
I will never be designing around Google and have all but removed them everywhere else.
That is what I am concerned about at the legal layer ( we do private versus public law, so that is a non-starter; I know that is only real in the United States, and the Internet so far mostly challenges individual sovereignty )
We removed SMS across the board due to TCR being insane, so I would not be doing OTP by SMS, and we know if a login is real. We provide the phone, the computer, sometimes the vehicle and/or the domicile, the offline systems, the online systems, remove wireless except for via redundant cellular masts at a safe distance and field work, do not currently see any healthy form of wearables, remove attention theft, and so on; so it seems like our design scenarios are very different. Privacy is an âor deathâ priority.
Your technical descriptions are excellent and I appreciate saving a few years by this thread.
The more I look at your intel, it seems that the right solution for what I am trying to do would be SharedWorkers ( my understanding is that they are basically ServiceWorkers but shared between instances of the same PWA on the same device in the same browser ) and WebSockets then use Local Notifications versus Offsite Notifications and just bypass the entire situation. It seems that is either supported right now, or will be supported soon across all the design targets.
The more I think about it I would way rather a WebSocket connection anyway