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
Voyager is already cross platform for iOS, Android and web. It is also open source: https://github.com/aeharding/voyager
Wow, I totally missed that. However, it does feel like the web was tacked on as an afterthought. It feels like navigation hasn’t been optimized for larger screens (see screenshot below). A sidebar would be much more usable on larger screens than this stretched bottom tab bar.
That being said, it would probably be easier for me to contribute to Voyager than to build my own app. But I also kinda want to build my own app, lol. But I might also consider contributing to voyager if they are interested in optimizing their interface for larger screens.
If you don’t like how voyager does some things, fork it to add your own ideas. It’s faster than starting from scratch.
True. The thing is, my day job dictates the tech stack I use. There are specific technologies I want to learn in my free time, and those technologies happen to align well with this app, in my opinion. Forking is probably the smarter move… but I think I’m going to do it my way.
What stack do you want to be working in?
Tamagui + One (built on React and React Native), tanstack for querying and list virtualization, flash list for native list virtualization, maybe Zustand, Dayjs. It will be 100% TypeScript. I will likely use no Server Side Rendering with React. I would like it to be possible to host the site via GitHub pages for free so the project can easily be forked. Beyond that I’m still deciding.
Good luck then, with that stack you’ll likely be working alone as contributors typically drive forwards Flutter these days. But it sounds like you’re doing this to learn anyway, which is great.
Personally I use Thunder and added the two column view for tablet, had considered PRing a web and/or desktop compilation to see how it looks, but realized I never used it. I don’t even have a standard web UI up ony server all the time.
Maybe my perception is skewed, but I just got done applying to React jobs, and there were tons of React Native gigs. I haven’t looked at Flutter in years, but I can’t imagine the market is flooded with as many Flutter people compared to React. There are also way fewer people that know Dart than JavaScript.
Tamagui is definitely more niche, but React has infected a large portion of the industry at this point, like it or not. Voyager is written in React Native.
The reason I’m choosing to go with Tamagui is that they do a good job of bridging the gap between React Web and React Native. Another solution would be to split native and web into separate code bases or share React business logic but have separate code for the web and native views.
My goal is to share as much of the code as possible. Feed virtualization will need to be handled differently on web vs native, and navigation will differ, but I’m pretty sure I can share 90% of the code between web and native.
So Tamagui is niche, but I do think it’s the right tool for the job in this case. The downside is Tamagui One is in beta, and Tamagui itself has more maturing to do, but I like what I see so far and I’m confident it will continue to improve, making it worth the investment. They also abstract away much of the complexity, which means less things I need to worry about.
Awesome! Have a look at the Lemmy Apps Directory if you are interested in comparing the features of existing apps. You should especially see the web apps section, which has some brilliant solutions to cross-platform and cross-device functionality.
Thank you! Will 100% use this as inspiration.
This directory also lists the dev for each app, and most of them are great at being responsive and helpful. Of course sometimes people get busy, but the development community has been great here.
That’s amazing! I’ll reach out to some of the devs.
Could you make a ‘save post as draft’ feature? I think that would make it stand out right now. I’m not sure if any other apps have this yet.
Connect saves drafts transparently as you move around the app.
Summit does too
Awesome, I’ll give both of these another go then. Thanks
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?
Offline posts wouldn’t suffer from this problem. That’s my very roundabout way of saying, this shouldn’t be that hard to do.
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.
Respectfully, I don’t think it’s that simple. I think it’s one of those problems that appears deceptively simple, but when you dive into it, it becomes a big headache. One big difference between truly offline first and arbitrary web requests is an offline first app imo should let you close and reopen the app without dropping those pending interactions. When you marry this with cross platform, you need a robust database solution on both native and web, which makes the stack more complicated. I will consider making aspects of the app offline first, but I have decided not to make fully offline first a core feature.
Requiring the app to be opened to sync would be annoying for someone who only uses the one app and just wants it to update in the background. Unless the two apps communicate with each other to sort out a priority, there isn’t a way to determine which one counts from the app side.
Apple is pretty stingy about how often tasks can run in the background. Offline first quickly spirals with complexity that isn’t immediately obvious imo. That’s why I don’t want to make fully local first as a core feature.
Cool. Let us know when it’s ready to download
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!:-)
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?
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?
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.
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.
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 .
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.
it should have good moderation implementation and have its markdown synced with lemmy ( like spoilers etc. ).
It should be easy to block, report.
I like the idea of the offline support. Could be cool if you are able to “download” a post for offline reading or just reading through its comments. <= could be linked with the “favorite” functionality of lemmy.
Thanks for adding another app to the diversity of lemmy.
I’m not sure what percentage of Lemmy users moderate, but I would likely prioritize features that benefit the most users. Moderation might come a little later, but my goal is to allow you to do everything through my app eventually, including moderation.
Sadly then admins and mods will not use it until it has those features as otherwise it would be pain in the *ss to use it and swap around.
Yeah, that’s primarily the reason why I’m still using Jerboa.
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.
My goal is to store everything offline for a period of time. Likely, it will be more complicated than this, but let’s say for now everything you see will be automatically cached offline for 30 days. Instead of a number of days, I will probably set a max size for the offline cache and drop the oldest data in the cache as new data comes in.
The only issue here is I’m not sure how easy it will be to cache images offline. They will take up more storage, and I’m not as familiar with image caching mechanisms for apps.
Do you know if Lemmy tends to have good alt text for images? That would be easier to cache offline instead of images.
Maybe after the initial version, I can add the ability to pin a post to your cache so it doesn’t get cleaned up automatically.
You can use the hash for image caching.
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.
Update on this matter:
I made a feature request for including an image hash with the
image_detailstable but it seems like they will be adding a blurhash field instead, which is unique enough for a temporary cache that will at most probably cache ~100 images at best.Oh and yeah, you probably should get ready to support blurhash in your client. It both acts as a small hash and a way to show blurry “previews” of the image.
I was just looking at image_details but for the height and width of the image. I see this exists in the TypeScript client schema, but I’m not seeing it populated for any posts. Any idea when this is actually populated?
Knowing the height and width of images before loading them would reduce layout shift.
Seems like the
image_detailstable was added in Lemmy v0.19.6. if you are testing it with your current instance (LW), it’s still using Lemmy v0.19.3. That’s why.Link: https://github.com/LemmyNet/lemmy/compare/0.19.5...0.19.6
Ohhh that makes sense! Thank you!
There is no implementation for alt text yet on lemmy, how would it handle post purges? / removals?
I assume you mean when my app caches a post, but that post is deleted from Lemmy. That’s a good question. Off the top of my head, I would say as soon as I know a post is deleted, I would likely want to purge it from the cache.
I guess it’s a question of whether I should respect the API saying the post is deleted or act like a temporary archive. I’m open to either. From a technical perspective, it would be simpler to act as an archive.
As far as the type of cache I use, I may use a LRU cache, which will effectively prevent something from being deleted every time you view it. So even if something was cached a long time ago, if you pull up that post again, it will reset the timer.
I would prefer if its deleted by creator or mod/admin it should be deleted as soon as possible. To reduce bad/harmful usage of that feature. But i cant stop you do otherwise ;D
I agree with that. It’s similar to if someone loads the post in their browser. If the site isn’t actively polling the API to check if the content is deleted, they will continue to see it until they reload the page. The difference is the cache lives longer. I can probably have it poll the API when they reopen a cached article, and if it’s been deleted, purge it from the cache. The result is they may see it flicker as it’s purged quickly, and if they’re offline I wouldn’t be able to poll the API.
Great idea! Just here to offer support. I don’t think voyager existing matters much, diversity is the name of the game for the fediverse.
Feature wise, I’d love to see something that embedded youtube videos and similar media with the url given but I’m not sure of the feasibility. Making something forward thinking that can eventually be integrated with other activity pub services would be a good idea but I’m certain that brings up the workload as well.
Keep us updated and make a sub when you have a name!
I have experience doing YouTube embeds. It’s not hard. It’s just a question of all the different types of media embeds I also choose to support.
Fwiw, the Tesseract front-end for Lemmy (e.g. on dubvee.org), Mbin (needs an extra button press iirc), and PieFed all do native YouTube embeds, for posts using that as their URL.
I used to love slide for reddit because I felt it did offline the best even tho it couldn’t up vote or comment
That makes sense since upvoting and commenting seem the hardest to me. I think anything that interacts with existing content in the API will be more difficult to do offline than creating new content (e.g. creating a post offline).
Offline mode will need a robust handling of replies and comments for content that has been deleted or removed if you want the user to be aware, especially if they have multiple comments on deleted posts when they reconnect.
Yes! Exactly, I don’t think offline first should be a high-priority feature. I will spend too much time trying to get it perfect at the cost of other features.
@moseschrute what advantage would this app have over voyager?
That’s a great question! As far as I can tell, Voyager is optimized for smaller screens, and larger screens are supported but not as well optimized. My app would have first-class support for large and small screen sizes. Alternatively, I may consider contributing to Voyager.
It will be responsive, supporting phone, tablet, and computer screen sizes along with everything in between.
isnt this already what browsers do? why reinvent the wheel here
Sorry, I don’t mean this to sound rude, but websites don’t magically become responsive. It takes a lot of work. And that becomes even more complicated when you want to share large amounts of code between web and native.
I’m not reinventing the wheel. I’m using the best libraries—imo— to build a responsive cross-platform app.
My favorite app for the fediverse is firefox on both mobile and laptop… but I use an instance that ‘just works’, mbin-based
mbin isn’t Lemmy, it’s just compatible with Lemmy.
yeah I forget how terrible the lemmy site is being able to access its content on a site that doesnt look like some forgot the css.
I use Voyager on android but the web client or “old reddit” style on larger screens. You could also look at redreader which is an android reddit client that could be adapted to Lemmy. IDK if there’s an iOS version.
Implement Shinigami Eyes so you can really stand out!
Settings synchronization between every device would be a big plus.
I’m really happy with Voyager on iOS, but an app for my linux computer would be welcome as I’m kind of struggling with how Lemmy appears in Firefix.
Lemmy UI is only one option, although it is the default for most instances. There are a lot of different web clients, some of which will preserve settings:
I’m surprised so few people have mentioned Thunder, which I use. Is there something keeping it from being more popular?
Thunder is a solid app! I don’t believe that it has a display for large screens like PCs, but it is cross-platform in Android and iOS.
I’m very new to Lemmy and I need to read through their API. Whatever settings they allow me to save, I’m happy to lean on their API. I just want to avoid writing my own backend.
I kinda want to avoid building a backend for this if I can. That would also mean your app wouldn’t depend on any infrastructure that I own, preventing any centralization around my backend. And it would mean a very low cost for me to maintain this app.
One way to solve sync could be to have a QR code you scan to sync settings. But it might only sync when you scan it and not continually. I can also look into any Apple or Android APIs that might make this possible, but that would leave out web, and I really want feature parity between all platforms.
But this would fall under a nice-to-have feature that I would likely not prioritize. I really want to nail down the core functionality first.
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
Why not take an existing client like Voyager, and add the features that you are missing?
This is exactly what I am doing for “easier onboarding”. I am working on a fork of Voyager, learning my way through React Native and ionic, and adding support for Fediverser to it.
That’s a great point! I kinda want to write my own client, but I haven’t ruled out contributing to Voyager. It’s very possible I totally fail, learn from my mistakes, and bring what I’ve learned to an existing app like Voyager.
I kinda want to write my own client
Fair enough, every developer goes through that.
At the same time… If this is your primary motivation I would feel like there is no point in you asking for “feedback” because you are essentially looking for validation.
I don’t mean to pick on you, I just wish we collectively learned to stop this. So much effort is wasted by individuals who want to prove something to themselves and want to go out on their own, 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.
If you are okay with reconsidering your position… go to Voyager’s discussion pages on GitHub, there a few issues I opened there and would like to tackle:
- make it offline-first (probably using something RxJS to store and sync application data and state through different apps)
- add support to browse subreddits (won’t require the API, and to ease the issue of network effects)
- make it less dependent on the Lemmy API and substitute for straight ActivityPub whenever possible
- use content-addressable storage for media (IPFS likely, but maybe also webtorrent)
If any of these things interest you, I’d love to have a longer chat and see if we can work together.
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.
You are right. I am still looking at anything related to the Fediverse as work and not as a hobby, and I shouldn’t be expecting other people to share the exact same vision and ambitions.
I do share the offline first ambition! I also probably have ADHD and a tendency to start projects without seeing them through. I think it would be wise for myself to keep the initial scope of the project small. I would love to build the app that solves everything, but in practice I know I likely won’t be able to make that happen.
From what I’ve seen, fully offline first would be more work than I believe it’s worth. Especially when you add the complexity of being cross-platform. I think I have to choose cross-platform or offline first, and I would rather solve cross-platform really well (better than Voyager IMO).
So it’s not that I don’t share your ambitions, but I need to be realistic. But if an app existed that solved all the things you mentioned, I would happily use it!
I appreciate you being understanding, and please continue to share your ambitions. I just encourage you not to be frustrated if someone closes a GitHub issue you open. Maintaining open-source software is taxing, and it doesn’t mean that the person closing the issue doesn’t like your idea.
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.
Honestly, I’d say pick an OS and stick with it. Cross platform is tricky and it’s not that good.
I’m a seasoned developer with experience in both React on the web and React Native. I’m looking for an excuse to dive into Tamagui, which is designed the tackle cross platform. So I’m excited to tackle this challenge.
Oh, never heard of that! Okay then , go on!
