Protocol primitives for notifications

[joshlacal]

Hello!

There recently was a discussion in the atprotocol.community forums about notifications in the Atmosphere, and it got me thinking about a few things related to the protocol and appviews.

As you're probably aware, push notifications for mobile devices can really only be delivered by an APNs/FCM server registered to the developer of the app. There's no way for say, a third party Bluesky client to subscribe to Bluesky's push notification server. I found this out when Samuel was working on Graysky years ago and saw he had to create his own backend for his client.

Third parties have to listen to the firehose, collect and store user blocks (public) and mutes (not public, but enumerable by the appview), thread mutes (which are not enumerable), and poll for new chat messages. For public data, it's fine, but when you add private and difficult to enumerate data, there's a clear gap between clients.

With group clip clops coming, it's a bit of a bummer my app probably won't be able to send push notifications for chats the way the Bluesky app will.

With private data in development, I really hope the team considers this issue with notifications across apps. Push is the lifeblood of modern social apps, and I really think we need a way for private notifications to be delivered across clients and even appviews.