[Feature] Applets for Maskbook

[neruthes]

Abstract

It has been clear that we have some advanced optional features to introduce; examples include Ethereum wallet, AdClick, and Smart Text Interpreter.

Through months of contemplation, I am convinced that applets may be the best way to do so as a good combination of technical extensibility and right of choice for users. With an Applet Manager, a user may enable and disable such optional features, like how optional features in the "Discover" tab may be hidden in WeChat.

Applet Capabilities

Summary

An applet may be able to:

• Have a section of options in settings page;
• Insert a script which runs in every webpage where Maskbook may access;
• Present a button in the composing modal which opens another modal;
• Write a custom data field in Maskbook post payload;
• Display a custom button in the extension icon left-click panel on browsers;
• Provide renderers for smart text protocol;
• Dispatch events to its backbone script from smart text rendered area;
• Display a stand-alone MetaMask-like dialogue according to commands from smart text rendered area; and
• HTTPS/WSS communication access.

With these capabilities, applets may be able to perform necessary operations while conforming to the expectations for optional features in Maskbook.

To be continued...

[Jack-Works]

this will bring unnecessary complexity to our product I think

[neruthes]

this will bring unnecessary complexity to our product I think

• We will eventually have some optional features.
• Users should be able to quit optional features.
• We must minimize the disaster of including an Ethereum wallet in Maskbook.
• Third-party contributions should be possible and should have a subtle distance from our main codebase to prevent coupling.
• This is a good starting point to explore the possibilities of Holoflows.

[Jack-Works]

this applets and holoflows don't share the same plug-in model.

if maskbook is going to have a plugin system, it shall using the hook model (beforeSomeEvent, afterSomeEvent). Holoflows is using the composing function model (data |> f1 |> f2 |> f3).

[neruthes]

this applets and holoflows don't share the same plug-in model.

if maskbook is going to have a plugin system, it shall using the hook model (beforeSomeEvent, afterSomeEvent). Holoflows is using the composing function model (data |> f1 |> f2 |> f3).

Could you elaborate how hook model may support the capabilities aforementioned? Especially...

• Present a button in the composing modal which opens another modal; and
• Write a custom data field in Maskbook post payload.

[Jack-Works]

this applets and holoflows don't share the same plug-in model.
if maskbook is going to have a plugin system, it shall using the hook model (beforeSomeEvent, afterSomeEvent). Holoflows is using the composing function model (data |> f1 |> f2 |> f3).

Could you elaborate how hook model may support the capabilities aforementioned? Especially...

• Present a button in the composing modal which opens another modal; and
• Write a custom data field in Maskbook post payload.

hook model can not add a button. there should be another command style API like addAction or replacePostBox.
beforeDeconstructPayload can do the job.

and again, this will bring unnecessary complexity

[neruthes]

this applets and holoflows don't share the same plug-in model.
if maskbook is going to have a plugin system, it shall using the hook model (beforeSomeEvent, afterSomeEvent). Holoflows is using the composing function model (data |> f1 |> f2 |> f3).

Could you elaborate how hook model may support the capabilities aforementioned? Especially...

• Present a button in the composing modal which opens another modal; and
• Write a custom data field in Maskbook post payload.

hook model can not add a button. there should be another command style API like addAction or replacePostBox.
beforeDeconstructPayload can do the job.

and again, this will bring unnecessary complexity

Reasonable.

We may need didShowComposePostView event and several methods:

• Composing:
  • addOwnEntryButton
  • setAdvancedAttribute
• Post Rendering:
  • renderOwnCustomPostContentArea
  • renderOwnCustomPostContentDetailView
• Database:
  • getOwnDbValue
  • setOwnDbValue

With these APIs, publishing polls and images in posts will be possible. Typed posts may be implemented as posts with attributes.

[Jack-Works]

No I'm not suggest you to develop such a system

[neruthes]

No I'm not suggest you to develop such a system

Ok. In your point of view, what is the most harmless way to include an Ethereum wallet in Maskbook?

[Jack-Works]

No I'm not suggest you to develop such a system

Ok. In your point of view, what is the most harmless way to include an Ethereum wallet in Maskbook?

By not adding it.

[neruthes]

No I'm not suggest you to develop such a system

Ok. In your point of view, what is the most harmless way to include an Ethereum wallet in Maskbook?

By not adding it.

I wish you may understand that we will have to make anything to raise funding, even including Flappy Bird, otherwise we will bankrupt since we do not have a sufficient revenue cashflow. Our priority is to minimize the consequences of these disasters, rather than to stay away from these disasters.

[Jack-Works]

I wish you may understand that we will have to make anything to raise funding, even including Flappy Bird, otherwise we will bankrupt since we do not have a sufficient revenue cashflow. Our priority is to minimize the consequences of these disasters, rather than to stay away from these disasters.

Ok, this kind of plugin system is possible, but it need a lots of work and our code will become spaghetti. If we don't have a ton of features for raise funding, it is easier to add it case-by-case

[neruthes]

I wish you may understand that we will have to make anything to raise funding, even including Flappy Bird, otherwise we will bankrupt since we do not have a sufficient revenue cashflow. Our priority is to minimize the consequences of these disasters, rather than to stay away from these disasters.

Ok, this kind of plugin system is possible, but it need a lots of work and our code will become spaghetti. If we don't have a ton of features for raise funding, it is easier to add it case-by-case

Tons of features, likely. Hope for the best; prepare for the worst. Also, the long-term vision is quite different from what we documented in Mar 2019.