4 ms·

Logseq – adding settings for self-hosted sync

35 points by jerrygenser 2y ago

Zambyte 2y ago
To me this both sounds perfectly reasonable for the Logseq developers to ignore, and for a fork to be made to add it.
- byefruit 2y ago
  100% agree. If users want to remove a feature that funds maintenance and development of the project then they should really just fork it.
  - Zambyte 2y ago
    In this case they would be adding a feature that complements the feature they depend on for funding with one that would be free to use, rather than removing anything.
TechDebtDevin 2y ago
Been using Syncthing with graphs forever now. Probably will continue using that.
- bachmeier 2y ago
  Edit: Not sure why I posted this as a comment on someone else's post, but I'll leave it since it's here. I haven't followed Logseq much since they announced the move to a database. I liked the idea when it was a regular open source project. They've taken a considerable amount of money from outside, they're moving from plain text files to a database, and they're planning to monetize by selling sync features. We've been down this road, I don't know, maybe a few thousand times before. We know how this story ends. Heck, we could write the blog posts and the defensive comments about sustainability, running a business, and all that jazz right now. (This comment is not a request for a lecture on how business models work. I understand how they work, and that's the point of my comment.)
  - brunoqc 2y ago
    > they're moving from plain text files to a database I wonder if a database is required for CRDTs. I don't know if logseq use that, but if we had a FOSS note-taking app with CRDTs, we might have to give up the text format.
    - mweidner 2y ago
      You can store a text-editing CRDT's state in a standalone file instead of in a database. However, it is hard to make the file human-legible or updateable. The best you could do is probably something like a piece table (https://en.wikipedia.org/wiki/Piece_table https://en.wikipedia.org/wiki/Piece_table), or the plain text followed by some opaque CRDT metadata. If you want to preserve the ability to edit plain text files using an arbitrary program, your sync engine could be a file watcher that computes a diff each time the file is saved - like git does, but character-based instead of line-based.
