I am on the side-line itching to jump into Logseq, but I still have doubts …
I currently use Joplin and for two main reason (aside that it is a great note-taking app):
It uses Markdown; so notes will not be locked in.
It is open-source (MIT License) so I do not have to worry about some company dying and the software as well.
I can self-host the synchronization server, using either WebDAV or the Joplin-server container (I use WebDAV).
I know Logseq uses Markdown and hence notes are easily exportable. But I am not clear on the other two points …
Regarding (1):
I see that Logseq uses AGPL license. Which should be even more strict about open-sourcing the code than the MIT license (if I understand correctly). Hence there is no need to worry about this aspect … correct?!
Regarding (2):
I know that the synchronization feature is still in development and testable by sponsors (I saw this in the settings; though I am unsure what “sponsor” means). From researching this forum, I have found out that there are other methods (Git, Syncthing, iCloud) to synchronize, but with mixed results.
So hence, my question, whether the synchronization-feature that is being developed will be self-hostable in order to have a reliable, but fully private way of doing the synchronization?
I realize that the questions above also raise the question of what the business model is for Logseq? How do the developers make their well-deserved money and how do I show my appreciation (i.e. pay), once I decide to commit to Logseq?
Regarding (1):
I see that Logseq uses AGPL license. Which should be even more strict about open-sourcing the code than the MIT license (if I understand correctly). Hence there is no need to worry about this aspect … correct?
Correct, because it is copyleft. All derivative works must retain the same freedoms as the original, if I’m not mistaken.
I think syncing has long been a pain point for many Logseq users, but because the developers only have one business model right now, I don’t think its a pain point they have any interest in solving for free. With the other options available, though, this seems like a fair tradeoff.
FWIW, I use both Logseq and Joplin to meet different needs. I prefer Joplin’s way of handling sync, which reads directly from a sqlite database. But I also like having git version control for my Logseq graph, which not even the native sync function offers.
I had some of the same questions, especially about the backend code, and posted them here.
Below is what I wrote. What thoughts do you guys have?
I would love to be able to self-host the backend used for the sync server. I understand that the sync mechanism is still under development, but given that are there plans to release the backend source code?
I know that in the past there were requests for the backend source code; but at that time logseq used the backend very differently, AFAIR it operated as a host for logseq pages which were shown in a browser. At present, logseq uses local files, and syncs them via the backend code, all of which must be a very different backend from what existed back in early 2020.
The readme.md says almost at the very top that logseq “…focuses on privacy, longevity, and user control.” That link to the gnu free software philosophy page lists the four essential freedoms of software that is under user control, which includes “2. The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.”
In the past, there were plans to allow logseq to work with git, which eventually was done, and so it could be used completely with only free and open source code. But currently the ability to sync is a major part of the software, and access to the full syncing code (including the server portion) is a precondition for having the freedom to study and change how the program works.
So is the backend source code going to be released? There are a lot of people who have contributed time/code and money to this project thinking that it was solidly on the foundation of free and open source principles with full user control. If this is not the case, that’s a problem.
I know the tone of this sounds demanding; but I do want to also express my gratitude for all that each contributor has given. This is an amazing piece of software, and I hope to see it made better still as time goes on.
Logseq Sync is designed for scalability (millions of graphs) and performance, we used AWS lambda && gateway a lot, DynamoDB, Postgres, which are very complex and not designed for self-hosted.
We’re not going to open-source Logseq Sync for both business and the above reasons, but we plan to design a protocol for self-hosted usage so that the community can implement different solutions on top of it.
Thank you for the insights into the stack that you are preparing for the commercial Sync function.
This is a very good starting point! That concept already works well with Tailscale / Headscale and also with Bitwarden / Vaultwarden, so we can expect the availability of a useful, reengineered Sync services at some point.
we remain free and will only charge for pro services like sync, collaboration, and publish
In addition to syncing a local LogSeq graph, does the intention of releasing the protocol also hold true for the expected collaboration features? This would be a very fine move, and allow more sophisticated usage scenarios of LogSeq in the wild.
Many thanks for all the effort and constant improvement of the platform! I hope it pays off in the long run.
Now that Holochain is going into Alpha-RC version this week. It would be great for you to consider this distributed computing protocol. Sync and collaboration with no servers. Everything is self hosted on all the devices.
There are some very amazing demos of what Holochain can do from the core devs and some of the projects building on it. Happy to point you in that direction if someone is interested.
Apologies for bumping a fairly old thread, but now that Logseq Sync is pretty widely deployed, I was wondering if this protocol is described anywhere? If there aren’t any self-hostable sync implementations yet, I’d be happy to (attempt to) contribute one.
Theoretically, the only change required on Logseq itself would be a setting to override the default sync server URL.
Did you already start some works in this direction, and eventually documented parts of the API?
I suggest to spin off a separate discussion thread, as this one’s already quite aged, and to attempt identifying primary questions to be answered, until there is a community supported mimicry of the upstream Cloud infrastructure.
If I understood @tienson correctly, they are open towards voluntary reverse engineering efforts, which in return may support stabilising the interfaces in general. Why don’t we start the movement now and here right in the LogSeq community forum?
Hi @tienson, it’s been almost a year since the above comment. I think maybe what you meant is that the team plans to include some code in logseq clients that will let us choose our own server for a hosting solution? If so, that sounds great, and it’s one of the things that would make @GreenTeaRoll 's new project for building a self-hostable sync implementation much easier. One thing in particular that will be hard with the clients as they are is the iOS client, since if a fork of the client is needed to be able to use a self-hosted server, someone is going to have to publish that fork in the app store separate from the original logseq app, or else people will have to sideload it and refresh it in their iPhones every week to keep it current.
So, I guess what I’m saying is that I hope you’re still planning on doing this, and thanks!
This part is actually much easier than I was expecting, I think I can send them a PR to add this to the settings (Advanced settings?) page without much difficulty, assuming the team would be willing to accept such a PR. I had started working on that here, just need to wrap my head around Rum