yisiliu
commented
4 years ago This is the road towards Holoflows. We could split our tasks into two directions: 1. an execution environment as a sandbox within any text field on the web 2. the design of Smart Text to be rich enough to hold any type of scripts. We will need to assess this to get along with our major business goal before any further actions.
Abstract
In this article, I will address my latest considerations regarding the way we implemented Ethereum Cryptocurrency Red Packet (ECCRP) features in Maskbook (version 1.9.X).
Understanding Maskbook Plugin
The idea of Maskbook Plugin (MBP) started as the little extra piece of information affixed on posts, such as geographic location information. On Facebook and Twitter, a post may be affixed by a location, without framing the post in a way that the location becomes the core focus of the post.
This is critical to understand the role of MBPs. One major usage of MBPs would be to attach location information within a post, while making sure that the user is not obliged to choose whether to attach a location in the post. As exemplified by Facebook, a series of additional information can be optionally attached to a post.
In the context of Maskbook, the idea is also clear. An MBP should mainly display information to the audience who can decrypt the post. However, ECCRP appears to be a drastically different scenario. The underlying logic of ECCRP is that it should attract new users, which would require the information of including an ECCRP inside the post to be displayed publicly. However, a user should also be able to determine the visibility settings of the ECCRP.
Plugin or Typed Post, It Is a Problem
According to the design of the Plugin system, a Plugin may write data into a public field of the post payload so that the people who are not capable of decrypting the post should be able to find certain information from the public data field, as written by the Plugin.
Another idea is Typed Post. To be straightforward, Standard Post and ECCRP Post are totally different things; they only share the same means of transportation – the "posts" in terms of Facebook and Twitter. We previously disliked this idea due to the possible trivialization coming in future, but it appears to be a favorable solution for conveying ECCRPs. With that in mind, if we manage to suppress trivialization by refraining from relentlessly adding new types, implementing ECCRP as new type of post should be a better way, in the hindsight of toady.
In addition, the complexity of ECCRP may slightly exceed the boundary of an MBP. In future, there can be other features which involve Ethereum and Ethereum wallets, and it should be better to put such features in independent MBPs, while making Ethereum operations universally available for each MBP.
Next Steps of Plugins
The Plugin system may continue its development. However, the priority should be greatly reduced, unless otherwise requested by marketing and fundraising considerations. At present, we do not have any additional MBP-based feature to develop.
Starting Typed Post
All types should share the same data structure and payload specification. However, the external shells should differ. When the external shell of ECCRP incentivize the readers to install Maskbook for collecting the Red Packet, the external shell of Standard Post suggests the reader to install Maskbook for reading the cleartext in the post.
Conclusion
When we have time to refactor, the implementation of ECCRP should be changed to a new type of post from the current MBP-based solution.