Here are the problems I want to solve:

The same app everywhere

It will run as a website, iOS app (also on macOS), and Android app. It will be responsive, supporting phone, tablet, and computer screen sizes along with everything in between.

And I’m not talking about simply resizing the interface. Navigation (e.g. sidebar or on mobile bottom tab bar) will match what you would expect to see on the device size you’re using. But everything else (e.g. posts) will look the same, which I hope will make it really easy to jump from mobile to desktop.

Onboarding and configuration

The app will allow you to configure it to look like a typical Reddit or Lemmy app. During the onboarding process, I will prompt you, asking which style of interface you prefer. Consider these presets, which change a bunch of more granular configuration options. I will also give you the ability to fully customize each option instead of picking a preset.

Caching and offline support

This is where it starts to get more tricky. Caching is easy. If you launch the app, it will have everything you previously saw still loaded.

I would like to make it so upvoting, for example, can be done offline. The app will optimistically apply the upvote to the post or comment, then when you reconnect to the internet, it will actually apply the upvote. This is a difficult problem to solve, so I can’t promise this will work, and it would likely be the last feature I add.

I need your feedback

This is a big project to undertake. I really want a Lemmy client that checks those boxes for myself, but I’m curious if any of those resonate with you? Is there anything I missed that you would like to see? If I do build this, I will likely have to keep the project very focused as far as features go initially.

Just for context, I’m using Voyager on iOS currently. I really like it, but the “the same app everywhere” concept and making it easier to onboard Reddit users are my main motivations for creating my own app. My app will also be fully open source

  • Nothing4You@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    27 days ago

    requires sending ~25-fold less data per post

    what are you referring to with this? AP traffic?

    do you have some more information about this?

    • OpenStars@piefed.social
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      27 days ago

      I used the raw data from this table, which is the 3rd entry in this post. It’s been a minute since I did the calculation but I think I did something like take the >4Mb of data for 20 posts that Lemmy does and compare to PieFed which:

      The PieFed home page, showing 5x more posts than Lemmy, weighs between 700 and 930 KB, depending on which posts are shown. In low bandwidth mode, the home page is only 220 KB due to not having any thumbnails.

      So despite showing 5x more posts, it still requires <1/5th the data? That’s >25 more data required per post by Lemmy than PieFed, i.e. the latter is a much more “lightweight” client.

      Edit: but if you think there is a mistake here, I’d love to hear it?

      • Nothing4You@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        ·
        27 days ago

        at least the image resizing topic has recently been fixed in lemmy, thumbnails sizes are limited (at the time of thumbnail creation) in the latest release. I’d have to look closer at the other stuff, the api part is unlikely to have changed and will affect all frontends, but js part should differ depending on the front end. some instances already use other frontends by default and there is also a replacement for lemmy-ui being worked on (lemmy-ui-leptos), but I don’t know how they compare. either.

        it should be taken into account though how much of this is cacheable as well, as it will then typically only affect the first load for the static files.

        I can totally understand the issues in general though, I’ve been living with a 64kbps uplink for several years in the past.