Privacy

31847 readers

125 users here now

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
Don't promote proprietary software
Try to keep things on topic
If you have a question, please try searching for previous discussions, maybe it has already been answered
Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
Be nice :)

Related communities

Chat rooms

[Matrix/Element]Dead
Discord

much thanks to @gary_host_laptop for the logo design :)

founded 5 years ago

MODERATORS

Can a Unified Push push server see/read notifications? (sh.itjust.works)

submitted 4 days ago* (last edited 4 days ago) by Kalcifer@sh.itjust.works to c/privacy@lemmy.ml

14 comments fedilink hide all child comments

By "push server" I mean something like Ntfy.sh.

Cross-posts

https://sh.itjust.works/post/27577324

you are viewing a single comment's thread
view the rest of the comments

[–] kevincox@lemmy.ml 2 points 3 days ago (1 children)

IMHO UnifiedPush is just a poor re-implementation of WebPush which is an open and distributed standard that supports (and in the browser requires, so support is universal) E2EE.

UnifiedPush would be better as a framework for WebPush providers and a client API. But use the same protocol and backends as WebPush (as how to get a WebPush endpoint is defined as a JS API in browsers, would would need to be adapted).

[–] toastal@lemmy.ml 1 points 3 days ago (1 children)

Sounds like you need a browser tho. UnifiedPush & MQTT work without a browser with WebPush support.

[–] kevincox@lemmy.ml 2 points 3 days ago

There are three parts to the whole push system.

A push protocol. You get a URL and post a message to it. That message is E2EE and gets delivered to the application.
A way to acquire that URL.
A way to respond to those notifications.

My point is that 1 is the core and already available across devices including over Google's push notification system and making custom push servers is very easy. It would make sense to keep that interface, but provide alternatives to 2 and 3. This way browsers can use the JS API for 2 and 3, but other apps can use a different API. The push server and the app server can remain identical across browsers, apps and anything else. This provides compatibility with the currently reigning system, the ability to provide tiny shims for people who don't want to self host and still maintains the option to fully self host as desired.