It’s funny how common this mindset is in the self-hosting community: “If I’m running it on my own hardware, the software should basically be free… maybe I’ll toss a tiny ‘tip’ if I feel generous.”

The logic seems to be that since there’s no ongoing server cost, the developer’s time, skill, and effort must somehow be worth nothing and that we should magically fund the entire project through some hypothetical cloud version that they themselves will never use.

It’s like showing up to a brewery with your own growler and expecting the beer to be free because you didn’t use their glass.

Thank you. Yes, as a software engineer, not using AI for tasks where it can significantly accelerate development would be unrealistic. Much of the boilerplate code such as database ORM models, serialization/deserialization logic, and documentation was written with AI assistance, as mentioned in the project’s README. No developer writes such consistent and complete API docs :D. The architecture, UI/UX and harder aspects (see below) are done by me. It took me 2 months of late nights (hundreds of hours so far) and spending every minute outside of job and family on this and without AI would have taken much more. What you see now is the result of many iteration, refining the UI/UX, redesigning the database, and reworking the overall architecture, flighting with CORS configs make video player work on web in flutter etc etc... much of which isn’t visible from the outside.

Journiv is source-available but not “Free Software” under the FSF/OSI definition. I chose the PolyForm Noncommercial 1.0.0 license intentionally to keep the code open for personal and educational use which allow hosting for non-commercial while preventing "commercial" redistribution or hosting for commercial gain without permission.

My motivation behind Journiv is to give a solution to self hosted people like me and other a journal first experience on par with any major cloud offering so that they don't have to mold their usage to a notes app and be unsatisfied and frustrated like me. This license enables everyone in the self hosted community to use Journiv.

I did consider permissive and copyleft licenses (Apache, GPL, BSD, etc.), but sustainability is a major concern for this project. I have already spent hundreds of hours on this over last couple of months and there is so much more to build (take a look at the issues page of github repo). I want to keep development open and transparent while ensuring that commercial entities can’t simply repackage and profit from it.

Please read the documentation linked in the ReadMe and you can try out all the security features.

There are docs for auth model, the code around it, the limitation of in-mem tokens, the clear documentation around token handling, the code to support CORS, trusted host middleware, CSP, HSTS, rate limiting. You can read the env.template and configure and try it out. I doubt there are self hosted (vibe coded, ai-assisted or even non vibe coded) existing apps which have these security feature in v0.1 or even later.

Like mentioned in comment and ReadMe the project is written with AI assistance not vibe coded or AI driven development. If you will read the code, look at design and db model you will find the answers you are seeking. Having said that I am always looking to make the project better so if you find anything which can be improved please open a PR.

Thank you.

The article and discussion here is about open source software which is not free software. Thats where the problem lies it is assumed that open source software has be free.

Freedom in software does not mean free software.

You are reading too much into it... Happy thanksgiving!

Thank you using Journiv. Please report and feature request or bugs on Github. Regarding how long term:

• It is very dependent on the support and sustainability the project gets from the community. So if you feel the project makes your life better and is valuable to you then definitely consider contributing and supporting it https://journiv.com/sponsors
• Journiv, core mission is to let users completely control their data and enable freedom to do whatever they wan't with it. So open data formats and robust export is being built from day one. Journiv-viewer (coming soon https://journiv.com/docs/guides/journiv-viewer#exporting-to-markdown) allow users to access their journiv export as HTML webpages completely client side and standalone HTML pages. So even if you don't have journiv instance running years down the line you have easy access to your journals. This viewer can also generate markdown export zips with frontmatter which can then be imported to any markdown viewer or note app which support markdown without any metadata loss.

I really can't believe this is going so far for a sentence in the post...

Like I said above that is your interpretation of the sentence. People can have their own. The sentence does not state a fact which is either true or false.

So this Thanksgiving, give your family the gift of memories that last forever!

