Mobile app implementation

[alextran1502]

I think it is a realistic expectation, or at least for Wife-Approval-Factor, to be able to journal from an app instead of going to a website.

[swalabtech]

Completely agreed.
When I started this project both mobile and web app was essential hence I picked flutter for frontend which made cross platform easy (easier, I am assuming you are pretty familiar with all the quirks of it's cross platform support given Immich mobile app is in flutter. But I can't complain it has been good). So mobile apps are pretty much ready.

Unfortunately both apple store and play store publish full legal name and address of app publisher if launched as individual which I am not comfortable with personally.

I am hoping to get to around $100/month or first $1200 total in support to launch them to cover the cost of forming an LLC/year, under which they will be launched.

I see you became a Github sponsor so thanks a lot. It means a lot and your support is special as Immich was one of the very first apps I installed after I got into self hosting. It immediately clicked for me and completely changed how I thought about self-hosted software. Seeing how powerful, polished, and user-respecting it was made me realize what’s truly possible in self-hosted domain when software is built with care and strong values. Immich has been a great inspiration for me personally for building Journiv.

Thank you.

[PaulExplorer]

Hi! Since you mentioned that a Play Store release is too much trouble, would you consider just uploading the APK file to the GitHub releases? It’s a quick way to let us use the app on Android without you having to deal with Google's store requirements. Thanks!

[swalabtech]

No. APK code can be decompiled to near source code by anyone using tools like jadx or apktool etc. Since the frontend source code is not publicly available APK can't be made available either as of now. See https://github.com/orgs/journiv/discussions/51#discussioncomment-15465666 for more details.

Thanks.

[PaulExplorer]

I understand your concern, but providing the APK via GitHub or the Play Store results in the exact same file being distributed; both can be analyzed the same way.
Also, Flutter uses AOT compilation, which is much harder to decompile than standard Android apps. Since the Web version is already public and carries the same risks, would you consider just running flutter build apk --obfuscate? It would protect your code while making the app accessible to us.

[swalabtech]

Thank you for the details.
I will look more into this based on your pointers. From my brief initial research those were my finding but I don't know much about mobile app distribution etc so I might be wrong.

Thanks.

[benedictjohannes]

https://github.com/orgs/journiv/discussions/51

I've read the discussion in full @swalabtech

If you're withholding the FE/client source code as monetization plan (and reveal so), being a developer myself, I would appreciate that and buy you coffee (or beer). You instead spent 2 hours (your words) writing an essay that I'd reckon Saitama would probably dub "pera pera" as he listened to Deep Sea King's introduction.

Btw: HTTPS client certificate generated upon login scoped to the session/user ID as CN, beats CSP as a security measure any day (including February 30th). CSP itself is a band aid useful only for leaky and loose deployments. And a Flutter client ignores CSP outside of browser environment. Implementing this allows you to host a handshake server bridging the self hosted backends - and that'll help serve the goal of keeping the lights on.

Also: Anthropic would love your suggestion to audit minified code, that'd be awesome to keep their GPU doing some work with marginal benefit for the user's purported audit intent.

PS: I might be doing just another pera-pera here. With that said, 100 situps, 100 pushups, and 10 km run deeper into open source can make your project work like it's written by Saitama himself. That is, if he doesn't destroy his keyboard, though.

[swalabtech]

Hello @benedictjohannes
Thanks for interest in Journiv and taking the time to read the discussions. Your comment has lot incorrect technical information and to be blunt I personally don't like such discussion which adds no value to the project or others than being sarcastic. Hence, this will be my last response to you on this thread.

If you're withholding the FE/client source code as monetization plan (and reveal so), being a developer myself, I would appreciate that and buy you coffee (or beer). You instead spent 2 hours (your words) writing an essay that I'd reckon Saitama would probably dub "pera pera" as he listened to Deep Sea King's introduction.

Journiv is already monetized. Please see journiv.com/plus for details. But the bottom line is that no matter what monetization scheme currently exists or develops in future it would not cover any reasonable amount of time, effort and skills which has been put in and continue to be put in this project. I am very much aware of this fact and still choose to continue working on it. Mobile apps can or cannot be monetized. I do not know. If this uncertainty is concerning to you then I will recommend checking back the project in future or find something which suits your current and future needs better.

Btw: HTTPS client certificate generated upon login scoped to the session/user ID as CN, beats CSP as a security measure any day (including February 30th). CSP itself is a band aid useful only for leaky and loose deployments. And a Flutter client ignores CSP outside of browser environment. Implementing this allows you to host a handshake server bridging the self hosted backends - and that'll help serve the goal of keeping the lights on.

