We are getting closer to the next major release. This version will have many
breaking changes, so we are listing them here for app and client developers to
adjust their projects. As we prepare for the release of Lemmy 0.19.0, we’d like
to provide any app or client developers ample time to upgrade their apps, as
well as discover any problems, before we do the release. This will be at least 4
weeks from now (but likely longer). Server admins can also upgrade to the latest
release candidates for testing. Be aware that they are still unstable and
shouldn’t be used in production. As with any upgrade it is important to have
working backups in place. It should be possible for clients to support both
Lemmy 0.18 and 0.19 without major workarounds. If backwards compatibility is
causing you trouble, comment below and we will help to find a solution. To test,
you can point your app to the following test instance running a release
candidate of 0.19.0: https://voyager.lemmy.ml [https://voyager.lemmy.ml] A diff
of API changes is here: lemmy-js-client API changes from 0.18.3 -> 0.19.0-rc’s
[https://github.com/LemmyNet/lemmy-js-client/compare/0.18.3...0.19.0-rc.13] Note
for developers not using typescript or rust: If you’d like to auto-generate an
API client for your language, you can try out @MV-GH’s lemmy_openapi_spec
[https://github.com/MV-GH/lemmy_openapi_spec], or (if in kotlin), use Jerboa’s
script here
[https://github.com/dessalines/jerboa/blob/main/copy_generated_types_from_lemmy_js_client.sh].
## Major Changes ### Authentication Previous Lemmy versions used to take
authentication as query/post parameters. This is insecure and unnecessarily
complicated. With 0.19, the jwt token can be passed either as cookie with name
auth, or as header in the form Authorization: Bearer . A major advantage is that
this allows us to send proper cache-control headers, with responses to
unauthenticated users being cacheable. It also prevents token leaks in web
server logs. The login and registration endpoints attempt to set the cookie
automatically. If that is supported on your platform, you don’t have to worry
about the authentication token at all. In order for your client to be compatible
with both Lemmy 0.18 and 0.19, you should send auth in both ways. Meaning with
each API call, send the old auth query/post parameter, as well as the new header
or cookie. A few PRs detailing these changes: -
https://github.com/LemmyNet/lemmy/pull/3725
[https://github.com/LemmyNet/lemmy/pull/3725] -
https://github.com/LemmyNet/lemmy/pull/3926
[https://github.com/LemmyNet/lemmy/pull/3926] -
https://github.com/LemmyNet/lemmy/pull/3946
[https://github.com/LemmyNet/lemmy/pull/3946] -
https://github.com/LemmyNet/lemmy/pull/3982
[https://github.com/LemmyNet/lemmy/pull/3982] ### Users can block instances
Users can now block instances, so that their communities are hidden from
listings. This is done via POST /api/v3/site/block with parameters int
instance_id, bool block. https://github.com/LemmyNet/lemmy/pull/3869
[https://github.com/LemmyNet/lemmy/pull/3869] ### New sort options A new scaled
sort option has been added. This sort is identical to the Hot sort, but also
takes into account the number of each community’s active monthly users, and so
helps to boost posts from less active communities to the top.
https://github.com/LemmyNet/lemmy/pull/3907
[https://github.com/LemmyNet/lemmy/pull/3907] ### 2FA / TOTP Rework
Two-Factor-Authentication is now enabled in a two-step process to avoid locking
yourself out. Now a secret needs to be generated first with POST
/api/v3/user/totp/generate (no parameters). The generated token needs to be
added by the user to an authenticator app. Once this is completed, 2FA can be
enabled with POST /api/v3/user/totp/update. This takes a string parameter
totp_token (generated by authenticator app), and boolean enabled. 2FA can be
disabled again with the same update endpoint. Additionally, the 2FA algorithm
has been changed to SHA1 for better compatibility. The update disables 2FA for
all accounts, so that users who are locked out can use their accounts again, and
to ease the transition to the SHA1 algorithm.
https://github.com/LemmyNet/lemmy/pull/3959
[https://github.com/LemmyNet/lemmy/pull/3959] ### Timestamps now include
timezone Previous Lemmy versions used timestamps without any timezone
internally. This caused problems when federating with other software that uses
timezones. Going forward, all timestamps in the API are switching from
timestamps without time zone (2023-09-27T12:29:59.113132) to ISO8601 timestamps
(e.g. 2023-10-29T15:10:51.557399+01:00 or Z suffix). In order to be compatible
with both 0.18 and 0.19, parse the timestamp as ISO8601 and add a Z suffix if it
fails (for older versions). https://github.com/LemmyNet/lemmy/pull/3496
[https://github.com/LemmyNet/lemmy/pull/3496] ### Cursor based pagination 0.19
adds support for cursor based pagination on the /api/v3/post/list endpoint. This
is more efficient for the database. Instead of a query parameter ?page=3,
listing responses now include a field "next_page": "Pa46c" which needs to be
passed as ?page_cursor=Pa46c. The existing pagination method is still supported
for backwards compatibility, but will be removed in the next version.
https://github.com/LemmyNet/lemmy/pull/3872
[https://github.com/LemmyNet/lemmy/pull/3872] ### New endpoints for
export/import of user settings data Users can now export their profile settings
data (including subscriptions and blocklists) via GET /api/v3/user/export. The
returned JSON data should not be parsed by clients, but directly downloaded as a
file. Backups can be imported via POST /api/v3/user/import.
https://github.com/LemmyNet/lemmy/pull/3976
[https://github.com/LemmyNet/lemmy/pull/3976] ### Make remove content optional
during account deletion When a user deletes their own account using POST
/api/v3/user/delete_account, there is a new parameter called delete_content. If
it is true, all posts, comments and other content created by the user are
deleted (this is the previous default behaviour). If it is false, only the user
profile will be marked as deleted. https://github.com/LemmyNet/lemmy/pull/3817
[https://github.com/LemmyNet/lemmy/pull/3817] ### Outgoing Federation Queue The
federation queue has been rewritten to be much more performant and reliable.
This is irrelevant for client developers, but admins should look out for
potential federation problems. If you run multiple Lemmy backends for horizontal
scaling, be sure to read the updated documentation
[https://join-lemmy.org/docs/administration/horizontal_scaling.html] and set the
new configuration parameters. The Troubleshooting
[https://join-lemmy.org/docs/administration/troubleshooting.html] section has
information about how to find out the state of the federation queues.
https://github.com/LemmyNet/lemmy/pull/3605
[https://github.com/LemmyNet/lemmy/pull/3605]
Change log for upcoming Lemmy version 0.19.0 I am just reposting this from the original post: https://lemmy.ml/post/5711722.
It’s interesting to see this for the software we’re all using and it makes me want to learn a bit more about the architecture. Quite a few user-facing features and some backend improvements. For example:
Outgoing Federation Queue
The federation queue has been rewritten to be much more performant and reliable. This is irrelevant for client developers, but admins should look out for potential federation problems. If you run multiple Lemmy backends for horizontal scaling, be sure to read the updated documentation and set the new configuration parameters. The Troubleshooting section has information about how to find out the state of the federation queues.
It seems really straightforward (which is a good thing), each backend Lemmy_server handles incoming requests and also pulls from a shared queue of other federation work.
Agreed. My copy lost this documentation link in the original which gives more detail about the horizontal scaling: https://join-lemmy.org/docs/administration/horizontal_scaling.html.
It seems really straightforward (which is a good thing), each backend Lemmy_server handles incoming requests and also pulls from a shared queue of other federation work.