Maskbook Plugins System Brainstorming

[neruthes]

In #10, we discussed the idea "applet" briefly.

Today, I have started drafting the concept of Maskbook Plugins.

https://confluence.dimension.chat/x/9IAf

Looking forward to more ideas.

[Tedko]

Some feedback from our community:

[Jack-Works]

1. The DNS + IPFS way is strange, does anyone will use it?
2. The GitHub way is also strange in the format "_github.${username}.${repo}". IMO github://username/repo is better.
3. /maskbook-plugin.dist.js is bad. Prefer to use a config file to point to the script. e.g. .maskbook/plugins.json
4. Why limit to a single ECMAScript file? Developers should be able to use ES Module to load files.

[neruthes]

• The DNS + IPFS way is strange, does anyone will use it?

DNS provides a package name authentication mechanism so we do not maintain our own package name registration store.

IPFS can help the people of DPRK and Iran to mitigate US sanctions.

• The GitHub way is also strange in the format "_github.${username}.${repo}". IMO github://username/repo is better.

This solution was designed for embedding GitHub repo identifier inside a valid package name string (like Java). Package name is an established software identification format and I find no necessity to bypass it. It helps avoiding duplicates and is a good compatibility preparation for package management systems (like NPM, APT, and YUM).

• /maskbook-plugin.dist.js is bad. Prefer to use a config file to point to the script. e.g. .maskbook/plugins.json
• Why limit to a single ECMAScript file? Developers should be able to use ES Module to load files.

One IPSF URI can only store one file, supposedly. I do not want to let developers do pre-commit GZ compression or let Maskbook do realtime GZ extraction. Future methods of distribution may impose other restrictions so I suppose that we should make it single-file from the beginning.

[Jack-Works]

This solution was designed for embedding GitHub repo identifier inside a valid package name string (like Java).

Use a "special" URL to represent a unique software source is somehow like use an empty string to represent null. The problem here is that by using this way, you cannot represent the real "_github." domain anymore.

IMO the npm way is better, they provide different resolutions to dependencies e.g. "ssh://", "git://", "https://" etc.

One IPSF URI can only store one file, supposedly.

Therefore the limit only should be happened at IPFS resolution. No hardcoding filename on git repo

[neruthes]

This solution was designed for embedding GitHub repo identifier inside a valid package name string (like Java).
Use a "special" URL to represent a unique software source is somehow like use an empty string to represent null. The problem here is that by using this way, you cannot represent the real "_github." domain anymore.
IMO the npm way is better, they provide different resolutions to dependencies e.g. "ssh://", "git://", "https://" etc.

In that sense, we can use the following methods:

• maskbookplugin:git+https://github.com/username/repo.git
• maskbookplugin:dns:ipfs://

However, I do have concerns over whether it is filename-safe. When interoperating with a filesystem, I wish that each plugin file/directory can map to its Plugin Identification Code (PIC) without any dedicated catalog file. Introducing characters like colon and slash will complicate this matter.

One IPSF URI can only store one file, supposedly.
Therefore the limit only should be happened at IPFS resolution. No hardcoding filename on git repo

Method-specific distribution wrapping can be dangerous because it introduces trivialization. There is no guarantee that distribution methods will limit to the currently listed 2.

Here is a list of additional prospective distribution method:

• maskbookplugin:git+ssh://[email protected]:username/repo.git
• maskbookplugin:https://
• maskbookplugin:http://
• maskbookplugin:ftp://
• maskbookplugin:ipfs://
• maskbookplugin:bittorrent://
• maskbookplugin:gun.eco://

As the last resort, distributing plugins as GZIP files can be the best way if you insist the separation between the profile and the script.

[yisiliu]

I don't think such a technical spec is essential now. What I am concerning in this stage is 1. What should the plugin look like in Maskbook? Does it have a fixed display area or a size limit? 2. How can we integrate it with the current dashboard as an entry point? Shall we have another individual page to host the userscripts? 3. Shall we assume a strong relationship between the userscripts and the blockchain, e.g. a wallet?

We can get back to the technical details once we have a big picture ready.

[neruthes]

Entry Points

A plugin has 4 entry points:

• Post-Affixing Canvas
• Maskbook Post Composition View
• Plugins Management Page in Dashboard
• Arbitrary SNS Page Element

The user may perform different operations in each entry point. All 4 entry points lead to Plugin Screen Modal.

Viewports

A plugin has 2 viewport specs:

• Post-Affixing Canvas (PAC)
• Plugin Screen Modal (PSM)

PAC is a fixed-width canvas of 340px. The height is automatically adjusted according to the content, with a hard cap of 500px. A plugin should show essential information inside a PAC.

PSM is a flexible-width canvas, up to 700px. The height is dynamic, up to 700px. A plugin should host its sophisticated logics inside a PSM.

