#What motivates me to not switch to the Logseq DB?

60 messages · Page 1 of 1 (latest)

magic sentinel
#

Hi!

I've been using Logseq for 3 years. I keep EVERYTHING in it: personal notes, work journals with clients, summaries, etc. I’ve developed several cool plugins (Full House Templates, Missing Commands, Shorten My Links) and adapted a popular theme (Bullet Journal Theme) to the modern version of Logseq. I've tried to contribute to Logseq's core a couple of PRs (the one was merged). And I've create ≈75 issues on GitHub while testing the application. So, I'm really familiar with all parts of the Logseq.

After observing the changes in Logseq DB, I realized that I won’t be upgrading to the new version and I won’t adapt the extensions I’ve developed. This is a difficult decision that has been growing inside me for a while.

The main reason: version 0.10.9 meets 90% of my needs. The missing 10% in Logseq DB will also not be met, and moreover, this ratio will worsen to 70% to 30%.

Next, I’ll try to reflect on what’s happening. This is, of course, pretty subjective and from my outside point of view. I don't know the inner discussion of the team.

I'm posting this here for discussion and in the hope of some changes.
Note: I’m writing this text in a respectful manner, but English is not my first language.

List of sources:

#

Cutting Functionality

I understand the transition to a database instead of text files, I understand the desire to enable collaboration and develop the product further, to add paid features, etc.

But I don't understand cutting existing features: splitting tags and refs; hierarchies
Note: I'm aware of the "Import all tags" checkbox during folder import in Logseq DB — this is not a solution

For existing users with a large notes database:

  • They'll have to change their workflow
    - Yes, you’re making the transition easy, and the new features are meant to replace the old approaches
    - But the cognitive cost of changing the familiar way of organising is very high
  • Or to stay on the old version: which means no updates anymore

For developers:

  • Part of the plugins relying on the removed functionality will no longer make any sense: these are wasted development efforts

Suggestion: don’t cut functionality at all — things just need to continue working as it was before (for any long-time user)

  • Return the hierarchies feature — those who need them can use them, and those who want to use Tags instead can configure them
  • Return the interchangeability of [[...]] and #...
  • Keeping all these function will help to respect users with it's own habits in notetaking and extension developers with it's already done work
#

An unexpectedly huge amount of work for developers

To ensure that themes and plugins continue to function properly, a lot of work is required:

  • Theme layout
  • Plugin adaptation
    - It's not just about using the API, but also conceptually. Some plugins are designed based on how Logseq works. A significant change to Logseq requires rethinking the existence of a specific plugin

Suggestion: Some of the problems could be solved with gradual changes, by releasing versions iteratively

  • Instead, the next version will be MASSIVE in terms of changes
  • For example, it would make sense to release a version that transitions from text files to a database and nothing else, WITHOUT adding new functionality
#

Defined by text behavior is broken

The text no longer unambiguously defines how the block is rendered. Previously, [[test]] always referred to a page "test", but now it could be a page, a property, or some node

Suggestion: The text of the block should unambiguously define the rendered result

  • So that copying the text and pasting it into a new block results in exactly the same block
  • So that modifying the block's content in the SQLite file via an external tool doesn’t cause issues
  • Some initial suggestions are here: #1274088597007634452 message
#

UX friction

The number of entities and it's settings has increased — the app has become complex and feature-heavy with drastically reduced UX.

Logseq is very geeky app for now. Quote that describes the situation well: "we lost the immediate simplicity." Source: #db-chat message

Suggestion: Please hire a good Product Designer / UX specialist

  • Engineers should not make decisions on how to design the product, as they are focused on a completely different aspect of development — it's is hard to collate two angles of view in one head
  • If the team already have such specialist, he must have the final word in any implementation
#

Cognitive overload aka "focus on power users"

The app has become flexible and multifunctional, but cognitively overwhelming

  • Refs and tags are now different
  • Different pages for refs, tags, properties, nodes, etc
  • Tagged Nodes in addition to Linked References
  • ...

Concepts have become more complex, and their configuration has become hard.

  • Thinking about how and what to do now takes a lot of effort.
  • People who already found Logseq difficult to use will now likely abandon it.
    • I recommended Logseq to many people (often those from humanitarian backgrounds) and I am familiar with all their challenges.
    • Now, overcoming these challenges will be impossible.
    • It’s now easier for me to recommend Obsidian, which isn’t my favorite, to these people — they’ll figure it out faster there.

