辛宝Otto

辛宝Otto 的玄酒清谈

北漂前端程序员儿 / 探索新事物 / Web Worker 主播之一/内向话痨
xiaoyuzhou
email

What can we learn from the official XLOG Obsidian plugin?

image.png

In the previous section, the sync-to-xlog Obsidian plugin was mentioned. After communicating with the official team, it was discovered that the XLOG team is also maintaining a plugin, which is still in the early demo stage and is being validated. The goal is to have more powerful and complete functionality, and even obtain editing permissions.

So let's clone and run it.

I'm looking forward to what I can learn from the official plugin and see more system designs and usage of Crossbell/XLOG.

Usage Introduction#

More User-Friendly Login Authentication#

The settings page adds a login button to invoke a login page and obtain the related token. The experience is great and not hacky.

It turns out to be a standard JWT, and I also see many optimization points.

image.png

The above image shows a SettingsTab.

Web View Information Display#

A Robin Icon is registered on the left side, and when clicked, a web view expands on the right side to display basic information.

image.png

I want to edit, upload, download locally, and open XLOG web pages based on the description.

Source Code Analysis#

From the entry file, I can see:

  • AppPlugin: the core of the plugin
  • SampleModal
  • SettingsTab: the settings page
  • Registered status bar in the lower right corner
  • Custom icon
  • All web views are handwritten, which should be quite laborious
  • The API section maintains a Class Indexer
  • User login distinguishes between OP authorization and email authorization
    • Newbie's token belongs to email, so that's how it works!
    • Siwe's token belongs to wallet operations, which is my authorization scheme
    • It all makes sense now
  • The ribbon image is an SVG that is hardcoded and doesn't have any fancy technology
  • When mounting the web view on the right side, workspace.revealLeaf is used, which seems to be the usual way of losing focus
  • Command registration. A blank modal is registered
  • The settings page registers protocolHandler to facilitate token transmission, which is nice
  • Maintains a mapping-manager for local settings and remote post association, comparing them using simple slugs
  • Attempts to listen to relevant events of metadataCache

The web view here is handwritten, and my heart goes out to the author. This should be done using a framework, especially when I think about manually writing a for loop for the list, it's even more heart-wrenching... Fortunately, I have already mastered it.

Official Implementation Ideas#

Token#

The part of obtaining the token can be confirmed later. After all, it's all about getting the token, and it has the same effect as Siwe's token.

Retrieving XLOG Content#

Here, the Crossbell SDK is used, which should be more comfortable and secure.

When creating createIndexer, when is the token not carried? Then, only publicly readable ones can be obtained, which raises doubts about how to operate it.

Site information. Use indexer.character.get(charId) to obtain basic information on the homepage, and provide a fallback default avatar for the avatar part.

Get all posts using indexer.note.getMany.

That's it. There's nothing fancy.

When displaying IPFS, the website is hardcoded in the replace.

Uploading files uses the SDK, which should be a good reference.

Valuable Code Blocks#

// Manipulate frontmatter
this.plugin.app.fileManager.processFrontMatter

// Upload image to IPFS
import { ipfsUploadFile } from 'crossbell/ipfs'

export function uploadFile(file: File | Blob) {
	return ipfsUploadFile(file)
}

// Register protocol
this.plugin.registerObsidianProtocolHandler('xlog-login', async (data) => {}))

// Write HTML href like this
// obsidian://xlog-login?token=xxx&characterId=xx&type=op/

This article easily completes synchronization with the sync-to-xlog plugin!

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.