Not the OP, but I believe they’re talking about the upgrade from 128 bit AES to 256 bit AES. It created some compatibility issues between clients for a few days as the ones that weren’t updated yet couldn’t decrypt the newer 256 AES encrypted notes. That was my experience anyways. It’s a great app/server from my personal experience.

If it’s only been a day, I might wait a bit longer before writing it off. The issue could very well be resolved soon. Even the big tech companies have a service go through problems for a day or two.

I only tested Notesnook for a few days, so I may not remember it’s key elements well, but Standard Notes seemed like a very similar product (the downside is the subscription, it was basically unusable to me without paying).

The NotesNook UI is the best I’ve seen, it’s hard to find that level of polish in a FOSS android app.

I think you’ll struggle to find what you’re looking for without a subscription model unfortunately. If you do want to retry Joplin that is my recommendation, I run it with a locally hosted Joplin sync server, it’s fantastic for my use case. It’s been recieving a lot of solid updates lately too.

My thoughts exactly

I’ve basically agreed with you this whole time, see my initial comment regarding the difference between the previous comtribution model and the new request for purchase:

Yeah, functionally it’s the same.

However we’re drawing different conclusions about the situation. You say it’s misleading and morally wrong to refer to “buying” this software, I say it isn’t and that it’s actually a helpful perceptual change in fostering support from their users.

I don’t really think there’s anything else to say beyond that. If you don’t like how Immich is handling their software, don’t use it.

Evidently there’s some difference to the approach. I’m not familiar with the WinRAR days, but they specifically address that in this video. I don’t know if it being similar to WinRAR is a good thing or bad thing in your book, but maybe you’ll enjoy the video.

https://www.youtube.com/watch?v=YdwG6SHeZEA

The technicality of usage rights is irrelevant, the developer is asking you to pay a set price that they’ve set as the total they would like to be reimbursed for providing the development service. That’s not a contribution, that’s a purchase. They’re generous people though, so they won’t restrict your use of the software if you choose not to pay.

Maybe you make donations to FOSS developers regularly. Unfortunately, I did not in the past. While I always intended to, it just slipped through the cracks. After running in to FUTO and the software they sponsor, I’ve been motivated to donate to or purchase much of the free software I’m using, and it’s entirely because of the way they approach their relationship with the user.

If you feel like that’s a dark pattern, or that your payment would only be purchasing an empty NFT, then I guess that’s your choice. But purchasing FOSS applications provides an incredibly important line of support to developers who stem the tide of surveillance capitalism and the digital abuse that big tech has filled our world with. Call it a donation, contribution or purchase price. In any case you are exchanging value for something that has made your life better and supporting the person who made that possible.

Maybe it would help to view the cost of Immich as purchasing a ethics NFT. Sure, you have no observable difference in the material world, but you as a person have affirmed your ethical values through reciprocal action with someone who shares those values 😉

Ownership is being conferred by purchasing immich, that’s what the product key codes they’ve started using indicate.

That is the fundamemental change in the way they are offering Immich: if you pay, you are provided with proof of ownership (product key). If you don’t, you are using it as a part of an indefinent trial period.

Why do you think you aren’t really buying it? Is it because they allow you to run it without paying money for it?

I don’t think the definition of “purchasing” software should be defined by whether you can run the service without paying or not. I think it’s best defined as paying money for something that you like and want to exchange value for. In my book that’s nothing near a dark pattern, as I can’t imagine anyone being confused by it, let alone mistakenly believing there is missing features that they won’t get until they buy.

Privacy is a marketing angle right now for sure. I hate seeing companies like apple advertise to the vague privacy concerns of the general public. Companies like Proton are also making money based on privacy concerns.

As far as I’ve seen, FUTO’s approach is to fund and support independent developers who have a high skill level and well thought out piece of software. They focus on software that is Open, or source available for auditing and viewing purposes, privacy respecting and free of any kind of advertising. They also are pushing for a new culture of payment to these developers that is not a donation to support, but a purchase to use. They don’t insist on the purchase though, you can use any piece of FUTO sponsored software free of charge indefinitely.

They do, but I don’t think that would apply to Immich. Immich is under the AGPL, and hasn’t taken on any FUTO licensing. In a QA they did awhile back they said there was no plans to change it as well, so should be AGPL for the long term.

