Replies: 10 comments 5 replies
-
|
I have also been working on an implementation of the backend. I have a working version along with modifications on rsapi and logseq itself
I will appreciate any feedback and I'm also to work on have the upstream changes pushed @andelf sorry for tagging you but I just wanted to be sure the devs are seeing it |
Beta Was this translation helpful? Give feedback.
-
|
It would be great if the devs could provide some kind of feedback on this 👍 Even if they don't want to take the time to do this, at least we would be aware of their plans! |
Beta Was this translation helpful? Give feedback.
-
|
Yes plz, Logseq team 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
I guess this thread is ignored purposefully. After all, the Sync feature is probably the only way of monetization available to the Logseq team, so obviously that's not too good for the team and for financing the project's future development. |
Beta Was this translation helpful? Give feedback.
-
|
because of the little interaction with the community, I switched back to obsidian and set up a self hosted livesync there, setup was a bit more difficult but now it works great. https://github.com/vrtmrz/obsidian-livesync |
Beta Was this translation helpful? Give feedback.
-
|
TLDR; User sovereignty and project sustainability must not be put into a position of conflict (and doesn't need to be) - please reconsider this issue. I am a happy user of Logseq and I support the project on Open Source Collective. I use the synchronization service, and I love the convenience, but I feel uncomfortable about the lack of a self-hosted synchronization option. I primarily love the tool for itself and I want it to be sustainable because it provides (and will hopefully continue to provide) an excellent extension for my brain. In contrast I think that tying the project's sustainability to me not being able to use the built-in synchronization feature for my own data on a server I control will a.) skew the incentives, b.) send a bad signal, and c.) reduce my long-term trust in the project. I won't be able to relax, and instead will be vigilant and open to alternative tools. However if Logseq enables a self-hosted synchronization option it will make me MUCH MORE LIKELY to recommend Logseq, continue to support the project financially, and to use the default synchronization service. Background: I am a maintainer of an open source project (also on Open Source Collective, albeit with a much smaller user community than Logseq) and I understand the sustainability struggle. We have always given as much autonomy and 'sovereignty' as possible to users of our open source product, because we believe that builds trust, and trust is the most valuable currency an open source project can have. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe a fork of LogSeq is in order if the devs refuse to engage with this. I understand wanting to make money but this isn't giving me confidence in them. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed, and I haven't really delved into it, but the decision to add a db vs. relying solely on text files (unless I misunderstand the plans) feels too close to lock-in for comfort. I suppose another option is just to have a recurring sync to git, and lock the UI until the sync is done after you've been idle for ___ minutes). I can't imagine that'd be too hard. And I recently started putting the web version in a Docker compose setup; I'll update here if I get it to a non-broken state. 🤝 |
Beta Was this translation helpful? Give feedback.
-
|
I wrote & use my own git auto sync a long time ago, & have loved having markdown files & their changes over time as such a clear source of truth. It's so clear to see what's happening, such a human friendly tool. I can write in logseq, push to GitHub, and coworkers can read my notes (albeit they kind of have to infer what my macros do but that's fine, it's pretty clear). I also sometimes write scripts that dump to markdown files, which is so convenient to do. I worry so much that the database-backed Logseq will convolute the situation irreparably for me & others. Plain files is such a wonderful user affordance, works well with git and shell scripts, is a whole damned universe common user addordances that databases winnow away. I do feel like this 🧵 is getting away from the discussion point here & further spiking an already heated topic. Are there any existing discussions on the markdown-files vs DB topic we should look at? Maybe start a discussion? |
Beta Was this translation helpful? Give feedback.
-
|
There's obviously a lot of strong feelings here, and for good reason. This would be something I'd like too (I paid for a cloud file sync utility on Android that works pretty well for me). But right now no one has opened any PRs. There's nothing really to discuss. Don't expect the devs to do this for you. If you actually care about this, do the work or pay someone else to. Open the PRs. Throw some 👍 's down. The case has been made, in a civil polite way, and further needless hammering on this point will just wear everyone down. |
Beta Was this translation helpful? Give feedback.
-
|
You should probably take a closer look at the first message in the discussion. The working version of the code under question is available in https://github.com/bcspragu/logseq-sync The only thing that stops it from happening seems to be the lack of devs' response, unfortunately :( It's quite obvious that no one should waste time if the results of the accomplished work would be ignored (just like this thread, probably?) |
Beta Was this translation helpful? Give feedback.
-
|
I would like to sponsor the merge of this feature. |
Beta Was this translation helpful? Give feedback.
-
|
Has there been any activity regarding this yet? Hard to believe we're approaching almost a year without any kind of straight answer. Speaks volumes. I think a fork is in order. |
Beta Was this translation helpful? Give feedback.
-
|
A 'fork' is already happening, with the team working on a db version, with a major impact on sync. So not sure whether a hard fork would make sense here until they share a release based on the db code-base. |
Beta Was this translation helpful? Give feedback.
-
|
We need a fork because people need a mark down based version which constantly is being updated with new features. I do not want to use db based logseq version for example. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello there!
I've been working on a self-hosted alternative to the official Logseq Sync backend (forum thread, repo). It's more or less functional at this point, but using it requires modifications to the Logseq codebase, mostly just changing hardcoded URLs in the core Logseq codebase as well as the
rsapipackage. To make it easier for folks to use, those URLs should be configurable, likely in some "Advanced Settings" pane somewhere (or perhaps where the proxy config settings live).I'm more than happy to make those changes, but I wanted to check with the Logseq team first to make sure that all sounds good and those changes would be well-received.
Beta Was this translation helpful? Give feedback.
All reactions