Connect to self-hosted backend?

[kianenigma]

I am planning on running a self-hosted version of Habitica api/frontend for personal use. It seems like, the mobile applications do not provide an option by default to connect to a different endpoint.

It would be helpful to some if you'd have an option to provide your own API address to the mobile app, with the default being the publicly hosted Habitica.

[phillipthelen]

Currently it’s possible to configure a custom server url through the apps config files and compiling it again. Adding something in the UI to do this would be an interesting feature, but not something I would have the time to implement anytime soon, so I’ll tag this as help wanted.

[kianenigma]

Cool! glad to hear it is easily configurable.

I'm not much into IOS dev, would it be possible to install a modified binary on a device? I recall that some years ago this was quite an annoyance due to app signing restrictions.

[saraolson]

If we do this, I would like it to be a hidden feature that isn't visible to the average user since it is a very small use case. It could be through a button that only appears after switching on a 'developer mode' in app settings, or only appears when shaking your phone on the login screen or tapping a certain thing like the melior logo 5 times.

Then we would post documentation on how to do this on the habitica wiki, or provide explanation through email if someone were to reach out.

[maxkratz]

I'm interested in such a configuration possibility, to!

[szethh]

Is this being worked on? Currently the reason holding me back from using Habitica is the lack of self hosting.

[villasenor]

@phillipthelen @saraolson What is the likelihood of getting this merged in if I were to work on a PR for it? It might take me a while as I'm not a Swift developer, but I'm sure I can figure it out eventually. I like the idea of making it a hidden feature - like only showing the text field for a custom server URL if the logo is tapped 5 times. As @szethh said, the lack of ability to set a customer server URL is a major blocker. I'm running it on Kubernetes myself, so I feel the pain!

[EricMiddelhove]

I am sure I could implement this in a short amount of time. 👍🏽

[villasenor]

That would be amazing @EricMiddelhove!! When do you think you'll have time to work on it?

[EricMiddelhove]

Depends, i'll probably get this done until the end of the week. (17th July)

[villasenor]

That would be awesome @EricMiddelhove! If you need me to do any testing, please let me know.

[EricMiddelhove]

I was really busy with work this week, therefore wasn't able to implement it yet and probably wont until next weekend. I will do it then.

[EricMiddelhove]

Sadly work does not give me the time to implement this, therefore I need to give this free ... :/

[victort]

just another voice in favor of helping test this if ever implemented. kthx.

[bootymcjudy]

How could we compile this and load it into our iPhone? I can see the instruction to change debug.xcconfig, but am lost as to how to compile and load into my iPhone

[bootymcjudy]

I got as far as building using my own free developer apple ID, but the build fails indicating there is a missing Secrets.swift file, it looks like something is suppose to use the swiftgen.yml file to output it but its missing. I also renamed secrets.yml.example to secrets.yml but no luck

[nowjon]

+1 here, I'd rather not re-sign the application on my phone and don't want to pay apple's ridiculous subscription.
Would love the functionality if anyone is able to dedicate some time to it :)

[Shahin-rmz]

Hello, a new intrested user here. How is tge progress on selfhosting solution?
Thanks

[Scot-Survivor]

@EricMiddelhove do you have time to implement this now?

Or is habitica just against this idea in general?

[EricMiddelhove]

Have not looked at this for a while now. I see what I can do :)

[Shahin-rmz]

Good Christmas gift :))

[Scot-Survivor]

Thank you :)), I figured I'd ask since it was a year since the last rely from a contributor I appreciate the help.

[EricMiddelhove]

Okay so just FYI to all of you patiently waiting 🙈 I have managed to find / implement the functionality to theoretically connect to a self hosted Backend. However I am not 100% sure on how the UI for this feature should be. Any Ideas / guidance?

[Snuupy]

Okay so just FYI to all of you patiently waiting 🙈 I have managed to find / implement the functionality to theoretically connect to a self hosted Backend. However I am not 100% sure on how the UI for this feature should be. Any Ideas / guidance?

tailscale, jellyfin, immich all have locations to add a self-hosted url for example

[EricMiddelhove]

That were also ideas I had. However I ask myself where would fit such an option best in Habitica.

[Snuupy]

If I had to put it somewhere I'd put it in settings, or if a logout is necessary since settings is only available once logged in, but how does the app know to log into the selfhosted server in the first place?

in that case, maybe under menu on the main page before you select login/logout that says:

logging in on:
with options listed: habitica.com | self-hosted -> prompts user to input server URL

like bitwarden does it

my 2c

[Scot-Survivor]

Any updates on when this will be available?

[saraolson]

we don't have any plans to implement this feature at this time

[villasenor]

@saraolson thanks for responding! Is it just not as important as other things or is there a particular reason that the team does not want to add it? Like would a working PR that adds this functionality be accepted?

[diyoyo]

I got as far as building using my own free developer apple ID, but the build fails indicating there is a missing Secrets.swift file, it looks like something is suppose to use the swiftgen.yml file to output it but its missing. I also renamed secrets.yml.example to secrets.yml but no luck

Anyone can comment on this, please? I'm stuck at the same step.
I believe this might be linked to Firebase requiring a google-service.json file or something, like for the Android app? Or is it completely unrelated?

FYI, to be able to reach this step, I also had to disable "APple sign in, Siri, ...", basically all the iOS features.
Also had to change the namespace (Bundle Identifier) and the group name.
Were these changes really required or did I miss something?

[diyoyo]

For people who had a hard time (like me) setting up the self-hosted solution, even with debug.xcconfig, I just pushed my all-in-one scripts here: https://github.com/diyoyo/host-it-yourself/tree/main/ios/habitica

It does all the string replacement to allow non-subscribers to 'sign' the app, and replaces the API host directly into the swift code rather than using the debug config.

This is not the most beautiful solution, but this is the best I could come up with for my personal use.
Hope that helps.

Note that the Build always fails the first time, but then succeeds the second time. I can't figure out why.

[saraolson]

@villasenor to be honest if there was a PR ready, we would still have to really consider as a team if it's a feature we want to support for end users. the main reason being we have a very small team, and any added feature is always much more work than the initial implementation.

we've learned many times before that features are always more demanding than they seem. while we would love to implement every idea we or contributors have, its necessary to be very cautious and consider the benefit vs the costs to the wider user base. especially since we've had features like this before that have caused confusion and support burden in the past.

there's bug testing, having to support it in the future if anything breaks or changes long after the initial PR is complete, training the support team recognize it and to include it in their possible answers for things that may be wrong, documenting it somewhere for people to use it, implementing safegaurds for people that don't know what they're doing to actually not use it. and any time we make upgrades or changes, its one more thing to test. sometimes features are worth all that, and unfortunately sometimes they aren't.

we haven't closed this issue because we aren't completely set on saying no (we do see value in it), but at this point in time we aren't in a place to commit to everything i've mentioned above.