Open sourcing our server
ente.io
Ente’s servers join our clients - Ente is now fully open source
    • RedNight@lemmy.mlEnglish
      15·
      10 months ago

      I’m trying to learn about licensing. Why do you like AGPL-3.0 compared to others?

      • baduhai@sopuli.xyzEnglish
        31·
        10 months ago

        The AGPL applies copyleft to web services. If you’re learning about licensing, it might be worth googling copyleft. Fascinating concept, and, in my opinion, something to subscribe to.

      • ResoluteCatnap@lemmy.mlEnglish
        14·
        10 months ago

        If you haven’t already, check out https://choosealicense.com/licenses/ . This gives a broad overview of the common open source licenses. And if you’re just starting out, one of the first things you’ll want to learn is that the licenses fall into either a permissive or copyleft category. You’ll want to make sure you understand the difference between those broad categories.

        Shortly, permissive have less to no strings attached to use their code, and copyleft requires you to retain the same licensing terms meaning if you publish under GPLv3 then someone using/ modifying your code needs to also publish under GPLv3. Copyleft licenses ensure that open source code stays open source.

      • baatliwala@lemmy.worldEnglish
        12·
        10 months ago

        In very basic terms - GPL means that any modifications you make to a code base and distribute to public, you need to keep the license as GPL and open source all your modifications.

        Once cloud started becoming a thing, the cloud vendors went “Well ackchyually🤓, the code changes we’re making are hosted on OUR server so we’re not technically distributing them to the public. So fuck you we have no obligation to make them open source”.

        Which is why AGPL exists so even server side code needs to be public. Since the application in question here is a backend service, it’ll always be used server side and so any forks need to be open source.

    • cmhe@lemmy.worldEnglish
      1·
      10 months ago

      Only really nice when not CLA is required and every contributor retains their copyright. Ente doesn’t seem to require a CLA.

      Otherwise it allows the owner to just take the changes from their contributors and change the license at a later date.

      • Arthur Besse@lemmy.mlEnglish
        5·
        10 months ago

        edit: the two issues i raised in this comment had both already been addressed.

        this was the developer’s reply on matrix:

        1. We do have a CLA: https://cla-assistant.io/ente-io/ente
        2. We will update the iOS app to offer you an option to point to your self hosted instance (so that you can save yourself the trouble of building it): https://github.com/ente-io/ente/discussions/504
        3. The portion of the document that deals with authentication has been outdated, my bad. We’ve adopted SRP to fix the concerns that were pointed out: https://ente.io/blog/ente-adopts-secure-remote-passwords/
        here is my original comment

        AGPL-3.0

        Nice

        This would be nice, but, this repo includes an iOS app, and AGPL3 binaries cannot be distributed via Apple’s App Store!

        AGPL3 (without a special exception for Apple, like NextCloud’s iOS app has) is incompatible with iOS due to the four paragraphs of the license which mention “Installation Information” (known as the anti-tivoization clause).

        Only the copyright holder(s) are able to grant Apple permission to distribute binaries of AGPL3-licensed software to iOS users under non-AGPL3 terms.

        Every seemingly-(A)GPL3 app on Apple’s App Store has either copyright assignment so that a single entity has the sole right to distribute binaries in the App Store (eg, Signal messenger) or uses a modified license to carve out an Apple-specific exception to the anti-tivoization clause (eg, NextCloud). In my opinion, the first approach is faux free software, because anyone forking the software is not allowed to distribute it via the channel where the vast majority of users get their apps. (In either case, users aren’t allowed to run their own modified versions themselves without agreeing to additional terms from Apple, which is part of what the anti-tivoization clause is meant to prevent.)

        Only really nice when not CLA is required and every contributor retains their copyright. Ente doesn’t seem to require a CLA.

        I definitely agree here! But if it’s true that they’re accepting contributions without a CLA, and they haven’t added any iOS exception to their AGPL3 license, then they themselves would not be allowed to ship their own iOS app with 3rd party contributions to it! 😱 edit: it’s possible this is the case and Apple just hasn’t noticed yet, but that is not a sustainable situation if so.

        If anyone reading this uses this software, especially on iOS, I highly recommend that you send the developers a link to this comment and encourage them to (after getting the consent of all copyright holders) add something akin to NextCloud’s COPYING.iOS to their repository ASAP.

        cc @[email protected] @[email protected] @[email protected]

        (i’m not a lawyer, this is not legal advice, lol)

        edit: in case a dev actually sees this… skimming your architecture document it looks like when a user’s email is compromised (“after you successfully verify your email”), the attacker is given the encryptedMasterKey (encrypted with keyEncryptionKey, which is derived from a passphrase) which lets them perform an offline brute-force attack on the passphrase. Wouldn’t it make more sense to require the user to demonstrate knowledge of their passphrase to the server prior to giving them the encryptedMasterKey? For instance, when deriving keyEncryptionKey, you could also derive another value which is stored on the server and which the client must present prior to receiving their encryptedMasterKey. The server has the opportunity to do offline attacks on the passphrase either way, so it seems like there wouldn’t be a downside to this change. tldr: you shouldn’t let adversaries who have compromised a user’s email account have the ability to attack the passphrase offline.

        (i’m not a cryptographer, but this is cryptography advice)

        • i_am_not_a_robot@discuss.tchncs.deEnglish
          1·
          10 months ago

          That’s complicated to do correctly. Normally, for the server to verify the user has the correct password, it needs to know or receive the password, at which point it could decrypt all the user’s files. They’d need to implement something like SRP.

          • Arthur Besse@lemmy.mlEnglish
            3·
            10 months ago

            That’s complicated to do correctly. Normally, for the server to verify the user has the correct password, it needs to know or receive the password, at which point it could decrypt all the user’s files. They’d need to implement something like SRP.

            What I proposed is that the server does not know the password (of course), but that it knows a thing derived from it (lets call it the loginSecret) which the client can send to obtain the encryptedMasterKey. This can be derived in a similar fashion to the keyEncryptionKey (eg, they could be different outputs of an HKDF). The downside to the server knowing something derived from the passphrase is that it enables the server to do an offline brute force of it, but in any system like this where the server is storing something encrypted using [something derived from] the passphrase the server already has that ability.

            Is there any downside to what I suggested, vs the current design?

            And is there some reason I’m missing which would justify adding the complexity of SRP, vs what I proposed above?

            The only reason I can think of would be to protect against a scenario where an attacker has somehow obtained the user’s loginSecret from the server but has not obtained their encryptedMasterKey: in that case they could use it to request the encryptedMasterKey, and then could make offline guesses at the passphrase using that. But, they could also just use the loginSecret for their offline brute-force. And, using SRP, the server still must also store something the user has derived from the password (which is equivalent to the loginSecret in my simpler scheme) and obtaining that thing still gives the adversary an offline brute-force opportunity. So, I don’t think SRP provides any benefit here.

          • Arthur Besse@lemmy.mlEnglish
            1·
            10 months ago

            They’d need to implement something like SRP.

            Update: I contacted the developers to bring my comment to their attention and it turns out they have already implemented SRP to address this problem (but they haven’t updated their architecture document about it yet).

    • Railcar8095@lemm.eeEnglish
      38·
      10 months ago

      I love immich, but I’m going to settle for something that doesn’t require to modify the compose every couple of months due to breaking changes. Trying to apply changes for two breaking updates in one go killed it for me.

      I’ll check this one for the time being

      • hedgehog@ttrpg.networkEnglish
        6·
        10 months ago

        If you haven’t already ruled it out, I recommend checking out Photoprism. It was the first app I ever self-hosted using Docker and I haven’t needed to change my config because of breaking changes yet.

        • AbidanYre@lemmy.worldEnglish
          5·
          10 months ago

          Does photoprism support multiple users yet? That was what drove me to immich. But I also don’t love the frequency of breaking changes.

        • Railcar8095@lemm.eeEnglish
          1·
          10 months ago

          I did use it in the past! I should check it again. I didn’t like how the multi user was planned (basically independent instances), but was long enough things might have changed.

          • hedgehog@ttrpg.networkEnglish
            2·
            10 months ago

            If you need/want a robust multi-user experience, specifically with private personal library support, then Photoprism isn’t going to work, unfortunately.

            • Free:
              • You can create multiple Admin users in the free version, but they all can see and delete everything (unless you don’t give Photoprism delete access)
            • Paid (Essentials or Plus)
              • you can create “User” users who can upload photos - but they still have access to your full library
              • you can create “Viewer” users who can’t see private photos (but they also can’t upload photos).
              • you can share links to albums that are viewable by anyone with the link

            I’ve been using it single user and it’s been great, though I should add the caveat that I upload my photos to my server using Photosync and don’t give Photoprism write/delete access to my library, so no uploads come from it. I had been using Photosync for years before even hearing about Photoprism so it just fit very neatly into my existing process.

            Multi user features are effectively paywalled and not technically FOSS due to not allowing commercial use, but roles are documented at https://docs.photoprism.app/user-guide/users/roles/ and there’s more info at https://docs.photoprism.app/user-guide/users/libraries/

            If Photoprism Plus/Essentials features could work for you, but the ongoing subscription is an issue, then you should know that - unless this has changed - you can sub for one month on Patreon or Github, use the info they provide to upgrade to using the Essentials or Plus features, and then cancel the subscription. I still have an ongoing one but I didn’t connect it to my Patreon account or anything so I don’t think anything would change (except for me no longer getting support, if I needed it) if I canceled it.

        • anivia@lemmy.mlEnglish
          1·
          10 months ago

          Trying to upload high resolution photos (like the 200mp photos taken with my s23 ultra) completely crashes photoprism for me until I stop the docker container and manually delete the images. That makes it unusable for me

      • Lem453@lemmy.caEnglish
        5·
        10 months ago

        The 1.95 update was trivially easy to update with their instructions if you already have the skill to use docker compose.

        • Railcar8095@lemm.eeEnglish
          20·
          10 months ago

          Good, once I can trivially not follow instructions between updates I’ll check it again.

          This is not a criticisms got immich, once they are in the stable phase I’ll try, just I don’t have the time to be checking the notes every update just in case.

          My stack is very large, I rather use sw that requires little to no micromanaging.

      • herrfrutti@lemmy.worldEnglish
        4·
        10 months ago

        I understand this, but that way you always read the update notes and you control what version you install. This can be a good practice.

        That stuff breaks is not so nice though.

  • taaz@biglemmowski.winEnglish
    31·
    10 months ago

    We’ve consolidated all our code into a single repository – just clone ente-io/ente on GitHub, and you will have at your disposal a state of the art, end-to-end encrypted, full stack (mobile/web/desktop clients, the server, and a CLI to boot) alternative to Google Photos and Apple Photos.

    • Moonrise2473@feddit.itEnglish
      5·
      10 months ago

      This seems a disadvantage, a single repo that does everything seems inconvenient and unnecessarily complex for a casual hobbyist that wants to try the project

        • Moonrise2473@feddit.itEnglish
          5·
          10 months ago

          The flutter apps and the electron app are unrelated to the server+web.

          Same for the separate 2fa app

          If you want to contribute to something you need to fork everything.

          Because this contains everything that is served by ente in their commercial offer in the way that’s suited in a professional way (photos stored in S3-like storage on minio server), not just photos, also future projects you might not want to run on your server like ente lock and ente legacy

      • stoicmaverick@lemmy.worldEnglish
        2·
        10 months ago

        I don’t think so Tim! Just stick it all in one repo/compose file and smash the ‘go’ button. Are you paying by the directory or something?

  • HybridSarcasm@lemmy.worldMEnglish
    16·
    10 months ago

    If you really want to serve the self-hosting community, please improve your documentation. As someone unfamiliar with this product, I have no idea what to do with this once I clone the repo. I hunted and found a compose.yaml file, but it’s not clear if this is all I need.

  • cron@feddit.deEnglish
    11·
    10 months ago

    I’m unsure about the end-to-end encryption aspect. While this feature is great for a cloud service like ente.io, it doesn’t really help much in a selfhosted scenario - and might make backups more complicated. Any other opinions on this?

    • helenslunch@feddit.nlEnglish
      3·
      10 months ago

      Would probably be trivial for a local authority to hack your server and collect the necessary info that way.

      I mean that’s the main reason I self-host anyway.

      • cron@feddit.deEnglish
        25·
        10 months ago

        Remotely hacking into my server is probably harder than just walking into my home with a warrant and confiscate everything.

        • helenslunch@feddit.nlEnglish
          9·
          10 months ago

          1. Yes but then they need to get a warrant.

          2. All the more reason to have it encrypted since they can’t access it even with a warrant and confiscation.

    • anivia@lemmy.mlEnglish
      1·
      10 months ago

      Do you want your ISP to be able to spy on your private pictures when uploading them to your self-hosted server? End-to-end encryption is a no-brainer every time you transmit private data online

      • conciselyverbose@sh.itjust.worksEnglish
        3·
        10 months ago

        Their model is that the server doesn’t know what the pictures are.

        Which is fine. It’s cool that it exists as an option, especially with someone else hosting your pictures. But it’s not for me. I want my server to see my pictures so it can play with them.

        • Midnight Wolf@lemmy.worldEnglish
          2·
          10 months ago

          so it can play with them

          Papa jpeg: “this little jpeg went to market, this one stayed home, and this one went weeeeeee all the way along the download stream!”

          Other little jpegs: “hoorayyyyyyy”

          • conciselyverbose@sh.itjust.worksEnglish
            2·
            10 months ago

            lol I want some of them served publicly. And at some point I want to do other processing of the contents of photos.

            I have absolutely no opposition to the existence of an end to end encrypted photo service. If the process of adding new devices is easy enough, it’s what I’d want from someone else hosting. But it’s not what I need for personal hosting.

            Which, again, is fine. There’s absolutely a place for it. But the dude we’re responding to is acting like not doing it is a liability when there’s very good reason not to. (I think it’s because of platforms trying to muddy the water of what end to end encryption means to pretend they do it and confusing him.)

  • sunbeam60@lemmy.oneEnglish
    10·
    10 months ago

    Happy to see some alternatives, but I’m a very happy user of PhotoPrism (+PhotoSync) so will stay there for now. Agreed that encrypted at rest isn’t all that helpful for a self-hoster.

  • corsicanguppy@lemmy.caEnglish
    4·
    10 months ago

    The first two things I saw:

    • docker seems to be required
    • the download page seems to require javascript

    Too much neu hype. Done.