Got it. As you can see, I am myself very new to Lemmy and still learning their API. I still need to think through this more since even caching hashes will consume much more data than caching the text content of posts and replies.

Most likely I’ll want to give control to the user of what they want to cache. Either text or text + images.

Looks like lemmy api does not give the hash of the image, that's unfortunate.

You'd need to use the link field instead.

Again, I plan to add moderation features. But I am one person with a full-time job. I need to prioritize the features that will please the most users. Prioritizing everything initially could mean lots of bugs in the app, and I would lose users quickly due to a crappy app. I would rather build features slower but correctly.

That being said, if most Lemmy users moderate, then that would make this more of a core feature. But again, I want to also build an app that appeals to incoming Reddit users, and those people won’t be moderators. I’m hoping this will be a tool that can help grow Lemmy.

That would actually be easier than the offline upvote feature. The issue with offline interactions is if you upvote in one app, but downvote on another, who wins?

Whichever interaction is sent 'last' when connected. No, the user would not have any control over this in the example situation,but to be honest it is a pretty minor issue with no real solution. The same thing could happen in an arbitrary order if you clicked different options on two different browsers at approximately the same point in time because web calls are not instantaneous.

I guess it’s true that it would way more infrastructure.

Still the QR code idea would be great 👍

Thanks in advance for your work

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!

You know how when a hobby becomes your job, it often stops being fun and leads to burnout? Side projects are fun because they offer you an opportunity to build something on your own terms. I want to build the app that I want to use, and I want the freedom to make decisions.

At the same time, I want to hear from the community, and I will take into account that feedback for decisions I make.

Respectfully, some of those issues you opened up are really big asks. Specifically, offline first (RxJS) and adding activity pub support. Initially, my idea was to build an app that did both of these, but after some experimentation, I decided I would burn out before the project ever saw the light of day just trying to solve offline first.

I would still love to hear from you. But I have ideas for what I would consider core functionality, and that will come first. But I will take feedback into consideration and will likely implement some offline first functionality, which will be way simpler than being fully offline.

My tech stack will be similar enough to Voyager that it’s possible I can copy past parts of my code into their app. So I’m not ruling out contributing back to Voyager, and writing my own app doesn’t mean I won’t learn stuff that I can contribute to other clients.

it feels like FOSS alternatives would be 20 years in the future if put worked together on 2-3 alternatives instead of 20-30 disparate projects.

Honestly having 20-30 separate projects is awesome if merging in the creative bits from each were merged into the more popular ones more often. Sometimes there is a foundational difference that makes that a lot harder than plug and play, but to be honest not developing with being modular in mind is one of the biggest issues with any kind of development.

if merging in the creative bits from each were merged into the more popular ones more often.

Yeah, the pity is that most of the times this simply doesn't happen, and everyone wants to reinvent their own special flavor of wheel.