This is incorrect. You are comparing two completely different layers of security. What you describe in first sentence is mTLS. It does not prevent XSS/malicious scripts or protect frontend runtime at all. Authentication and content integrity two completely different thing. A lock on the front door does not beats having smoke detectors inside.

Calling CSP a band-aid only for leaky deployments is incorrect. CSP is basis of all secure web application to run in web browser and a recommendation by OWASP. Flutter is cross platform with web support and CSP is applicable when it runs in a web browser.

If you read the discussion on the other thread you would notice I have shared information on how to verify web client CSP and how it protects. See example of trying to connect to google.com and being blocked due to CSP. Establishing an mTLS handshake with journiv-backend alone does not restrict the client from opening connections to other servers. connect-src directive of CSP does which is configured in journiv-backend

mTLS based authentication are geared for machine to machine communication and have very high friction around certificate management. Needless to say a non-requirement Journiv.

Now regarding "host a handshake server bridging the self hosted backends" this is already done in Journiv with Journiv plus. I welcome you to look at backend code on how this is implemented without mTLS which again is not required.

Also: Anthropic would love your suggestion to audit minified code, that'd be awesome to keep their GPU doing some work with marginal benefit for the user's purported audit intent.

Yes, that is why https://github.com/orgs/journiv/discussions/51 details exists so people who want to test Journiv client can do so without going through more work. I will recommend you to read it in detail to understand CSP. Journiv's self hosted backend allows user to own their data with privacy. The frontend just wraps around backend rest APIs and only knows (and allowed to) how to talk to journiv-backend as mentioned in the other discussion. If someone still is hesitant around using frontend the /docs lists all APIs with swagger docs on which they can build their own client, scripts, automation etc and do whatever they want because they own their data and the backend.

Also clarification, it is your words that Journiv is open source. I know this is always confusing to many hence Journiv on purpose refrain from using open source and uses open core. FWIW. I am sure many can still find nuances with this, but can't make everyone happy.

Thanks.

[benedictjohannes]

Hello @swalabtech,

Thanks for a prompt reply! And apologies for the sarcastic adjacent tone, apparently I was under the false pretense that all developers are fans of Saitama's bluntness.

It's my bad that I miss Journiv Plus page (thanks for the link). Tag Analytics is an lovely QoL feature for everyone, but I'm quite surprised seeing COUNT(1) and GROUP BY created_at as your currently delivered paid tier differentiator.

Regarding security: I agree CSP is a solid OWASP recommendation for the web. However, its primary role is mitigating XSS/exfiltration in the browser. In a self-hosted context, the threat model is different: the user already trusts the origin (their own server). While CSP mitigates web-specific risks well (love the google.com fetch test!), it doesn't address frontend opacity concerns for native/Flutter contexts where it doesn't apply.

mTLS based authentication are geared for machine to machine communication and have very high friction around certificate management.

Indeed you'd be right. It's also automatable. I myself run /usr/bin/code serve-web --without-connection-token (access to my entire homedir) with zero worries because my devices already has my desktop's internal CA's signed Client Certificate configured - and along with Tailscale, it's hardly take half a weekend to configure (for the initiated).

So allow me to expand on my handshake server suggestion: You could implement a OIDC and CA central provider:

1. Journiv backend deployments would trust this as identity source (configurable, on by default)
2. give directions to users managing their instances on how to utilize this (nginx snippets)
3. Have the mobile client optionally provision a certificate from it upon login
4. Offer it as part of your paid tier. The client wouldn't only be well behaved due to CSP header, it would be cryptographically bound to the user's identity.

I encourage you to include the frontend source code in your open-core offering. As a member of trade, I think I fully understand your concerns (on copycats). I don't believe frontend source code gatekeeping creates a defensible moat because you already hold control on the backend and future feature developments. Calling CSP solves security and trust lacks a defensible claim (at least for me). Since you're already offering plus tier based on backend feature, and full zero trust security is a genuinely hard problem (as you've correctly identified): I believe zero trust central authority identity layer you own adds an amazing layer of defensible moat to your paid offering, which would allow you to publish the FE source code with zero copycat worries because you would've own the ultimate security auth layer (and relegate the lesser auth method to be free).

As such, I rest my case and we might agree to disagree. Regardless, I bid you good luck for your project, and I hope its launch reach the stratosphere and beyond!