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
Oh yes, definitely. BlueSky has a “bridge”, whereas the ActivityPub Protocol is a full federation protocol. The user-based, Twitter/X-like Mastodon, the user-based FaceBook-like Friendica, and the thread-based Lemmy + others all use it. Which you probably wouldn’t need to care about, since you would just call the API (except for PieFed, that’s not currently an option b/c it does not exist yet).
Much of what I am saying here is not really “actionable” atm - though it might affect how you “structure” your code, e.g. making function calls to use the API rather than do it in-line?
Although another reason that I mentioned PieFed was to point to its large & growing list of features that people kept saying that they wanted to see in Lemmy, but never seem to get added to Lemmy, although PieFed already has them (yet lacks many of the more basic, foundational features, oddly enough).
A powerful example is categories of communities - like I don’t have to go individually to !fediverse@lemmy.world and !fediverse@lemmy.zip and !communitypromo@lemmy.ca and !fedigrow@lemm.ee and !loops@lemmy.world etc., and can instead just visit https://piefed.social/topic/fediverse and see posts from all of these communities at once. That has been present in some apps - though I don’t know which ones - for a long time now.
And another is hashtags, which have worked so well elsewhere e.g. in Mastodon, and we’d love to see them add additional functionality to Lemmy too. Here is an example that uses both - although the hashtags don’t do much there since the vast majority of “Lemmy”/Threadiverse users do not use PieFed.
Interesting. If you have any talks or articles, I would love to learn more. Without knowing anything about PieFed vs Lemmy, I will say I do think it’s important with any product to nail down its core functionality first. Trying to please everyone can degrade the overall quality of the product. Is it possible Lemmy is focusing on core functionality first? Like it’s interesting that PieFed includes some features but lacks more basic features.
Swapping out API calls shouldn’t be too difficult, but if the schema of the data is very different, it could get difficult. If PieFed was a superset of Lemmy in the sense that it returned the same schema with additional information, then it becomes easier. AT Protocol is a good example of having a completely different schema, making it more difficult to implement interoperability - I know people are working on interoperability, so I’m not saying it’s impossible.
I know nothing about PieFed, so that may sound ignorant on my part, but I will do more research.
I have nothing to do with PieFed, beyond liking it and so I joined the flagship instance as a regular user, which gives me only small insight into the day-to-day usage experience:-).
That said, the main developer has given several talks - e.g. this one and see also Rimu’s YouTube channel.