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
It sounds really nice. Something to decide early on is whether to make it open source. Many people who use Lemmy specifically (more so than Reddit I am saying) will only use an app that is open source.
It will be open source. I have no plans to profit from this. My goal is to keep my costs really low - as near $0 as possible - by not running any backend for the app. Everything will be local. I do hope to build a nice app with a lot of users to add to my portfolio, but other than that I mostly just want to see Lemmy succeed long term.
If PieFed had an API I would say to check it out, as many of us are looking to it as the future. It is extremely lightweight, requires sending ~25-fold less data per post, already has most of the heaviest requested features that Lemmy lacks (categories of communities, hashtags, showing of the community and instance data alongside - after - each post, labeling of users, e.g. newly created accounts, private voting, ability to democratize moderation e.g. a user can choose to auto-hide posts based on a downvote counter, allowing moderators to be looser in the strict decision to remove vs. not remove content, etc.), and much more. Like Mbin, it is another implementation of the ActivityPub Protocol that federates with Lemmy while not being Lemmy itself.
The caveat is that its web UI is horrible (lacks user tagging, many notifications don’t actually take you to where it intends, replies aren’t done in-line but on a separate page and then afterwards doesn’t return you to where you were but to a generic view of the post whereupon you may have to dig through the complex navigation all over again to find where you were before, and most damning of all, it lacks a Preview feature so you may have to do all of that multiple times to get a post to look right, like a link or image embed).
But, as I mentioned, it lacks an API. So unless you wanted to make one first and do a more full-stack than front-end project, that makes it a nonstarter no matter how awesome and a perfect fit the idea would have been otherwise. I did want to mention it though, just in case, and also to plant the seed in your mind that perhaps when an API is available it would be awesome to be able to switch to PieFed or Lemmy (or Mbin?) rather than be locked solely into just “Lemmy”. Especially if Lemmy.World switches to PieFed let’s say 1-3 years from now, bc that one instance holds ~80% of all the users on it.
So… check it out!:-)
what are you referring to with this? AP traffic?
do you have some more information about this?
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:
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?
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.
All good points. I also don’t know how much is cacheable, but regardless, how much of that actually is cached, vs. being sent again and again?
Separately from the per-page considerations, from what people are saying it seems like a great deal of unnecessary info is sent along with each and every post that could be delayed until the user decides that they actually do want the additional info to make it worthwhile to pull in from the backend.
Yes some apps may also be lightweight, and perhaps PieFed could do a comparison with them as well, but to some degree that’s an apples to oranges comparison (hehe, yet both are different kinds of fruits! and one may indeed find themselves in a position needing to choose between them at a grocery/market:-), seeing as how a web based UI needs to run in multiple browsers yet conversely runs from any OS.
If leptos also ends up being lightweight then it could be compared to PieFed at that time in that regard. Though atm all that PieFed can compare itself against are things available to be tested. And perhaps leptos will borrow a few tricks from PieFed by that time, or even if providing an entirely independent execution, could solve some of the same issues. Do you know if leptos is supposed to share that feature of being lightweight, or were you just saying that it will exist at some point?
I need to set some constraints for the project. IMO, going multi-protocol will be too much work. I would rather do one protocol really well than try and satisfy multiple. I also primarily use Lemmy, and a Lemmy-based app is something I myself would actually use. Doing a different protocol would require me to put myself in the headspace of users that I’m not as familiar with. Much of building an app is sympathizing with your user base not just technical.
But I plan on making the app open source, and that means it can always be forked and adapted to a different protocol later. And I’m happy to draw inspiration from other protocols.
I appreciate the idea! I think a multi-protocol app would be great, but again I think for this project and my limited time, doing one thing well would yield a better result.
8 months ago the admins of Lemmy.World (which has ~80% of all Lemmy users on it) strongly hinted that in the future they may consider leaving Lemmy and moving to a different codebase (for, let’s just say “reasons”). Their hope was Sublinks, however ever since that project has basically died off, yet PieFed has surged forward in its place.
So I am not trying to tell you what to do, just offering that wider perspective. Especially since I noticed that your account was only a month old so you may not know the entire history behind Lemmy, and thus find it more surprising when such an event as mentioned above may transpire “suddenly” and “without warning” - except that there are signs, and have been since the beginning. Phrased another way: is your hope to keep “Lemmy” alive - the Lemmy that was written by the codebase developers who consistently advocate for genocide of Western people (especially landlords) and upheaval via violent means of Western civilization, while simultaneously denying that genocide has ever taken place in certain formerly communist nations (including Russia, China, and North Korea), and also being against “capitalism”, even while ignoring how some of their favorite nations are themselves capitalist? (again, e.g. Russia)?
Or is your goal to keep the spirt of the free & open source software “Fediverse” alive? The latter also includes Mbin and PieFed (and perhaps one day Sublinks if it ever resurrects from its apparent demise), all of which interact with “Lemmy” as in what most of us try to avoid calling the “Threadiverse”, despite how that name predated Meta’s “Threads” service and more accurately describes the threaded conversational nature of what we do here. So just to have a single name to call it, mostly we call it “Lemmy”, but it’s not Lemmy, it’s also Mbin and PieFed, and one day perhaps other things too, which uses the identical ActivityPub Protocol to share its messages with users on Lemmy. Case in point, I switched above from my first reply being from my old Lemmy account on Discuss.Online and ever since have been using PieFed - but did you even notice? :-P “Lemmy” and “the Threadiverse” have become somewhat synonymous in our usage of terminology, though they are different, and yet they are also the same.
Again, do as you please ofc, but I hope this discussion might have helped!:-)
That makes sense. I appreciate the history lesson. You’re right, my account is very new, and I’m new to Lemmy. Maybe the protocols you mentioned are more compatible than I realize. I would imagine that if Lemmy.world migrates, what they migrate to will be more similar to Lemmy than something like AT Protocol. So it might be okay to run with Lemmy for now and then adapt later depending on where most users wind up.
I still would like to keep the project’s scope smaller, but if there was a mass migration from Lemmy, I would absolutely reconsider. Let me also read up on the similarity of the protocols. If interoperability is easy to do, I’ll consider interoperability from day one.
FYI, its not true the 80 percent of users are on lemmy.world see here (total number of active users) and here (number of lemmy.world active users).
Also piefed as far as i know does not really support multireddits , you can’t define a feed of groups of communities as a user. piefed topics are configured by admins or the developers .
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.
Not just open source. It needs to have a sustainable community of developers. I’m not interested in a project that dies when the one maintainer has other priorities (been there with another lemmy app) Open source just means anyone can fork it and carry on, but if nobody does, it still dies.
In that case, it would have been better if OP had offered the type of functionality that they wanted (e.g. cross-platform support, better responsiveness to tablet screens, etc.) to Voyager, as in like make a fork of Voyager and add in the new desired features. Elsewhere in this thread OP acknowledges that this would have been preferable… yet they are going to do their own thing regardless. Which isn’t nothing imho, even if something else might have been more ideal.