Suggestion: Collapse app entities back: refs, tags, properties, nodes, etc.

  • The [[test]] should always lead to the same place.
  • Different types of entities can be distinguished via filters for Linked References.

Suggestion: Merge Tagged Nodes & Linked References — these features solve very similar problems

Suggestion: Product Designer

#

Unclear positioning due to AI: Logseq has lost its simplicity niche

When outlining was important, we chose between Logseq and Tana

  • Logseq won due to its free cost, local storage, and simplicity

When local storage / free access was important, we chose between Obsidian and Logseq

  • Logseq won because of its outlining capabilities and simplicity

Simplicity is no longer there, we are now getting complexity with Logseq DB and schema configuration, but...

  • Actually, this is not promising: the need for schema/class configurations is unnecessary, as AI is evolving and structured text is losing its advantages
  • The focus is shifting towards working with local text, but Logseq has moved away from this positioning
    • By removing file-based text
    • And focusing on schema/class configurations

Suggestion: Product Designer

#

Roadmap focus to meet my rest 10% of needs (and probably someone's else)

What I really need is bug fixes — and polishing existing features

  • This is what the entire forum, github, reddit, telegram, and discord are all shouting about
  • Not new features!

Key features that are missing for me:

  • Really reliable synchronization
  • Flexible publishing and sharing of notes (this is not even in roadmap)
  • Availability of plugins on mobile devices (this is not even in roadmap)
    • As a developer of extensions I'm really tired of people's argument: «I won't use any plugin, as it is not allowed in mobile»

Suggestion: Product Designer

faint tundra
#

don't have enough time right now to fully express thoughts, but agree 100% that db should be additive not subtractive from the user perspective. some features i think will have to change due to external factors, but having multiple simultaneous features disappear or fundamentally change in a single release is going to be a tough pill to swallow.

faint tundra
#

another program i use is archivebox, which is going through a similar refactoring currently, and the thing that impressed me most about how they've handled it is their roadmap.

https://github.com/ArchiveBox/ArchiveBox/wiki/Roadmap

i don't think a kanban board is a useful way to communicate goals or progress to people outside the development team. it just leads to the same question over and over again: "what's next?"

i think a very straight forward roadmap that allows users to calibrate their expectations, and also anchors development focus on delivering stable software in reasonable iterations, instead of chasing what's next constantly, would go a long ways. this roadmap needs to be accurate and reasonable.

by far my most used feature in logseq md was task management, and i find the current implementation of task management completely unworkable for any of my use cases. i understand it's not fully implemented, but i also do not have any sense of what a full implementation might even look like. based off the incomplete implementation, i have concerns it won't meet my needs.

GitHub
Roadmap

🗃 Open source self-hosted web archiving. Takes URLs/browser history/bookmarks/Pocket/Pinboard/etc., saves HTML, JS, PDFs, media, and more... - ArchiveBox/ArchiveBox

wise tangle
#

I see where you are coming from, and have expressed similar concerns regarding complexity and migration here as well, but for me the benefits far outweigh the costs. As long as I've used Logseq I've never been able to use the mobile app, and my big hope is that the DB version will solve that issue once and for all. This akibe should bring in a lot of new users for them.

I also think some of these issues will be worked out. I know they are still working on trying to make it easy for developers to switch and more work needs to be done there. Some of the UX complexity has already greatly improved in just the past month, and I know they are constantly working on this. (I agree though that they shouldn't have appropriated "tags" for the "new tags" feature, but should have introduced a new symbol and name. I've argued this many times before.)

So, if the MD version meets most of people's needs, I think the thing to do right now is just be patient about the fact that it is no longer being updated and wait and see a little longer before judging the DB version. I feel hopeful that they will eventually do more work to make migrating less painful. I'm giving my testing of the DB version a break for a few weeks (months?) until they do something to make it possible to import without losing my task workflows https://discord.com/channels/725182569297215569/1298107981463818293

I have to admit though that, out of impatience, I was looking again at some of the other options out there yesterday. Fortunately for Logseq, nobody else has done such a good job combining an outliner with a PKM ... at least not yet. And those core features which make it so attractive are still very much the same in the DB version.

faint tundra
#

#general message

a first impression in #general that speaks to some of the above concerns and ideas, specifically this one

Suggestion: Collapse app entities back: refs, tags, properties, nodes, etc.
The [[test]] should always lead to the same place.
Different types of entities can be distinguished via filters for Linked References.

void lichen
#

I think part of this may just be a communication issue.
I can't speak for the logseq team, but I can speak as a developer.
Sometimes the best way to find out how users should use something is just put all the pieces in front of them and see what they make of it. That's what I hope is happening right now with the db test, there are a lot of features being played with and it's not clear what will need refinement/what will need to be cut/what is currently just a bit leftover and needs removing.
Like for a while there we had page tags and tags in queries. Checking now there are only tags, as it should be.

I agree that having someone in a product design/UX type role that can also share plans/ideas with the community of testers would be a great addition. I think a lot of the valid disappointment here could be entirely cleared up if it was more clear what parts of the DB version are "at or close to their final form" and what are "in a state of experimental flux". I worry that a lot of the critique comes from confusion about what is what.

#

As for the features I mostly think they are a great addition. The UX is a little clunky but logseq MD was a tool I used for a while but never was entirely sold on. Logseq db from my perspective has many more of the underlying features I want .

Personally my main issue is syncing and performance. But I accept they will both come later. Though the current performance is quite concerning to me. Performance is certainly possible to improve later, but if it's ignored too much improving it can be very painful and require significant overhauls.

faint tundra
#

i am still daily driving the db version, tbh just because it is what feels most comfortable to me to use. so that's a positive sign. i agree the main gap is just communication and i guess context. if this is alpha, the implication is that once the bugs are worked through, it'll move on to beta. if that's the case, i think reading into the current feature set is at least a bit appropriate as far as them representing the end goal. if this is more of an extended r+d phase while the refactoring is done, then reading too much into the current feature set doesn't make as much sense. it seems like a lot of the focus has shifted to closing the feature gaps between md and db, which i think is definitely a good thing, especially as more and more users are testing out the db test versions for themselves. it's possible a lot of the concerns will be mooted with time. there just kinda needs to be some sort of method of communicating the right expectations.

wise tangle
# void lichen As for the features I mostly think they are a great addition. The UX is a little...

Their business plan is based on delivering "real time collaboration" for teams. With this in mind, I imagine that performance and sync are their top priorities - and the main reason for the update as well. They've already improved this aby about 900% since they launched the alpha, and I imagine they will continue to do so. From what they've said, it seems like a lot of the issues with performance are due to the UX and not the underlying architecture.

void lichen
wise tangle
void lichen
#

In that case I'd agree. That was what I was talking about. The way you architect your react UI can have a big impact on performance/ spurious re-rendering (which is normally the issue).
It can be a very difficult hole to dig yourself out of.

distant vigil
#

Logseq is currently working on the database version, which is far from what I expected.

I remember that tienson specifically explained the reason for using markdown in a podcast.

I use Logseq because it uses the markdown text format.

In the worst case, the Logseq markdown version is no longer updated, and only version 0.10.9 can be used, which I think should be OK.

I haven't encountered serious bugs in the past six months.

The real problem is that the more heavily you use Logseq, the harder it is to migrate to the database version.

Well, I'm using beta features, so it's normal that it can't be used normally anymore.

I once asked the Logseq team for regular bug fixes, but they rejected my request because there was a lot of work to be done on the database version.

Thank you, stdword, you are very brave and you said what I wanted to say.

wise tangle
wise tangle
#

I still think that it would greatly simplify migration for existing users (especially those who aren't computer programmers) if they

(1) didn't use the "#" symbol for "new tags"
(2) didn't use the word "tags" to describe them
(3) made the experience of converting tags or pages to "new tags" after import much better, so people didn't have to make decisions based on a system they don't (yet) understand.

The point is that this is something completely new. It should be treated like that, and people should be given time to learn and adapt their workflows, not be shoehorned into something different from what they are used to.

#

@maiden frigate

#

Now that I understand what "new tags" are and am beginning to grasp how they work (after playing with them for several weeks), I am excited about the possibilities. But I think it is important to understand how complicated and counterintuitive much of this is at first. Especially for non-programmers.

#

I also think it would be good to bring in more people who don't have a programming background to participate in the alpha.

wise tangle
#

The difference between:

(A) We have a neat new feature called "logsets" (or whatever) that gives you new powers to make database-like tables in Logseq. Give it a try.

and

(B) All your existing tags, which you were using for your own workflows, are now something else that works entirely differently. Yes or no?

faint tundra
# 
{:block/uuid #uuid "00000002-2737-8382-7000-000000000000",
 :block/updated-at 1725755846256,
 :block.temp/fully-loaded? true,
 :block.debug/properties
 {:block/updated-at 1725755846256,
  :block/created-at 1725755846256,
  :logseq.property/built-in? true,
  :block/title "Root tag",
  :block/type "class"},
 :block/created-at 1725755846256,
 :logseq.property/built-in? true,
 :block/format :markdown,
 :block/title "Root tag",
 :db/id 4,
 :db/ident :logseq.class/Root,
 :block/type "class", 
 :block/name "root tag"}

👁️ what is a "class" block type LMAO

maybe it'd make sense to just have a q+a for the alpha testers at some point?

#

i think..... pages and wikilinks being interchangeable and new tags being an evolution of tags doesn't need to be as cognitively dissonant as it is, but either pages and tags need to be re-combined as a single node type, or it needs to not replace tags the way they worked in markdown and just be its own new feature. there's no reason to hard code breaking changes in.

maiden frigate
maiden frigate
maiden frigate
maiden frigate
# distant vigil Logseq is currently working on the database version, which is far from what I ex...

It's not that we "rejected" your request, it's just that we can't focus on bug fixes while also rewriting the app. Even before starting on Logseq DB, we/the devs had trouble keeping up with the amount of issues created on GitHub. If we had the resources (people, time) to roll out bug fixes of Logseq MD, we'd do that.

Also, Logseq DB will be in the exact same build as Logseq MD and Logseq Org. So we're not going to abandon anything. If you don't want to use Logseq DB, you can just switch your format of the app to Markdown like you can now choose between MD and Org.

#

You've probably read this post already, but here Tienson explains why he changed his mind on Markdown and Org in Logseq for certain use cases. The thing is, for Logseq to be anything more than a hobby project we need to tackle those use cases (mainly reliable storage and sync, collaboration, support more powerful/automated workflows): https://discuss.logseq.com/t/why-the-database-version-and-how-its-going/26744

crimson abyss
neon elk
#

Hey, i am worried that the team is currently working on the following (@Ramses, please correct me!):

  1. Rewrite the app with a new backend
  2. Rewrite the (fantastic!) Logseq built-in features (e.g. flash cards) with the new backend
  3. Introduce new DB-based features (that require new interface paradigms! That break people's workflows!)
  4. Real time collaboration
  5. … all while maintaining backwards compatibility with the file-based version

I'd love it if you prove me wrong, but from my experience in building software this seems like a project that will never get released (i have been part of a few of those!).

**1. **is set, pick another and ship it.

(btw: All i want is a better mobile app.)

wise tangle
faint tundra
#

it's definitely a rock and a hard place situation. i don't think all this work is being done just in the pursuit of More ™️, but the lack of a more detailed roadmap at this stage i'd be lying if i didn't say i think it's a bit of a red flag. i'm basically treating the markdown version as "proof of concept"—and the db version as a necessary stepping stone towards logseq being a long term maintainable project. but without a roadmap, who's to say at what point the db version stops being proof of concept as well? i've changed a lot of my approach to note-taking since switching over to the db version. i generally enjoy that kind of friction so it has been positive for me, but most people want a note-taking platform to get out of their way shortly after adopting it. because of that, i think a very long gestation period for the db version is 100% the call, but i think if i didn't already use logseq and i came across the website today i would assume it's an abandoned project and look for something else, and that's such an easy fix. a roadmap and some simple communication can go a long way.

crimson abyss
#

I'm going to be a bit harsh here, with my experience being scrum master and devops engineer at enterprises.

My current take is that Logseq the company isn't getting managed and I see the hallmarks of that. When management doesn't set a clear goal and keeps people on track then eventually everyone will do "what's best" and while there's lots of work getting done you will never reach the end goal or anything that really moves the dial. Keep that up long enough and the teams working on a project will start to perform less because the win of a release is needed to keep momentum going.

Now in practice you have 2 methods of building, incremental or big release and hate to break it to the developers, that requires some planning.

Logseq as a company luckily isn't that big it's needs a 2 day PI planning session that every engineer hates with a passion of a thousand sounds. But what it does need is a couple of 1 hour sessions to collect goal, milestones and maybe an MVP

Once that's done, if I had to pick I would go for incremental. Get smallest part setup to have a public beta. Explain that it won't have all the features yet but it's there for people that can live without and make a frequent release.

@maiden frigate I'm going to go out on a limb here, but when I talked milestones you told me it wasn't a straight line. That's developers that don't want to commit.

And even further out on a limb and make this an open application to join the team and help out. If you think that would help let me know and I'll write an official open application.

maiden frigate
# crimson abyss I'm going to be a bit harsh here, with my experience being scrum master and devo...

Thank you for the open and honest feedback, Bas. You know I always appreciate your direct feedback and share it all with the team.

I can't comment much on the dev processes, but I've shared your offer with @gusty yacht. You're not the first to offer it, though.

As for communication with the community: that falls squarely on my shoulders. But we're working on a better way that not only informs the community, but will also make it easier for me to summarize what we've built (and will build) in blog updates.

In a nutshell, we're close to testing RTC and Tienson will start a daily dev log which will be publicly accessible, and will work much like docs.logseq.com. He's also going to ask the other engineers to keep a dev log. This will help me a ton to write the updates as I don't have to trawl through GitHub issues and code changes (much of which I don't understand anyway).

crimson abyss
maiden frigate
proper terrace
proper terrace
# magic sentinel # Unclear positioning due to AI: Logseq has lost its simplicity niche When outl...

I cannot agree with this point more. AI has to be a first class citizen here. In addition to plugins, there should be a mechanism for developers to integrate custom AI agents with Logseq. Because of its outlining first and local first principles, AI is very well suited here. Imaging integrating Logseq with other tools that people use for managing knowledge. I personally use Readwise (and its Reader to import all my twitter highlights, kindle highlights, medium and substack articles) in addition to Zotero as a reference manager and reading papers and books.

maiden frigate
#

Unless the model is fully local (which the team has explored, but does not have the resources to build out more at this moment), privacy isn't respected by most AI tools due to the nature of training their models.

proper terrace
# maiden frigate Unless the model is fully local (which the team has explored, but does not have ...

I'm actively working in the AI/ML domain. The trajectory is leading toward having more and more capable AI models and agents on edge devices and locally. If Logseq wants to target a future that is not focused on only the next 6 months, it can start by providing mechanisms/intefaces/tooling that people can build agents and integrate them with Logseq workflows. Initially, those agents will probably call a remote API but what Logseq will gain is 1-exploring the whole AI agents area done by the community 2-improving its native AI integration. A lot of initiatives and startups have taken this path. As an example, Quivr can be built completely locally or one can use the hosted version of Quivr. The important thing is the community that is being built around the platform that Quivr and a bunch of other startups/open-source-repos provide.

GitHub
GitHub - QuivrHQ/quivr: Opiniated RAG for integrating GenAI in your...

Opiniated RAG for integrating GenAI in your apps 🧠 Focus on your product rather than the RAG. Easy integration in existing products with customisation! Any LLM: GPT4, Groq, Llama. Any Vectorstor...

proper terrace
# proper terrace I'm actively working in the AI/ML domain. The trajectory is leading toward havin...

LogSeq data is super useful for AI native integration. People who use Logseq use it for its unique set of features (outlining, backlinks, tags, templates, journals) to build a knowledge graph. The data collected based on using these features is very rich compared to raw text that LLMs are trained on. It's much more cleaner, its already filtered for a particular user's use case, chunking it to feed to LLM is a lot more straightforward, finetuning tasks are more clear (setting a plan, reminders and tasks for today, connecting notes on external content based on metadata available in logseq, authorship prediction, custom-built text summarizations), and human feedback from user is baked in for PEFT methods for finetuning. There is a sea of potential here, waiting until you can run a local model is an obvious missed opportunity. Local very capable models are around the corner

proper terrace
hybrid delta
#

I'm open to AI in Logseq only if it's disabled by default, and preferably only as a plugin. Not interested in sharing any portion of my private notes with an LLM or other third party. I haven't explored MacOS's incremental AI capabilities yet (still not particularly interested), but I imagine perhaps there's some potential of Logseq enabling AI features of their OS.

void lichen
#

Coming from another perspective I have absolutely 0 interest in ai in my notes app.
I use it constantly as a developer, (cursor, and recently windsurf) but I just can't imagine it being of any use when writing content that is specifically supposed to be my own thoughts.

I don't use AI to write good code and I won't use ai to write high quality notes.
It's great for vomiting out vaguely useful slop, but I have yet to see anything beyond that 😅

lilac plover
#

I'm not a co-religionist of any movement, so I'm curious about users like me who use Logseq primarily for PKM, project management, and taking notes, but who also use various LLMs, LLM routers, etc., to expand their notes, thoughts, parsing data, stress-testing my ideas, and long-form texts, etc. Logseq is mostly used for data enrichment and storage, but all of the latter activities that genAI helps with are outside of it. Does that seem like a solid approach, or is it merely "temporary" until Logseq is updated to include those typical, genAI-driven operations as well? Where is the Logseq DB, the topic of this thread, located in this conversation?

#

I have identified 3 types of current users: 1) Those who are obsessed with cloud-dettached local files. 2) Those who need the cloud capabilities but just want to keep the source of data on a local storage (call it an archive, future-proof, or just cloud safety as long as you have a robust local backup strategy, too). 3) Those who are 100% cloud beasts, no matter what. Do you think that Logseq MD and/or Logseq DB users fit mostly in one of those 3 categories?