This is what I was thinking when I wrote that. "give your family the gift of memories that last forever" you don't even have to give them the instance software to use it. You start using it capturing your memories and thoughts where you have full control and ownership on your data which can last with you for decades rather than according to some third party company terms and policies etc.

At somepoint you can "if you want to" give all/some part of it to your kids/family. What is said above is how Journiv started https://journiv.com/blog/the-story-behind-journiv

My kids are growing faster than I can keep up. Every day brings a hundred tiny moments worth remembering: the first clumsy dance, the way they mangle a new word, the small family adventures I wish I could preserve forever. Like many parents, I wanted to capture these moments—not just for today, but so my kids could look back decades from now and see their childhood through my eyes.

Quoted text ^

Both Day One and Apple Journal, which this software is proudly positioned as an alternative to, marketed themselves on “personal” and “private”, not “for the family”.

Yes because even they can just easily give it away in Apple or Google play family sharing they want you to pay the subscription individually :)

And now I am out of this comment thread. I don't think I will have the last word here so I will let you go next :)

No. There are feature requests to add support for imports from various places. If you plan to use the app please open an issue.

Thanks.

Thank you.

I am not sure where this thread is going. I don't see it adding any value to the discussion or the project. If you have any specific feedback on how to make the project better. I will love to hear that.

I am also not sure how nitpicking on choice of word is helpful here. People can interpret things differently and above is your interpretation.

To provide context on why the post has that sentence:

• The major feature of this release is user management with RBAC.
• You might not have a use case where you use software with other family members but many do specifically in self hosted world where they self host for the family. See:
• https://github.com/journiv/journiv-app/issues/93
• https://github.com/journiv/journiv-app/issues/41
• https://github.com/journiv/journiv-app/issues/18
• https://github.com/journiv/journiv-app/issues/62 many more ...
• Hence that sentence.
• Like I said you are reading too much into it. Its like a vegan having a problem with a billboard which says "Delicious meat" just because they don't eat meat.

Thank you. I am glad you like it.

In CalDAV specification journal is supported by VJOURNAL which is not specifically CALDAV.

My understanding so far is that no one specifically uses VJOURNAL due to lack of its adoption and features but have a feeling it is a standard which should be followed based on the fact how dominant CALDAV is but VJOURNAL is not CALDAV and is not same. The post goes in details about limitation and issues with VJOURNAL.

Thank you for adopting Journiv! Yes the export will be added. I do agree with you that a human accessible export is very important. I am a software engineer who knows how to make docker backups etc etc but I never do it :) I know I can set it be automated but the friction is too high to do it.

Journiv is being built for out of need and to be the solution of owning memory so it long term strategy is at it's core. I am personally using it for all my memories with my young family so it will be devastating to lose it because of backup friction.

My plan for Journiv is:

1. 1 Click export which periodically created a static HTML site with all the entries and media. Zips it and put in local location configured by user. Since journiv run in a docker container the first phase will be putting it but not tied to docker container lifecycle. Second phase will be integration with a network file share where Journiv can automatically dump the export. Once I configure it I want it to just work not fiddle or worry about making backup. If backup fails I get some discord/telegram notification or within Journiv app.
2. Flat JSON export with media. HTML static site will allow user to see entries but JSON export is critical so that the entries can also be exported some where else if the need be.

Yes, mobile clients are coming. I want to have adoption and sustainability before investing time and resources in launching mobile clients. That is the reason why they will come little after. There has been lot of interest and appreciation for the app as you can see in github issues so stay tuned.

Thank you. I will incorporate this.

Thank you.

Exactly for the reason you said. They don't care about your privacy they want your verified email address to sell to the higher bidder.

YUNOhost looks interesting. I didn't know about it. Thanks I will look into it. Is YUNOhost popular?

Thanks! My main focus right now is simply building the product, the license doesn’t matter much if the product itself isn’t good yet. It’s always easier to move to a less restrictive license later than to go the other way, so this is the approach I’m starting with.