Here is our regular update that explains what we have been working on for the past two weeks. This should allow average users to keep up with development, without reading Github comments or knowing how to program.

We are slowly getting closer to the 0.19 release, although there is still a lot of work left. Client developers should read this post with information about breaking changes to update their projects.

Edit: You can test the latest 0.19 code on voyager.lemmy.ml, or by installing 0.19.0-beta.8 on your server. Be sure to report any bugs on Github.

@nutomic has closed over 100 issues, most of them duplicates, invalid or already resolved ones. He also made numerous pull requests to fix minor bugs and implement small enhancements. This includes a bug fix for federation of admin actions which was released as 0.18.5. He is also changing the way HTML escaping is handled to avoid broken texts.

@dessalines is working on redesigning the join-lemmy.org website, adding the apps and instances pages. Also worked on rewriting the Docker images to use Debian as base instead of Alpine. Additionally he is adding support for new backend features to lemmy-ui (scaled search and cursor-based pagination).

@SleeplessOne1917 has implemented support for new block instance feature, finished implementing the remote follow feature, and updated 2-Factor-Auth to account for a backend rework. He also implemented some bug fixes. He has also been working on adding authentication to lemmy-ui-leptos.

Support development

@dessalines and @nutomic are working full-time on Lemmy to integrate community contributions, fix bugs, optimize performance and much more. This work is funded exclusively through donations.

If you like using Lemmy, and want to make sure that we will always be available to work full time building it, consider donating to support its development. Recurring donations are ideal because they allow for long-term planning. But also one-time donations of any amount help us.

  • Dandroid@dandroid.app
    link
    fedilink
    English
    arrow-up
    45
    ·
    1 year ago

    Thank you for doing these regular updates. I find them very insightful. This is turning out to be a great release, and I’m very excited.

    Is there a timeline for instance-agnostic linking to posts and comments? Link to GitHub issue tracking this.I moderate a small sports community, and the lack of this feature is really impacting the user experience. We have threads for each game, but we can’t sticky a post with links to the ongoing games. Or rather, we can, but anyone not on the same instance that the link is pointing to will not be logged in after clicking it, and can’t comment or interact at all with the thread.

    I think this feature should be a candidate for the next major release, as it severely impacts new users who aren’t fully aware of how federated/instanced services work and that they are being redirected to another instance that may look the same but their account isn’t on.

    • nutomic@lemmy.mlOPM
      link
      fedilink
      English
      arrow-up
      14
      ·
      1 year ago

      In this case the problem is that I don’t have any idea how this could work in terms of federation. For users and communities it is done via webfinger, but I don’t think it would make sense to implement webfinger for posts.

      One solution suggested in the issue is to try and resolve all links in the post/comment text, and rewrite them to the local domain. That should work though it seems tricky to parse and replace links.

  • Anonymousllama@lemmy.world
    link
    fedilink
    English
    arrow-up
    16
    ·
    1 year ago

    I’m liking these periodic updates, it’s really great for transparency and engagement. Prefer this compared to trolling through GitHub. Cheers

  • chiisana@lemmy.chiisana.net
    link
    fedilink
    English
    arrow-up
    8
    ·
    1 year ago

    With the authentication header update, isn’t usual best practice to support both on the server side simultaneously, and set a deprecation window such that clients can update over time?

    • nutomic@lemmy.mlOPM
      link
      fedilink
      English
      arrow-up
      9
      ·
      1 year ago

      In this case it would be too complicated to keep supporting the old auth format. Plus we want clients to update soon because sending auth parameters in the url is not secure. Anyway clients can support 0.18 and 0.19 at the same time by sending both old and new auth params at the same time.

      • chiisana@lemmy.chiisana.net
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        5
        ·
        1 year ago

        “Too complicated” feels like a cop out… there’s no question as to whether or not clients can send both, from best practice point of view, the party instilling the change should bore the burden of supporting both for some time. I cannot and do not want to change the current release train, but I hope you can take this into consideration into the future, for future breaking changes.

    • poVoq@slrpnk.net
      link
      fedilink
      English
      arrow-up
      7
      ·
      edit-2
      1 year ago

      Apparently that is mostly possible client side. Photon already supports both, and Voyager with the latest release, but with some caveats.

      • chiisana@lemmy.chiisana.net
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 year ago

        I’m not asking about whether or not clients can do it, there’s no doubt a dual outbound header method is possible, but rather more about general development best practices. When instilling a change, isn’t it usually best to support both states to ensure least amount of users are immediately affected, and gradually bleed those stragglers out?