As far as I’ve seen, the only connection that Immich has with FUTO is the $1M grant and continued development support. I would imagine any sales from these Immich server purchases are now obligated to go to FUTO, but that’s the only connection between the two companies.

I saw a lot of concern in the original github announcement regarding the use of the term “license.” People felt it gave the team a legal footing to paywall features down the road and offer them only to licensed users, along with a few other concerns based in the legal implication of the term license. That of course runs counter to their statement that no features will be paywalled ever, so I guess there’s still some anxiety over their trustworthiness out there. Understandable given some of the rug pulls that have happened in the open source world over the past year though (i.e Redhat, redis, etc…)

Yeah, functionally it’s the same. However I think it is a big perceptual change to be in line with the FUTO principle of “we want to make good software that is open and accessible, but we would also like you to pay us for it so we can continue this project sustainably.” That’s a bit of a contrast with the general open source approach of “I’m writing this software as a service to others, make a donation if you’d like to support my work.”

Personally I think the move towards a more structured buy it if you can mindset is great. I’ve seen too many projects get abandoned because of lack of time and resources and then shift from developer to developer, sometimes getting better, sometimes worse.

Me too. It’s a quality app, the only other open source keyboard that rivals it in my mind is Heliboard.

I’d argue that’s just a license for 4+ users as the only differentiation is the dollar amount. In fact one of Alex Tran’s comments in the github announcement was that they simply capped the price at $100 to keep it from getting too expensive for instances with many users. It’s definitely licensing based on users, not servers.

I would be much more comfortable if their licensing language was centered on licensing a self-hosted server, not user amounts. Paying for individual users (IMO) is best done as a hosted service with a monthly fee. They’re probably a ways from being able to implement that though.

EDIT: they’ve adjusted the language and integration of buying the Immich software. It’s much clearer and balanced now. You can find the new info on their github announcements page, or likely in the notes of their next immich release.

ORIGINAL COMMENT
I was really looking forward to them opening a compensation option as I got in after they had taken down donation links, but this is all a bit weird. There is some good discussion happening on the github announcement page. I’ll probably hold at version 1.108 for awhile until the dust settles.

I’ve gone through quite a few FUTO videos since they started sponsoring Immich, and it seems like the issue is that they are essentially an organization of engineers that don’t have a strong background in the legalese of licensing (thus the lack of attention to the wording of the original FUTO temporary license). Their intentions and goals are solid from my perspective and the software they promote is fantastic, but it feels very much like an org run by idealistic engineers without much of a PR presence. The best PR they have is Louis Rossman, take that as you will 😄

All that being said, I have paid for a few of their other pieces of software that are single user. The part I’m not overly fond of is that it seems to be a payment for each individual user, and not a payment to be able to run the server itself. I’m sure there is rational behind it, but it just feels like this whole licensing element isn’t fully baked yet.

Interesting, yeah I did see in the github issues that Jellyfin itself was a bit unpredictable in triggering the right information requests from the plugin and that it may suddenly start working just because Jellyfin finally fired off correctly. I guess I’ll just be patient 😅

I haven’t run in to any freezing issues either. It sounds like it might be a network issue, do you access the service over your local network or by external DNS?

Not to hijack your post, but do you use tubearchivist-jf-plugin for getting metadata in to jellyfin? I cannot seem to get that plugin to function on my set up for some reason which makes it very hard to view the tubearchivist library on jellyfin 😢

Me too, the mobile device landscape is definitely shaped by consumerist values. Divest has been intriguing me lately as well, I used to think it was a more flexible, less hardened alternative to Graphene, but it seems to have continued on down the road a ways past Graphene now. That wiki looks super interesting, I’m going to check it out. Just a quick look through what they have looks like high quality info.

Yes that’s the benefit of verified boot, and it is a helpful security feature. However, if you’ve used or are using Windows or Linux as an operating system, then you are comfortable with using a device that does not have verified boot (not sure about iOS and Mac, I’m not familiar with them). The risk you’re talking about with malicious code being injected in to an app you’ve chosen to trust is a threat to any device, verified boot or not. Modification of the kernel is an attack vector, but it certainly isn’t the only way for an app to cause mischief on your phone and devices are all relatively as vulnerable to developer or supply chain attacks.

