Conversation

Notices

1. Embed this notice
   Rich Felker (dalias@hachyderm.io)'s status on Friday, 21-Feb-2025 23:08:36 JST Rich Felker

   @cas @jawsh I'd rather the user declare it than the app. Apps don't know the user's priorities or usage models. For example a lot of apps may assume I want them running to receive notifications, while I want absolutely no notifications except from Signal or Cwtch or something and thus don't care if they get to run and want to save energy.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Friday, 21-Feb-2025 23:48:15 JST Rich Felker

     in reply to

     • PureTryOut

     @bart @cas @jawsh They really shouldn't. That's compromising privacy outsourcing data handling to third parties who can't be trusted. There's no fundamental reason for it to be more efficient than a sleeping process waiting on input from a socket.

   • Embed this notice
     PureTryOut (bart@mastodon.fam-ribbers.com)'s status on Friday, 21-Feb-2025 23:48:17 JST PureTryOut

     in reply to

     @dalias @cas @jawsh Then again push notifications (the ones you receive when the app is not running) should be handled through a dedicated daemon, not the app itself. #UnifiedPush for example.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Sunday, 23-Feb-2025 20:45:25 JST Rich Felker

     in reply to

     • PureTryOut

     @bart @cas @jawsh Who self hosts? The user? That's a non starter for vast majority.

   • Embed this notice
     PureTryOut (bart@mastodon.fam-ribbers.com)'s status on Sunday, 23-Feb-2025 20:45:27 JST PureTryOut

     in reply to

     @dalias @cas @jawsh What? Not at all. With UnifiedPush you can completely self host the thing, including the push server itself.
     I'm not saying we should follow the Google and Apple way, not at all.