Logseq desktop OG - LDAP Plugin

Hi everyone,

I’ve built a small demonstrator plugin that syncs LDAP attribute values (e.g. e‑mail, phone numbers) directly into Logseq Markdown text. The idea is that once synced, the values are plain text/links in your graph, so they stay visible on every platform – including mobile, where plugins don’t run.

How it works

  • A slash command /ldap > LDAP Sync reads ldap-server:: and ldap-filter:: from the current page’s properties.

  • It loads a substitution table from a server configuration page (Label → LDAP attribute/OID → output format).

  • Because Logseq plugins live in a sandbox and cannot open raw TCP sockets, a local Node proxy (proxy/ldap-proxy.js) handles the actual LDAP connection.

  • The plugin then replaces placeholders like E-Mail: '' with the returned values, formatted as text, mailto: links, or tel: anchors.

Current state

This is intentionally a demonstrator / prototype. A large part of the code was generated to test implementation approaches, and a proper review or rewrite will follow once the design feels solid. So far it supports:

  • single-page sync via /ldap

  • text, mailto, tel formats

  • multiple LDAP server credentials in plugin settings

  • ldap-synced:: timestamp on synced pages

Why I’m posting

Before I invest more time in a rewrite, I’d love to get your take on the overall design:

  • Does the local-proxy architecture feel acceptable, or is the setup too cumbersome?

    • As far as i know there is no way to integrate that in the marketplace and the user have to install it by himself.
  • Is the “server config page + substitution table” approach usable?

  • Are there edge cases or Logseq constraints I should handle differently?

    • Are there better approaches?
    • Is there another PlugIn which fits better and the logic can be used.
  • Any feedback on security, UX, or mobile behaviour?

    • The proxy is not accessible from the outside, yet communication between Logseq and the proxy remains unencrypted.
    • Implementing a security layer does not appear to be feasible.
    • The password for the bind user is stored in plain text within Logseq.

The full README, ADRs, and source are in the repo

Looking forward to your thoughts!