Using software someone else developed always comes down to trust, unless you are auditing the code for every app you use, which I don’t think either you or I are. Having features that increase security in some technical way feels good but may lull us a sense of security. For instance, here’s a quote from a security researcher that I ran across in the past. It’s regarding the reputation for security that iOS has:

Erez Metula, founder of a a security and penetration testing firm called AppSec labs: “There’s a myth that iOS apps are more secure than Android. But the truth is, iOS apps are even worse in terms of security. When we do penetration testing for our customers, we’re often asked to test their Android and iOS versions of the same app. We have realized that since iOS developers incorrectly assume that iOS is ‘more secure,’ they allow themselves to make bad security decisions that open up vulnerabilities in their app.” He added, “Interestingly, since Android developers think that Android security is worse, it pressures them to follow better security practices.”

The same is true for us users. Security features are important, but user education and awareness is the most important element of keeping ourselves from ‘making bad decisions and opening up security vulnerabilities’ in our device usage.

Thankfully like you said, there are thousands of highly qualified individuals vetting the code of mainstream open source projects, which saves us regular users in the case we face an xz situation. A few principles that outway security features like verified boot in my book are:

1. Use open source software whenever possible, and make sure that it is widely used and visible to others.
2. Check the “issues” section of the documentation frequently. Even widely used software can be riddled with unpatched security holes (I’m looking at you Nginx Proxy Manager 😄)
3. I may get some hate for this one, but use a trusted middleman like F-droid as your app vendor for apps that do not have wide circulation or visibility. They run basic checks of the code for safety before uploading to their repos, checks that regular users are not able to do.

Unless you are being targeted by a stalker, a malicious state actor or are downloading disreputable software, the average user (with a little bit of knowledge) would be just fine on /e/ or lineageOS. Tens of thousands of people are right now without any problems.

Like you say, it is moderately de-googled, which is a fantastic improvement over stock android any way you spin it. I believe that was the point of the original commenter, as it is mine. However there are those blobs that do get left in (in every ROM, including even DivestOS which is the most aggresive in this regard). Install a firewall or network monitor on a device that’s only been somewhat deblobbed and you’ll find that they are not little black boxes sending all your data to Google, but instead are there to do things locally like software interaction with hardware in the phone that is from another company like Broadcom.

Any ROM on a Samsung phone probably lags on security updates due to Samsung itself being slow to release them, though they do seem to be doing better lately. If the ROM itself is slow to push updates, the most you’ll wait is 2-3 months. That’s pretty much not a problem unless you’re being threatened by state level actors, and is the state that the majority of stock android users are in. In fact, stock android can often be years out of date because their manufacturer just doesn’t put them out.

Regarding dependence on Google services (play store of otherwise), let’s be honest, GrapheneOS users almost always install sandboxed play services, work profile or not. I don’t blame them, it’s how I have Graphene installed on my phone. However, this not a privacy oriented thing to do, it releases a flood of information to Google, much more that a simple connectivity check or SUPL ping. It’s not as much as fully integrated play services though, which is good. MicroG may be theoretically less secure, but it is certainly more private. It simply asks for less information from you than play services do.

The relockable bootloader subject is bit of a pet peeve of mine. Personally, I do choose to use a pixel so that I can have that added security, as it does have value. However, to say that without a lockable bootloader you are compromising your security and by extension privacy is what i would consider an overstatement that creates fear and uncertainty. Your security and privacy only become compromised if a thief steals your physical device then also has the know how to execute a sophisticated software based attack on the phone using adb. This just isn’t something that happens. In the many years I’ve been around the android ROM community, privacy/security focused or otherwise, I’ve not heard of this happening even once. To tie it back in to the OP, this scenario is actually a perfect use case for the app mentioned in this post, it offers you the ability to remotely wipe the device if it’s been stolen.

It can be an issue from a software angle though too, but then you would have to download and install a piece of malicious software that is specifically targeting phones without verified boot. At that point there is a greater issue though, because you can download and install malicious software that is targeting phones that DO have verified boot active just as easily. All that’s necessary is to be well informed and have good security habits and behaviors, it’s how desktop competant windows and Linux users have gotten along just fine all these decades.

It’s easy to get swept up in the security dogma of the android ROM community. In my opinion, some of it is helpful, but some is not practical or useful for every day users.