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.
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.
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 pluginSampleModal
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!