UnifiedPush: A decentralized, open-source push notification protocol

Post by afandian » Thu, Dec 22, 2022, 7:27 PM UTC

kevincox wrote: post #44

afandian wrote: post #19

The headline got my attention. I'm looking for a standard for subscribeable notifications / callbacks to update users of data changes in an API. Bonus point for federated. But server to server, not server to client. Double bonus points for connecting to consumer services like Zapier or IFTTT. I'm planning to use WebSub and/or RSS, but on the look out for others. Any pointers?

WebSub + RSS/Atom is a good option for relatively slowly changing data. (Maybe at most a couple of times an hour). It is nice because it is opt-in and an enhancement on the regular polling API. Using WebSub or UnifiedPush would technically very similar but you need a way for the client to pass you the subscription information. WebSub has a standard discovery process to manage this.

Post by EGreg » Thu, Dec 22, 2022, 7:49 PM UTC

michaelmior wrote: post #65

EGreg wrote: post #35

Earlier quoted context omitted.

If you deliver notifications, you are always leaking metadata around timing. A police unit parked outside a guy’s house and confirmed it was him in the real time chatroom, by cutting his internet and seeing him drop off. If you want real anonymity on the Internet, never use push notifications. Always “pick up your mail” periodically from random endpoints on the Web.

In theory, if you were worried about this, I think you could get around that problem by just constantly send fixed sized encrypted messages large enough to hold any potential notifications. When a notification needs to get sent, you add it to the next outgoing encrypted message. Of course, now the delay for notifications is now coupled to the rate of these messages being sent.

Post by michaelmior » Thu, Dec 22, 2022, 8:15 PM UTC

EGreg wrote: post #73

michaelmior wrote: post #65

Earlier quoted context omitted.

In theory, if you were worried about this, I think you could get around that problem by just constantly send fixed sized encrypted messages large enough to hold any potential notifications. When a notification needs to get sent, you add it to the next outgoing encrypted message. Of course, now the delay for notifications is now coupled to the rate of these messages being sent.

The messages can still be traced to the client picking them up. Cut their networking and the client doesn’t receive the messages anymore… this shows up as a bounced message. You can accumulate encrypted messages at random urls instead

Post by dismalpedigree » Thu, Dec 22, 2022, 8:23 PM UTC

EGreg wrote: post #35

ajvs wrote: post #4

Earlier quoted context omitted.

Thanks for your great work creating this protocol. Hope more app developers add support for it, especially for privacy focused apps like Signal which by relying on Google servers are leaking metadata.

If you deliver notifications, you are always leaking metadata around timing. A police unit parked outside a guy’s house and confirmed it was him in the real time chatroom, by cutting his internet and seeing him drop off. If you want real anonymity on the Internet, never use push notifications. Always “pick up your mail” periodically from random endpoints on the Web.

Post by karmanyaahm » Thu, Dec 22, 2022, 8:26 PM UTC

satvikpendem wrote: post #76

I'm using Google Firebase Cloud Messaging [0] which allows pushing notifications to devices even if they're asleep, unlike local notification services where the device must be awake and the app must be active. Will this service allow the same thing FCM does, including waking up the device? I'm looking at both iOS and Android devices, I see there's Flutter available but not iOS necessarily in the docs [1]. Related que…