Hi everyone,
For the past weeks I've been working hard on a push notification service for Avelon that is finally ready for open beta! This feature involves a completely new cloud service that automatically notifies you whenever someone replies to your posts/comments, and it simultaneously supports multiple accounts you might have. Although the app itself doesn't change much with this new Testflight build, there's a lot of stuff happening in the background to make push notifications happen.
My goal with the open beta is to test the service with many more users to see how it scales under heavier load. I'm not sure how powerful of a server it'll need - and as many of you might know cloud compute isn't exactly cheap. The service isn't quite done yet, so while I keep working on it you should expect downtime and occasionally delayed notifications.
How to join
- Download the latest 1.0.8 testflight build
- Open Avelon and go to Settings/Notifications
- Enable notifications for the accounts you wanna use
When you're testing, I'm especially interested in verifying that you're not getting any duplicate notifications and that you're receiving notifications for all the accounts you've enabled. Also, please share any bugs you might find or thoughts about how to improve things!
Notifications should still work if you go back to the App Store version without deleting the app, but notifications won't open the post and the notification badge will probably not behave properly. This is just a result of the previous version not supporting notifications yet, and will ofc be resolved with the official release!
Technical stuff for those interested
The push notification service is written in Rust, which is a pretty awesome language. This is my first time using it for a complete solution, but I must say I'm already sold on the features the language offers. Ensuring performance and security was a breeze compared to many other languages I've used. For those unaware, Lemmy itself is also written in Rust.
I've prioritized making sure the service scales well with many users, whilst not being heavier than necessary on the Lemmy servers. All traffic from the Avelon service is properly tagged to make it easy for instance owners to verify that the traffic is legit, and not some kind of DOS attack. If the traffic turns out to be a bit heavy for any instance owners, please don't hesitate to contact me to discuss how I can tweak the service to be less demanding on your server.
With the addition of push notifications I'll also update the privacy badge on the App Store to include (opt-in) collection of device identifiers. This is just a practical necessity to know which device to send notifications to. Apple continuously shuffles these random IDs, and they are the only ones who know who each one belongs to. The Avelon service simply sends a notification with the ID to Apple, and they figure out which device to forward it to. And of course, if you disable push notifications in the app all your info is immediately deleted from the notification server.
Thanks for reading & helping me test!
No probs, also, didn’t get the notification of your message, also running 17.3 beta. I’m a Pro user who jumped over to the TF channel, there can be issues with that upgrade path and tokens, but not usually if the token is created on the TF branch and used there. Might be worth looking at your token table to see if you are getting the numbers you expect.
Yeah, I think there's a slight issue with TF tokens atm, but only happens in some situations it seems. Has worked for me for the last week or so, so probably just a minor thing. Looking into it!
Wee update, nots are working for me now. Btw, happy to push you diagnostics anytime you need. Do you have that in the app somewhere (maybe useful at least on the TF branch)? I often found the on device diagnostic files a key to knowing where missing PNs/Tokens went.
Turned out the TF environment and dev environment arent compatible, so just had to switch that for all the notifications to come through! Not diagnostics atm, might be a good idea to add that tho. Some kind of metrics would also be pretty insightful..
Ah, makes sense.
Metrics are great, it’s always useful to have some dataset to base decisions on when deciding how to spend your time, but Diagnostic files are lifeblood for finding bugs. Just like metrics you do need to go through and put in hooks to write to the diagnostic file, but you can push all you want to it, and it can really help if you’ve done what you do, and make the API responses user friendly when they fail. You might have 15 different failures that trigger your “Failed to load” state, so a user plagued by that, sending the file to you, is great for knowing what actually went wrong.
A bit like Unit Testing, you can survive without them but by investing in them you’ll be doing a later you a favour.