Why not a plugin?

[gaurishhs]

Hi!

Is it possible to have this as a plugin for Logseq instead of a self-hosted server. I think this could reduce the complexity of manipulation of Logseq application itself. Something like a S3 Sync plugin where the user could configure the S3 credentials and the syncing could happen in background. This could also be a solution for users who do not want to self-host.

I'm opening this as an issue since Discussions is disabled.

[bcspragu]

(thanks for the heads up on Discussions being disabled, enabling and moving there)

[gaurishhs]

One downside i can think of rn is: No plugins for Android/iOS but they do seem to have plans for it.

[bcspragu]

Okay, now a real answer: This is an excellent idea (with the caveat you noted of mobile use), and is theoretically totally possible (albeit with some devils in the details). Most of my work + projects are cloud-y backend things, so I gravitate towards cloud-y backend solutions. As far as how to implement this as a plugin:

1. Package the Go code (via wasm? GopherJS?) as a JS blob for inclusion in the plugin
2. Add some wrapper/glue code to make it a plugin

Now, the devils in the details:

• Can one run a server (e.g. on localhost) from within a Logseq plugin?
• Does the current code use anything that can't be JS-ified (either via wasm or other)?
• What other nuances are there? E.g. around TLS handling, communicating with S3 or some S3-equivalent, local storage, encryption, etc

My exposure to the Logseq Plugin API is mostly through its HTTP-based interface in my logseq-ui project, a GTD-inspired TUI task management app backed by Logseq, so I'm not actually confident what capabilities one can expose/leverage in a plugin.

[gaurishhs]

Logseq seems to have a native JavaScript API¹ so i would argue for the plugin being a wasm wrapper unless you have a good reason for it. What i meant was the user could just enter the S3 URI which the plugin could connect to and sync directly with encryption which would probably eliminate the need for an HTTP server.
You could probably utilize MinIO's own² S3 client or AWS

Footnotes

1. https://github.com/logseq/logseq-plugin-samples ↩

2. https://www.npmjs.com/package/minio ↩

[gaurishhs]

I haven't gone through the source yet but what i think is if we could encrypt the file using a key (set by the user) and retrieve using the same key that would be fine. The keys and checksums for each file could be stored in logseq.DB Please correct me if this is wrong.

[bcspragu]

I'm not sure I understand your comment (e.g encrypt what file? what keys? what checksums?), but the way the sync protocol currently works is roughly:

1. Logseq client creates a graph (doc link)
2. Logseq client generates a key pair, encrypts the private key with their passphrase, and uploads that encrypted key pair (rsapi code for passphrase-based encryption, upload endpoint doc link)
3. Logseq client uses the generated key pair (in some way, not sure of the details) to encrypt Markdown files, which it then uploads to S3 using credentials it received from the Sync Server (doc link)

None of those things can be changed without changing the sync protocol itself, so any client-side plugin needs to implement the server-side of that exchange. All of the cryptographic bits (key generation, age-based passphrase encryption, etc) are handled on the client, the sync protocol itself doesn't really have any cryptography except perhaps verifying file checksums.

[gaurishhs]

I get it now, What i meant was utilizing the local file storage and uploading the markdown after encryption to S3 and loading the same on other devices