@dessalines@lemmy.ml Thanks for the information here and all the hard work you have put into this release.
Gotta say tho, as the maintainer of Lemmy-Swift-Client, breaking API changes like this without an API version bump, make API development within the community incredibly difficult.
So my question to you would be, what is the purpose of having v3 in the API path, if the true test of API compatibility is the GetServerResponse version field? And breaking changes will occur in GetServerResponse version changes as opposed to the version in the API path? That doesn't quite make sense to me.
Would love your perspective so I can figure out how to best design the package API to accommodate client developers who might have to contend with multiple server versions.
The lemmy API still hasn't hit a version 1.0, and should very much be considered beta, with a lot of active and breaking changes. When we do stabilize it, then we can start to make these breaking API changes more solid. The v3 should probably just go away at this point, because we have too much active development and API changes to justify it.
What we do on lemmy-js-client, which has its types auto-generated from rust, is use tags that match our lemmy release semver version.
I'm not sure how you built lemmy-swift-client ( I hope its auto-generated from either the rust or lemmy-js-client types), but you could do the same thing: use tags to version it, then applications could use those tagged versions.
WebSockets ... causing live updates to the site which many users dislike
I appreciate all the work in this release. It's insane how much you packed into one release. Well done. I am most excited about the live updates going away. It was quite disruptive. Thanks for that.
That said, WebSockets can be implemented very efficiently. I run an open source notification service called ntfy, and the public instance ntfy.sh currently keeps 6-8k WebSocket connections and thousands more HTTP stream (long polling HTTP) open, all on a 2 core machine with 4GB of RAM. My point being that WebSockets can be implemented very efficiently. Though in Lemmy's case it's likely not necessary.
--
Another thing I wanted to notice is that I am missing mentions of security issues in the release notes. There are some tickets that sound really really really bad, like this one: https://github.com/LemmyNet/lemmy/issues/3060
That said, WebSockets can be implemented very efficiently.
I agree, the main issue I was actually seeing with Lemmy's use of WebSockets was that when opening the main page it was continuously streaming all posts from the server (including posts in communities not subscribed to) to the browser client.
I really appreciate the work that you're doing but...
Captchas are not available in this version, as they need to be reimplemented in a different way. They will be back in 0.18.1, so wait with upgrading if you rely on them.
What the hell? Another bad default where newbies will continue to launch instances attracting 10k+ bot signups per day and new users will keep getting disgusted by Lemmy if they land on one of those spammy instances. Making captchas a default should have been a priority and I'm sure no one would have complained if the 0.18 release was postponed to make that happen.
The feed desperately needed a fix, so I'm glad they pushed it out. But agreed, they should be prioritizing methods to reduce spam and bots in the next release, even if they need to push out a relatively feature-sparse version first
I definitely would've... it was basically impossible to subscribe to communities on lemmy.world and lemmy.ml from smaller instances before 0.18.0, and after lemmy.ml updated that's no longer an issue.
All Lemmy instances on v0.18.0 are inaccessible with javascript disabled. The only way to privately browse Lemmy instances now is via kbin. I was hoping that Lemmy was going to focus more on privacy with the coming updates. Maybe this will be fixed in v0.18.1?
JavaScript itself has nothing to do with privacy. I assume you think so because you are using Tor Browser at the higest security setting that disables JavaScript entirely?
IMHO just stop using that broken-by-design browser and use a browser extension with a JavaScript allow-list.
It should still be possible to browse the internet with JS disabled. Especially Free Software should set a high standard to that. It's understandable that Lemmy devs have too much on their heads now, but let's not pretend that it's okay to make websites which aren't viewable without JS.
The piece of content in the feed is great and much more fun to browse !
That specific change makes me feel that I can jump from reddit to lemmy definitly.
There are multiple folks in Matrix who had issues, including myself. It only worked after using the only ansible to VERSION=0.18.0. The new ansible sets up local networks in docker-compose and such that do not work and lead to Gateway Timeouts.
I tried to upgrade via the instructions doing a git pull and then running ansible again and it totally broke my site with a server error message. I ended up reverting back to 0.17.4.
EDIT: It looks like they added some extra NGINX proxy stuff in there. All that broke my instance and I had previously just deployed via ansible following the instructions on their page. I would stay away for now.
Captchas have been restored by a PR shortly before release and almost immediately been removed again by reverting the PR. The PR author has been asked to re-create his PR and then 0.18.0 got released without Captchas.
I don't know how this works but I think I read somewhere that this version fixes the new post spam on browser, I checked and it's still the same, when will that be fixed? Is it an instance thing?
I noticed in the web client used on mobile, there would often be new posts flooding in at the top of the page. Maybe a page's worth at a time. I'm still using web client on mobile on lemmy.ml and haven't noticed this since the deployment of 0.18 yesterday.