maiden frigate
# proper terrace I'm not trying to be pessimistic here but I believe Logseq without AI integratio...

Sorry, but I don't agree. We're in the middle of the hype cycle of AI. A few years ago, some team members and community contributors wanted Logseq to incorporate web3 elements. I'm so happy we didn't step on that hype train as it fizzled out because of the scammy nature of so many web3 projects. Similarly, lots of AI tools are super privacy-intrusive and that would not land well with the type of person we're serving with Logseq. People who want AI out of the box have enough other tools to choose from.

I think what we need to do as a team is to provide amazing APIs so that people can build their own AI plugins on top of their Logseq data—but without shoving it down everybody's throats. As you can see from some of the replies here, many aren't interested in mixing their Logseq notes with AI. So consider the flip side: how many people would be turned off by Logseq if it would ship with AI capabilities?

abstract flume
#

I guess the real question is how far are we from getting friendly dedicated desktop and modile AI tools that can read and write our data vs how much it takes to develop a native solution that could potentially become obsolete very fast...

maiden frigate
#

You also have to consider the size and expertise of the team. AI would be a gigantic distraction at this point and set the devs back many months as they need to learn about LLMs. Only to jump on a hype train? Nah, I think they're smart for not going for AI at this moment and leave it up to the community (by providing better APIs)

