• aeharding@lemmy.world
      link
      fedilink
      arrow-up
      31
      arrow-down
      2
      ·
      1 year ago

      btw, wefwef is called Voyager now.

      Just because it had to be more confusing 😅

      Sorry!

    • Redjard@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      9
      ·
      edit-2
      1 year ago

      wefwef is an app, a webapp. Usually reachable under wefwef.app
      You can install it as a progressive webapp through your browser.
      This now is rehosting the files of wefwef on the m.lemmy.world domain, basically a fork that promises to keep in sync with the official codebase and the official domain. The m.lemmy.world domain shouldn’t need any connection to lemmy.world, it is basically not much different to a filehoster that hosts an apps apk. That is why I don’t think m.lemmy.world even sees your credentials if you log in anywhere.

      As to why, I’m not sure what the use of this is. Maybe in case the official domain goes offline?

      • That’s because when you use wefwef through wefwef.app, your data goes through wefwef.app before going to the instance, the app AFAIK does not communicate directly with the instances yet. You basically have to decide whether you trust wefwef.app enough to proxy your data through them.

        Using m.lemmy.world would mean your data goes through lemmy.world directly, which you already chose to trust.

        • G0FuckThyself@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          Okay what If I am already using wefwef than my data is already passed through wefwef, so there is no benefit now? or still I should logout with wef wef and use m.lemmy.world?

          • Redjard@lemmy.dbzer0.com
            link
            fedilink
            arrow-up
            4
            ·
            1 year ago

            Most things passing through are public anyway, as lemmy is allmost entirely public. The only privat info is your password and wefwefs session. Those are visible in clear to the server, so could in theory be logged. If you change your password (and invalidate your sessions) after wefwef switches to direct you should be good.

          • XpeeN@sopuli.xyz
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Stopping the stream of data is always possible. You can use google daily until you suddenly don’t, the steam of data is (or probably just the proccessing of your queries in this case) stops.

        • Redjard@lemmy.dbzer0.com
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          Oh, you are almost right, I was wrong. Checking the network traffic it seems images (and some parts of posts?) are fetched directly, but other elements are fetched through wefwef.app, namely everything that needs the users session. maybe this is done to process some lemmy outputs serverside into for example the notification icon? This surprised me, I was confident the only requests to wefwef.app would be static elements and the code itself.

          • aeharding@lemmy.world
            link
            fedilink
            arrow-up
            19
            ·
            edit-2
            1 year ago

            This is to get around CORS. @ruud@lemmy.world just fixed CORS on lemmy.world 15 minutes ago (things move fast on Lemmy, lol) so I’ll push an update to direct connect for lemmy.world tonight!

            Edit: done ✅

            • Redjard@lemmy.dbzer0.com
              link
              fedilink
              arrow-up
              1
              ·
              1 year ago

              This is about cors headers on the api calls? That only don’t affect other apps because they are offline and ignore cors?

              • aeharding@lemmy.world
                link
                fedilink
                arrow-up
                5
                ·
                1 year ago

                Native apps don’t have CORS restrictions. They can make http requests anywhere.

                Only web apps in a browser have this limitation.

                • Redjard@lemmy.dbzer0.com
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  1 year ago

                  Makes sense, never thought about that. An annoying situation, I wonder how many security issues would crop up if browsers allowed ignoring cors for pwas…

                  Currently apicalls are proxied through the server but end up with the lient all the same, with the session being stored in local storage “credentials”?
                  Will you currate a manual whitelist for direct calls or have the app test if direct fails and fall back to proxied?

                  • Redjard@lemmy.dbzer0.com
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    1 year ago

                    Why not add a new tier to pwas. You need to only use cookies scoped to your own domain, you get a new container without any existing session cookies etc. for other websites, but cors is dropped.
                    That should prevent carelessly putting auth tokens into cookies and should replace cors in that sensitive sessions are containered away and all existing data for other websites that where slopily created somehow are isolated.

                    After all for the way wefwef works for example I see no benefit to cors

            • isoA
              link
              fedilink
              arrow-up
              1
              arrow-down
              1
              ·
              edit-2
              1 year ago

              Hey is it dynamic or you have to add a list of instances to direct connect?

              Update: sorry, just saw your answer below 🤷‍♂️

        • Nato Boram@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 year ago

          It would surprise me if that was the explanation since this can be easily fixed by Lemmy.world itself by not sending two Accept-Control-Allow-Origin headers, thus breaking web clients.

          Right now, I’m forced to route my own calls to my server on the app I’m making because Lemmy.world is misconfigured.

          I guess that for instance below 0.18.1, it makes sense, since Lemmy had a bug at that point that didn’t allow web clients to connect.