• 5 Posts
  • 369 Comments
Joined 4 years ago
cake
Cake day: January 21st, 2021

help-circle

  • There are three parts to the whole push system.

    1. A push protocol. You get a URL and post a message to it. That message is E2EE and gets delivered to the application.
    2. A way to acquire that URL.
    3. 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.




  • 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).









  • The concern is that it would be nice if the UNIX users and LDAP is automatically in sync and managed from a version controlled source. I guess the answer is just build up a static LDAP database from my existing configs. It would be nice to have one authoritative system on the server but I guess as long as they are both built from one source of truth it shouldn’t be an issue.


  • Yes, LDAP is a general tool. But many applications that I am interested in using it for user information. That is what I want to use it for. I’m not really interested in storing other data.

    I think you are sort of missing the goal of the question. I have a bunch of self-hosted services like Jellyfin, qBittorrent, PhotoPrism, Metabase … I want to avoid having to configure users in each one individually. I am considering LDAP because it is supported by many of these services. I’m not concerned about synchronizing UNIX users, I already have that solved. (If I need to move those to LDAP as well that can be considered, but isn’t a goal).


  • I do use a reverse proxy but for various reasons you can’t just block off some apps. For example if you want to play Jellyfin on a Chromecast or similar, or PhotoPrism if you want to use sharing links. Unfortunately these systems are designed around the built-in auth and you can’t just slap a proxy in front.

    I do use nginx with basic with in front of services where I can. I trust nginx much more than 10 different services with varying quality levels. But unfortunately not all services play well.


  • How are you configuring this? I checked for Jellyfin and their are third-party plugins which don’t look too mature, but none of them seem to work with apps. qBittorrent doesn’t support much (actually I may be able to put reverse-proxy auth in front… I’ll look into that) and Metabase locks SSO behind a premium subscription.

    IDK why but it does seem that LDAP is much more widely supported. Or am I missing some method to make it work





  • kevincox@lemmy.mltoPrivacy@lemmy.mlIn search for a good VPN
    link
    fedilink
    arrow-up
    8
    arrow-down
    1
    ·
    2 months ago

    I mean it is always better to have more open source. But the point of the multi-hop system is that you don’t need to trust the server. Even if the server was open source:

    1. You wouldn’t know that we are running an unmodified version.
    2. If you need to trust the server then someone could compel us to tap it or monitor it.

    The open source client is enough to verify this and the security of the whole scheme.