Originally published at medium.com

MIX Acuity

Online censorship is accelerating. The need for a stable release of MIX Acuity — the MIX desktop browser for Mac, Windows and Linux — grows by the day.

The are a few major tasks that need to be completed before Acuity 1.0. I intend to have these finished by the end of June. Once this is done we can start promoting Acuity for real-world use and continue to improve it.

Secure account creation

Generating mnemonic words and encrypting private keys needs to be done in an industry-standard way.

Each MIX account has two addresses: a controller and a contract. When creating a new account this mapping needs to be stored in a smart contract so that accounts can be recovered with just the mnemonic words. This will enable compatibility with the DoublePlus web-based MIX browser by Brian Heishman.

Currently it is only possible to mine MIX once you have created an account. It needs to be possible to mine during the account creation process to obtain the MIX for account contract deployment and posting content.

Improved splash screen

Acuity has a splash screen already, but it needs to be updated to wait until both MIX and IPFS are ready before entering the application.

Smart contract review & redeployment

MIX has many smart contracts that implement its core functionality. They are generally very mature and well-tested. They need to be updated for latest Solidity and have test coverage increased further. Because MIX is a blockchain with a narrow remit it is theoretically possible to update any smart contract with a hard fork, but it is better to make them as good as possible to start with.

item_store_ipfs_sha256.sol — initial commit Nov 26, 2015, this is the core smart contract of MIX. It enables the creation of revisionable on-chain content items. Each revision is stored as an IPFS hash.

item_store_registry.sol — MIX has an upgrade system whereby anyone can deploy a new item store smart contract and register it with this contract. Each itemId is 32 bytes. The final 8 bytes can be used as a key in this smart contract to find the contract that manages the item. Client software needs to actively trust all item store contracts that they interact with.

item_store_short_id.sol — For cases where 32 byte itemIds are too long, the itemId can be registered with this contract and a mapping from a 4 byte shortId to a 32 byte itemId will be created. Each mixin, e.g. Title, in a piece of content is identified by a mixin type item. Only a small number of these items will be used most of the time, so it makes sense to identify mixin types by shortId instead of itemId to reduce the size of content stored in IPFS.

MixReactions.sol — Every account can have up to 8 emoji reactions to each content item. It needs to be determined if combined emoji should be supported.

account_profile.sol — This is a mapping between accounts and profile items. It needs to be determined if profile item history should be maintained in state.

MixAccount.sol — Every account is a deployment of this smart contract. It has the ability to forward arbitrary transaction data and MIX from its controller to other contracts. It can receive MIX, MIX tokens and ERC1155 tokens. TODO: investigate future use of CREATE2 opcode.

MixAccountRegistry.sol — Maintains a mapping between account controllers and contracts for ease of account recovery.

MixAccountItems.sol — Maintains a mapping between accounts and lists of items, for example so that content feeds associated with an account can be discovered.

CreatorToken.sol — Enables content creators to get paid continuously in their own token. Potentially enabling a revenue stream without the use of advertising, data harvesting or paywalls.

TrustedAccounts.sol — Enables accounts to publicly trust other accounts. The idea being that if you trust an account you are automatically whitelisting all content from them and everyone they trust. This should prove to be an effective way to receive content from a wide community while protecting yourself from illegal and immoral content.

MixItemDagOneParent.sol — A comment hierarchy is a DAG where each item can only have one parent. This contract maintains a record of which item is a reply to which. The parent must be created before the connection. The child must be created after the connection. This is possible because the generated itemId is a hash of the creator address and the creator supplied nonce. Another deployment of this contract will be used for mixin type inheritance.

MixItemDagOnlyOwner.sol — This is used for feed items. Only the owner of a feed can add an item to the feed. This may be extended so any account in a group can post to a feed.

Database schemas

Acuity stores some data locally in a LevelDB database. The structure will need to be reviewed before 1.0 because it would be more work to change it later.

Mixin schemas

The Protobuf schemas for each mixin type will need to be reviewed before release so we don’t have to change them later.

Recent Acuity milestones

Feeds

Every account can create any number of feeds. These can be subscribed to off-chain. Watch the video.

File attachments

Brian Heishman has implemented file attachments. This uses the new File mixin. Watch the video.

In-app mining

By popular request in-app mining has been implemented. This was quite easy because the open source Ethminer does most of the heavy lifting.

You can either mine the chain directly, or use a pool. Pool mining will be useful to get a small amount of MIX quickly. This will be very useful when setting up your account.

Trusted Accounts

MIX has a system whereby accounts can publicly declare in a smart contract which accounts they “trust”. Content from trusted accounts and from accounts the trusted accounts trust is automatically whitelisted.

Watch the video.

Emoji Reactions

Threaded Comments

Brian Heishman implemented the close button and the collapse comments functionality.

Russian UI

Further translations can be added quite easily.

Conversion from electron-vue to electron-webpack