proper terrace
# maiden frigate You also have to consider the size and expertise of the team. AI would be a giga...

I have backed logseq since its very early days and was among the first handful of people who tried to push the company I was with to allow using it on work computers (early logseq people may remember). Main reasons: focus on privacy, being local and being an outliner. It made it very easy for to collect and organize my thoughts and connect and track them to my research.

I don't think we are in disagreement over how logseq should approach AI capabilities. In my earlier comment I said " it can start by providing mechanisms/interfaces/tooling that people can build agents and integrate them with Logseq workflows." You call that API and that is fine. I used "mechanisms/interfaces/tooling" to draw an analogy between the existing plugin lingo that loqseq uses.

I however, disagree with calling the AI progress over the past 10 years a hype. For any promising new technology, there are going to be a lot of grifters and they need the hype to operate. As someone deeply and professionally involved with NLP, computer vision, and other applications of machine learning at a very large scale, I follow long-standing patterns. Do I believe AGI is few years ahead, absolutely not. But I know nothing and I mean almost surely nothing is done in machine learning the way it used to be done 10 years ago.

What I asking is: Be open to the possibilities of AI and make it easier for the community to experiment with it on their logseq graph.

abstract flume
# maiden frigate We want to monetize with services, so blocking API access for local plugins goes...

to clarify : I'm NOT advocating to block access to plugins or API behind a paywall, I'm saying SOME official plugins COULD be paid (just like Sync is a service, native AI could be another paid service).

also any cloud service is by definition antinomic with "the spirit of local-first and privacy", that includes Sync performed via a third-party server, so I don't see why cloud AI is more suspicious than Sync in that regard.

the team expertise and focus is a most definitely a valid point and I don't think native AI should be a priority on the roadmap. (also the analogy between web3 and LLM seems a bit contrieved of misinformed imo)

maiden frigate
# abstract flume to clarify : I'm NOT advocating to block access to plugins or API behind a paywa...

I don’t see how we could guarantee privacy with an LLM (unless it’s a local model) the same way we can guarantee privacy with a sync service that’s completely encrypted. So IMO you can’t compare the two, if we’re talking about remote AI at least.

As for the analogy between web3 and AI: all I’m saying is that AI is in a gigantic hype cycle like web3, and that we’re getting similar suggestions as back then. But ultimately I don’t decide about what features get added or not, I’m just sharing why I believe the devs don’t want to burn their fingers on native AI integration in Logseq at this moment