deleted 2y ago
[deleted]
cube2222 2y ago
I really like Logseq, and I feel it's the only one of the note-taking tools that has the tradeoffs I want (outliner, local-first, focuses on content on a block-by-block basis, has backlinks), and I always keep coming back to it, but recently there's been not much happening, and the mobile app has been slightly broken for me for a while now (when opening a note I often can't add new bullet points, so I end up writing notes in an invalid format). I'm really looking forward to their db-oriented version which is supposed to be merged into main (here's the long-lived branch[0]) this month. Presumably that will bring the project back up to speed, since that branch is currently almost 4k (!!!) commits ahead of main. At the same time, I'm a bit worried about how the company is gonna sustain itself. After all they raised quite a bit of money ($4M 2y ago), while at the same time I'm not sure how large a market there is for commercialisation of an open-source PKM app like this. Esp. since it looks like its market-share is maybe ~1/10th that of Obsidian (based on most popular plugin download counts). TFA is kind of related to this. While Obsidian is great from a sustainability perspective (it seems to me), it unfortunately comes short of being a good outliner. [0]: https://github.com/logseq/logseq/tree/feat/db https://github.com/logseq/logseq/tree/feat/db
- jauntywundrkind 2y ago
  Oh frell. As a user who loves shell scripting, version control, and alternative options, i hate hate hate DB-based datastores. I won't have git auto-commits, showing me over time how I edit logseq. I check in work-notes, which are markdown files that can be viewed easily in GitHub right nkw. I also use file sync tools to keep tablet, phone, and laptop in sync: these can handle resync after online if I'm not working on the same files. Going to a database will blow all this sync up, will go from an open conventional malleable extropic system to something esoteric & cloaked, turn us away from the external & push us internal. This will be awful, I'm so striken to hear this. DBs are just so awful, such a thing programmers love but which abridges the shareability of the system with users. We already have a great key value system, and it's one that has amazing universal tools around it: the file system. DBs have advantages for querying, so it's fine if you want to project your filesystem's contents into a database, but man, files are just so much more user-friendly, user-empowering. The 9p dream is real, everything is a (simple) file is still the untried win that can bridge the dev-user computing gulf. There was a recent submission, File As Metadata Format, that talked to this all, was so good to see, https://prma.dev/posts/files-as-metadata-format https://prma.dev/posts/files-as-metadata-format https://news.ycombinator.com/item?id=40890902 https://news.ycombinator.com/item?id=40890902 I love logseq but this is an app in trouble for sure. It's a huge sprawling Clojure project. That's enormously powerful, but trying to wrestle with that internal complexity is so hard. There's such a huge backlog of open issues. The community loves the product, but there are seemingly so few who have deep knowledge, who can answer questions or improve things or help. Regarding the Android version, if you tap away from a line, tap back on it, tap away again, and tap on it again the "dot" shows up. It seems to be a visual bug only for me; I can use the "next line" toolbar option to get a new line as usual, navigate around as usual, but yeah it's way harder to navigate & browse since the dots all disappeared two or three months ago.

35 points by jerrygenser 2y ago

Zambyte 2y ago

To me this both sounds perfectly reasonable for the Logseq developers to ignore, and for a fork to be made to add it.

byefruit 2y ago
100% agree. If users want to remove a feature that funds maintenance and development of the project then they should really just fork it.
- Zambyte 2y ago
  In this case they would be adding a feature that complements the feature they depend on for funding with one that would be free to use, rather than removing anything.

TechDebtDevin 2y ago

Been using Syncthing with graphs forever now. Probably will continue using that.

bachmeier 2y ago
Edit: Not sure why I posted this as a comment on someone else's post, but I'll leave it since it's here. I haven't followed Logseq much since they announced the move to a database. I liked the idea when it was a regular open source project. They've taken a considerable amount of money from outside, they're moving from plain text files to a database, and they're planning to monetize by selling sync features. We've been down this road, I don't know, maybe a few thousand times before. We know how this story ends. Heck, we could write the blog posts and the defensive comments about sustainability, running a business, and all that jazz right now. (This comment is not a request for a lecture on how business models work. I understand how they work, and that's the point of my comment.)
- brunoqc 2y ago
  > they're moving from plain text files to a database I wonder if a database is required for CRDTs. I don't know if logseq use that, but if we had a FOSS note-taking app with CRDTs, we might have to give up the text format.
  - mweidner 2y ago
    You can store a text-editing CRDT's state in a standalone file instead of in a database. However, it is hard to make the file human-legible or updateable. The best you could do is probably something like a piece table (https://en.wikipedia.org/wiki/Piece_table https://en.wikipedia.org/wiki/Piece_table), or the plain text followed by some opaque CRDT metadata. If you want to preserve the ability to edit plain text files using an arbitrary program, your sync engine could be a file watcher that computes a diff each time the file is saved - like git does, but character-based instead of line-based.

deleted 2y ago

[deleted]

cube2222 2y ago

I really like Logseq, and I feel it's the only one of the note-taking tools that has the tradeoffs I want (outliner, local-first, focuses on content on a block-by-block basis, has backlinks), and I always keep coming back to it, but recently there's been not much happening, and the mobile app has been slightly broken for me for a while now (when opening a note I often can't add new bullet points, so I end up writing notes in an invalid format). I'm really looking forward to their db-oriented version which is supposed to be merged into main (here's the long-lived branch[0]) this month. Presumably that will bring the project back up to speed, since that branch is currently almost 4k (!!!) commits ahead of main. At the same time, I'm a bit worried about how the company is gonna sustain itself. After all they raised quite a bit of money ($4M 2y ago), while at the same time I'm not sure how large a market there is for commercialisation of an open-source PKM app like this. Esp. since it looks like its market-share is maybe ~1/10th that of Obsidian (based on most popular plugin download counts). TFA is kind of related to this. While Obsidian is great from a sustainability perspective (it seems to me), it unfortunately comes short of being a good outliner. [0]: https://github.com/logseq/logseq/tree/feat/db https://github.com/logseq/logseq/tree/feat/db

jauntywundrkind 2y ago
Oh frell. As a user who loves shell scripting, version control, and alternative options, i hate hate hate DB-based datastores. I won't have git auto-commits, showing me over time how I edit logseq. I check in work-notes, which are markdown files that can be viewed easily in GitHub right nkw. I also use file sync tools to keep tablet, phone, and laptop in sync: these can handle resync after online if I'm not working on the same files. Going to a database will blow all this sync up, will go from an open conventional malleable extropic system to something esoteric & cloaked, turn us away from the external & push us internal. This will be awful, I'm so striken to hear this. DBs are just so awful, such a thing programmers love but which abridges the shareability of the system with users. We already have a great key value system, and it's one that has amazing universal tools around it: the file system. DBs have advantages for querying, so it's fine if you want to project your filesystem's contents into a database, but man, files are just so much more user-friendly, user-empowering. The 9p dream is real, everything is a (simple) file is still the untried win that can bridge the dev-user computing gulf. There was a recent submission, File As Metadata Format, that talked to this all, was so good to see, https://prma.dev/posts/files-as-metadata-format https://prma.dev/posts/files-as-metadata-format https://news.ycombinator.com/item?id=40890902 https://news.ycombinator.com/item?id=40890902 I love logseq but this is an app in trouble for sure. It's a huge sprawling Clojure project. That's enormously powerful, but trying to wrestle with that internal complexity is so hard. There's such a huge backlog of open issues. The community loves the product, but there are seemingly so few who have deep knowledge, who can answer questions or improve things or help. Regarding the Android version, if you tap away from a line, tap back on it, tap away again, and tap on it again the "dot" shows up. It seems to be a visual bug only for me; I can use the "next line" toolbar option to get a new line as usual, navigate around as usual, but yeah it's way harder to navigate & browse since the dots all disappeared two or three months ago.