When I created the Acuity project I used a template called electron-vue. This was extremely helpful to get the project started. However electron-webpack is much more actively maintained and is part of the excellent electron-builder project that we already use to build Acuity for Windows, Mac and Linux.

Switching to electron-webpack has upgraded Acuity to Babel 7 and provides a much improved developer experience.

Future Acuity milestones

Website

As you can see from the screenshot at the top of this post, the web site is coming along well. Once we reach the 1.0 milestone one of the first things to will be to get this live. Ethan Fisher created the design and content in Webflow.

Native video

I have quite extensive experience with web video. Adding video functionality to Acuity seems fairly straight forward. This would make Acuity an uncensorable version of YouTube.

FFmpeg is still the best open source transcoding software. Video will be transcoded to multiple resolutions either locally with FFmpeg, or using a hosted transcoding service, before being published to IPFS.

It will probably use the AV1 codec, assuming support for it in FFmpeg and Electron is mature enough.

User tagging

Mentioning people in messages is extremely important. This will be implemented as a smart contract, enabling rich functionality such as notifications.

Topics

It will be possible for any content item to be added to any number of “topics”. This will add subreddit-style functionality to Acuity.

Creator Tokens

Enabling every content creator to have their own freely tradable token is an extremely exciting concept. See the original blog post for details.

It will be possible to rank content creators in a Sybil-resistant way by comparing how much revenue they earn per day.

Token holders will be able to up/down vote content relative to how much of the token they own.

Acuity itself will have its own token called ACUITY.

Account whitelist / blacklist

Currently there is just the on-chain Trusted Accounts system. However, it does make sense to be able to override this with an off-chain whitelist / blacklist system.

Search

Individual instances of Acuity will index the content they see using Elasticsearch. When searching, Acuity will recursively contact other instances of Acuity in the users trust network. This will not rely upon any centralized entity.

Content language tagging

MIX has a language mixin. This will be exposed to the UI so the content creator can specify the language their content is written in.

Revisions

The Item Store smart contract has built-in support for content revisions, but this functionality is not yet exposed in the Acuity UI. This will be an extremely powerful feature.

Feed item pinning

A common functionality in other social networks and CMSs is the ability to pin posts to the top of a feed. MIX should have this ability also.

Unified content viewing / editing

Currently Acuity enables creation and editing of different “content types”, but MIX is not supposed to work this way. Content can be created by adding whatever mixins are required. Each mixin type will have 2 Vue components: a view component and an edit component. This will enable dynamic content creation.

WYSIWYG

Acuity currently uses Markdown for rich text. This is great, but of course a lot of users prefer a WYSIWYG experience. Tiptap is a strong candidate for this.

Historic Avatars

It seems that every social media platform always shows the latest user avatar, even for content that was published when the user had a different avatar.

It’s desirable to to show the correct historical avatar that the user had at the time the content was posted. Because full history is preserved in blockchain state, this can be implemented in Acuity.

Light Client

Currently, Acuity runs a full MIX node. Because there are not yet a lot of transactions this is not a major burden on the device. Once MIX gets more popular the time to catch up with the network may become detrimental to the user experience. Acuity will need to run as a “light client”. This is standard Ethereum functionality.

However, because every blockchain query would be over the Internet rather than local, Acuity would feel very slow. The solution to this issue is to deploy read-only smart contracts that perform all the queries in one request. This will also add further complexity to the Acuity codebase, but will ultimately result in excellent user experience.

TypeScript

Currently Acuity is written in JavaScript, but it will gradually be converted to TypeScript for greater robustness and security.

Other MIX news

Crowdfund issuance reduction

The Revenue smart contract was hard-wired in the genesis block to release project revenue for 2000 days. This is how the project is crowdfunded.

Initially (April 27th 2017) 50k MIX was released per day. This is reduced automatically by 5k every 200 days. Currently revenue is being released at 35k per day. This will reduce to 30k around 5th July. By co-incidence, 30k MIX is also approximately what the miners receive every day from the block reward.

On October 18th 2022 the project revenue will have ceased completely and the block reward will be the sole source of increased supply.

See Issuance for more information.

MIX Book

The MIX Documentation is very out of date. I will be hiring a technical writer to analyze all the progress already made and synthesize it into a book explaining in detail how MIX works. This will be an open source project with its own creator token.

It will probably use the same Read the Docs system as the current documentation. It can compile documentation into many formats including web, ebook and printed form.

Physical copies of the book will be available for purchase.

MIX Base

Komodo recently had a major security incident. This relates to the extensive use of third-party JavaScript libraries. Acuity is susceptible to this also.

The solution is the creation of another piece of software, MIX Base. It will handle everything that all MIX apps need, i.e. running Parity and IPFS, and account management. If a MIX app wishes to send MIX, change account controller, or spend gas too quickly, Base will prompt the user to confirm the transaction.

Because MIX Base will be written in Rust with much less use of third-party libraries, it will be much less susceptible to this attack.

This functionality will be gradually transitioned from Acuity to Mix Base.