Plugins Management Page

We will greatly copy the design of the Extensions Management Page in Chrome.

Use cases:

• View the list of currently installed plugins
• Add Plugin
• Disable Plugin
• Delete Plugin
• Visit Plugin Developer Website
• Export Plugin Source Code

[yisiliu]

Sounds good except the fact that the Maskbook extension would contain a lot more complications as a whole. Kinda worried if we are adding too many non-Maskbook functionalities to it, as we were planning for the holoflows.

[neruthes]

Sounds good except the fact that the Maskbook extension would contain a lot more complications as a whole. Kinda worried if we are adding too many non-Maskbook functionalities to it, as we were planning for the holoflows.

Indeed, we are inevitably introducing many features of Holoflows here. But I see it in an optimistic way. We can test prototype designs in Maskbook before Holoflows.

[yisiliu]

This problem is kind of essential since we cannot turn back once we've done the implementation here. I would suggest we do some testing plugins first for verification and then move the core directly and permanently to Holoflows, as you also suggested.

[neruthes]

Agreed.

For GitCoin plugin, we still need to hurry. Maybe hardcoding it for M5 is the best balance point.

[neruthes]

Note: Plugin Identification

I suppose that each plugin may be identified by a primary identification code. The major purpose is to differ the identification from the retrieval. For example, HTTPS URL can be a good way to indicate how to retrieve a plugin, but it is not a favorable identification method.

However, it can be very challenging to establish the connection between the identification and the retrieval. This usually involves a centralized service which maintains the mapping between names and URLs. And this kind of centralization is what we want to avoid.

If we do not make an explicit design right now, HTTPS URL should be good enough at this moment. The URL should point to a manifest JSON file, which indicates the HTTPS URL of the real script file itself.

[neruthes]

Update: Unified Distribution Method

I just updated the documentation.

A plugin developer may use DNS and URL to distribute the plugin.
For example, if the Plugin ID is "com.example.myapp", the developer should create a TXT record at "myapp.example.com" where the value is the a URL (HTTPS, HTTP, and IPFS are supported) of the plugin manifest. In the plugin manifest, the actual URL of the script file should be specified.
Maskbook skips the "/etc/hosts" configurations when looking up these TXT records.

This should make things easier.

[Jack-Works]

OK, a technical question: How would you like to do a DNS query in JavaScript that runs in the browser?

[neruthes]

OK, a technical question: How would you like to do a DNS query in JavaScript that runs in the browser?

Good question. Here is another thought: The developer of com.example.myapp should host a file at https://myapp.example.com/maskbook-plugin-manifest.json.

For a developer who does not have any domain name, he can use io.github.username.repo. Maskbook will treat all package names starting with io.github as special cases, so that https://username.github.io/repo/maskbook-plugin-manifest.json will be retrieved, instead of https://repo.username.github.io/maskbook-plugin-manifest.json.

[neruthes]

Feature Idea

For Red Packet, it is an async operation to create the red packet for obtaining the transaction ID. In the meantime, the user may not publish the post, otherwise the red packet data will not be included in the post. Therefore, we may want to offer setComposeAwaitThisPlugin() and unsetComposeAwaitThisPlugin() APIs for plugin developers.

[neruthes]

Note

I have been updating the distribution method design sections.

Now I have some questions:

• Can Maskbook perform HTTP GET operations from localhost, *.local, and 127.0.0.1 in the background without explicitly requesting the user to grant access to the hostnames in Chrome? cc @Jack-Works
• If there is a hostname access granting procedure, we may need to have 2 steps (1: Get manifest; 2: Get actual script file and icon image) of requesting hostname access for 3 hostnames (1+2). Is this fine?

[neruthes]

Added section:

---

Post View Integration

Domain-Based URL Reception

A Plugin may request Maskbook to provide an array of URLs which match the given domain names in a Post. For example, the plugin of Gitcoin may request to be informed of any URL whose hostname is "gitcoin.co" or "*.gitcion.co".

By default, Maskbook automatiaclly allows plugins to read the URLs in a Post for those whose hostnames are exactly or are subdomains of the Package Name. For example, if the Package Name is "co.gitcoin", Maskbook automatically allows it to read the URLs of "gitcoin.co" and "*.gitcion.co".

If a Plugin is under "com.maskbook.provide", it can directly read the entire Post content and can perform its own URL detection inside.

---

This will replace the previously written "plugins can inject arbitrary scripts into SNS webpages".

[Jack-Works]

This design is declarative and limited the flexibility

[neruthes]

This design is declarative and limited the flexibility

I look forward to alternative designs which can:

• Allow a plugin to legitimately perform additional interpretation of the Post content;
• Prevent a plugin from accessing information of a Post which it should not be able to access;
• Avoid requiring a centralized reviewing system.