How can we help continue the project?

[yunanwg]

It's been a while that I was saddened by the infamous decision to close official Omnivore instance, and hope remerged after the takeover of some community members to maintain the project and make it real selfhostable. Special thanks to @Podginator!

I think there are still a lot of things to do here beyond the development of the core codebase: browser extensions, native apps, cleaning up the massive obsolete issues and PRs, and even a Discord community to maintain.

How can we help? Omnivore is by far the best Read-it-Later application for me and for many of us I believe; I am by no means the most technical person to contribute to development, but I'd be keen to help on other aspects if needed.

Open to your opinion!

[Podginator]

Hi!

Fantastic question: I have a list of things that are on my radar, and I would love for people to extend this list and contribute. I now have admin rights to the project, so I will happily review and accept any and all PRs that come in.

This is my personal list, some of these things have already been done. You have also raised some good ideas here, so I will add them here as well.

I think I will open a github project, so we can have a trello like board for people to add new ideas and pick up issues.

Podginator's list:

• Fix iOS application so that it can work with self-hosted
• Replace the PDF Viewer (PDF Kit) with an open source version (PDF.js Based)
• Fix PDF 401 issue, when first opening a PDF. (Due to expired signed url)
• Add loading screen to PDF when opening, as currently it sits empty until the PDF is loaded.
• Add pinch to zoom into the PDF Viewer
• Add PDF Viewer to the Android Application
• Add PDF Viewer to the iOS Application
• Write total from scratch guide encompassing
  • What is Docker, and why do we use it?
  • What DNS is, and how to get your application online
  • Cloudflare Tunnels, and what they are used for
  • Windows/Mac/Linux guides (Including Raspberry Pi)
• Write gmail script guide, that can take an email received on a specific email, and send it over to omnivore's email list.
• Write NGINX mixed with Docker
• Write Kubernetes version (Modify existing Helm Script?)
• Write Tailscale version

Nice to have

• Remove use of Redis, and Redis queues, and simplify the deployment. (Self-hosted version probably doesn't need a lot of this stuff.)

Community Raised Issues:

• Clean up existing Issues and clear up existing Pull Requests.
• Add official way to add self-hosted URL to extensions
• Modify Obsidian plugin to enable the use of self-hosted images.
• Fix iOs application to enable the use of Self-Hosted instances.

[yunanwg]

Perfect!

Yes having a GitHub project is a good idea.

I can help do the technical writing and issue and PR maintaining part; how can we proceed?

I was also wondering if we want to close all historical issues and PRs, as most of them are stale already. If so, I don't mind doing a bit of the housekeeping.

[yunanwg]

Also personally I would love to see how we can better consolidate the Docker setup. Having more than 10 services is quite heavy in my opinion.

If we get to lightweight the setup, I can also help create templates on Railway, Zeabur or Fly.io so that it could be easier for less-techy people to enjoy this project without the official instance.

Ambitious but quite promising!

[Podginator]

I don't necessarily disagree; of course the first step was to get a working setup - some of which required the replication of some services.

Of the services in the docker compose file there are:

• Postgres - necessary
  • Migrate - Necessary, but runs once at startup.
• Minio - Could be abstracted away to use local filesystems eventually.
  • Create-buckets - Literally just runs some minio commands, before exiting
• Redis - Could be abstracted away to either use a local-cache, or no cache at all. Also part of the Queueing System.
• queue-processor - Could be abstracted away to run in the api - Might increase API latency.
• mail-watch-server - Could be folded into the existing API - but kept external for now due to separation of concerns.
• content-fetch - Necessary for content-parsing, but could be ran in the same docker container as the API, and ran asynchronously.
• Image-proxy - I assume this was more necessary when there was a centralised service running, where a high volume of requests would come from gcs. It might be possible to eliminate the need for image proxy entirely, and just use the raw links to images. The risk would be that some of these images might be blocked.

So with some careful code-changes I think it'd be possible to go down to a really reduced set of services. API, Postgres, Web. Something like this could also probably run in a single docker container.

If this is something that is tackled, though, I would prefer it to be on a separate branch. I think having the main branch remain as the service as it used to run (or a close enough facsimile of this) is beneficial. It shows how the service used to run, and shows how it was architected.

[yunanwg]

Totally agree. Let's save it for later on, ideally to be added in the GitHub Project.

We can start by cleaning up the issues and PRs and make this out of the remnants of the old codebase. Feel free to add me as maintainer if I can be of help!

[pgrosslicht]

Fix iOS application so that it can work with self-hosted

I took a look at the iOS application and I'm wondering what exactly there is left to do. There's a settings view to allow to set a custom, self-hosted url (https://github.com/omnivore-app/omnivore/blob/main/apple/OmnivoreKit/Sources/App/Views/SelfHostSettingsView.swift) and functionality to switch between environments (https://github.com/omnivore-app/omnivore/blob/main/apple/OmnivoreKit/Sources/Models/AppEnvironment.swift) in place.

[Podginator]

@pgrosslicht I am unsure of where the actual issue lies, but it immediately crashes on login attempt when you change the self-hosted settings.

[pgrosslicht]

Ok, so I did some analysis and this is such a stupid bug. In the AppEnvironment.swift, the reading of the UserDefaults is consistently using the wrong group name, group.app.omnnivoreapp instead of group.app.omnivoreapp (note the double n in omni). This leads to the UserDefaults being written in the correct place, but then read from the wrong one. I created a PR to fix this (#4541), however I started to wonder: can we even publish a new version to the App Store?

[mikepng]

@pgrosslicht The only way to publish the iOS app to the App Store is with an Apple Developer Account. The Europeans can install the app using alternative app marketplaces or web distribution. (https://altstore.io/)

[pgrosslicht]

I'm familiar with iOS App Distribution. Any way to distribute an iOS App (except providing an unnotarized, unsigned IPA that users need to sideload themselves) requires an Apple Developer Account. Even the alternative app marketplaces are rather useless, since you still need an Apple Developer Account to get your app notarized. At least it seems that the Core Technologies Fee no longer applies to apps that don't earn any money at all, but this would probably only apply to a version of Omnivore that only supports self hosted options and no paid option at all.

[finlay-mcaree]

[this should probably be a new thread/issue specific to the iOS app]

Even with an apple dev account, someone would either have to create a new bundle id and re-publish the app on the store with a new name, or be added to the existing dev account by whoever owns it - presumably @jacksonh? - then push an update.