Open EdwardHinkle opened 6 years ago
aaronpk
commented
6 years ago Well that's not what I was expecting this issue to be about. Do you mean that you're going to run a server on behalf of the iOS client, so that you can send push notifications to it? I hadn't considered having Aperture send out WebSub notifications for content added to its channels, but that makes sense now that you mention it!
EdwardHinkle
commented
6 years ago Yeah. I was thinking through push notifications, and I realized if I have a Micropub endpoint that turns Micropub requests into push notifications, that seems odd because they would all be ephemeral unless the person had the Micropub request ALSO be sent to their Microsub Server.
So while I still might implement “ephemeral” notifications by receiving a Micropub request, I realized most the time I will want 99% of my notifications logged. Which means they need to be a Microsub channel. Which means rather than having someone send content twice (or configure Microsub to “forward” posts), instead a client should be able to just get update notifications.
This means Indigenous can have a server that subscribes via WebSub and sends PUSH notifications when it gets them. And it could be configured on a per channel basis. And it can even be changed. For a day if I want to receive push notifications from a secondary channel, I can activate that for the day, and just disable notifications afterward.
This would also enable Together to eventually do some real-time post updates, by having its backend subscribe to the WebSub
Either build in WebSub (by using Switchboard as a library) or add support for connecting to an external WebSub hub.
By enabling WebSub support for each timeline feed, a client can get real-time notifications of new posts within a timeline. This helps enable things like Push Notifications for ANY channel.