Unikname Development Report #14

5 May 2021 | News

Guillaume Nicolas

Security Token

Welcome to the 14th edition

Every month we share a short summary of what happened during the last four weeks in the Unikname and uns.network ecosystems with our community. Welcome to the 14th edition!

My Unikname App works faster :haute_tension:

From the first visit to the daily use, you should notice an improvement of app reactivity. Here are some of our changes that makes it possible.

My Unikname app is a webapp. It’s developed with standard browser technologies like HTML, Javascript and CSS. We use abstract client-side frameworks to ease development, like Vue.js for data rendering, Quasar for ui components, Dexie for indexDB wrapper or Axios for browser fetch wrapper.

All those tools are packed together to create an optimized set of Javascript files (a.k.a “bundles”) downloaded on client-side. 

Each bundle is optimized to contain only part of tools we need for the project (we never use 100% of a framework code). This mechanism is called Tree-shaking and is done by a development tool : Webpack. Another mechanism is used to fill-in some browser lack of feature implementation : Polyfill. All of these optimizations are done during a “build” step run before file publication on webserver.

Code splitting

My Unikname App Javascript code is split into 2 functional parts:
  • post-install : all the code executed during installed app navigation
  • pre-install : all the code executed before app is installed (mainly landing pages and installation flow)
Thanks to code splitting and lazy loading mechanisms, files are downloaded on demand. It means that you won’t download post-install files if your on the landing page or installation flow. Saving kilos of bytes required in-app (like encryption algorithms, database managers or in-app ui components).


Another improvement has been to split those bundles in two :
  • a bundle for technical libraries which rarely change (like Vue or Quasar), called `vendor`
  • a bundle for functional code which is frequently updated due to new features.
This improvement saves download of kilos of bytes of unchanged code after visit app again.

Import syntax

Import syntax is important and can save tons of Javascript in final bundles. During a development, we missed this rule which causes full import of Quasar library code into final bundle.

Bad syntax is:

import Quasar from "quasar";
Quasar.lang //...rest of code

During Webpack file parsing, “Quasar” root module object is declared as used in following code, which makes impossible for tree-shaking (in Webpack v4) to know that only lang property of object is really used.

Correct syntax is:

import { lang } from "quasar";
// ...rest of code using lang

Size checker tool

To prevent invisible app size increase, we’ve added in our build process a size controller node utility : size-limit. This tool helps us to know when app size increases above a fixed limit.

So after build step, final (optimized) bundle size is computed and if size exceeds limit, command is stopped with an error. In our continuous integration environnement, code can’t go to production, without a developer intervention. Two solutions for the developer : increase is consistent then limit is raised-up, or developer must go into its code and find the origin (bad import, wrong library packaging, …).

Minified code analyzer

If developer has to go deeper in bundle analysis, s•he is quickly stuck in front of minimized code, which is un-readable by human. For humans, we use source-map-explorer utility which renders a tree-map of a minimized bundles where you can find origin and size of each byte. You can instantly spot which part of the code is heavy.

Bundling method

Last but not least, some of project dependencies are not optimized to work in a limited resource environment. For this type of environment (like client-side browser), tree-shaking is required to not overload browser with unused code. This processing is only possible if a module (dependencies are modules) is bundled using ECMAScript syntax (currently ES6). Unfortunately, some of our dependencies was shipped with incompatible bundling methods (e.g commonjs or AMD) or include their huge dependencies which were duplicated in our final bundle.

For example, we had to upgrade vue-tel-input dependency after developers made some build improvements to reduce final bundle size and so impacting ours. Cutting library size by a half between 4.0 and 5.0 and saving hundreds of kilobytes.

We faced the packaging syntax issue with libraries shared between UNS node and app. What we have done is to add (because we couldn’t break other clients usage) ECMAScript target in libraries build config. Then webpack automatically choose target build result based on client project config.


With all these improvements, we have:

  • removed around 400+ kilobytes of our final bundles code
  • reduced unused code download in UNC and before app installation
  • improved user experience with a more reactive app
  • reduced app update size (splitting technical libraries from functional code)

Unikname Connect dashboard automation :tête_de_robot:

In order to improve your partner installation experience, we’re working on the automation of Unikname Connect integration workflow.
We are developing mechanisms to be notified and create your site credentials as soon as you press the “site creation” dashboard button from your personal space.
Next step is to make these credentials available automatically in your space. Then in a simple click, you’ll be able to test and integrate Unikname Connect button to your website.

Like in our other websites (unikname.com, docs or my.unikname.app), we have integrated our support live chat tool : Rocketchat. This tool let us known when you’re facing an issue or having a question. All the team is daily connected to answer in real-time all of your interrogations. So don’t hesitate to press the bottom-right orange button to ping us.

UNS Network v5.6.0 node is out :globe_avec_méridiens:

Unikname ecosystem works on top of the uns.network blockchain which is decentralized, delegated proof-of-stake (DPoS) secured registry. To prevent reinventing the wheel, uns.network choose Ark blockchain as a basis for blockchain protocol. Inheriting DPoS rules, peer-to-peer communications, registry management, fungible token, and so on.

Ark offers a strong and customizable framework to project owners which leads to quickly deploy your own network. But, for uns.network, configuration wasn’t enough to implement token economy mainly based on fungible token. Because fungible token concept was missing, uns.network had to design and implement NFT on its own chain.

The only possibility was by forking the Ark code. Fork is great, but it has downsides : you loose automatic updates of the core framework. You have to deal with each new core release manually, by merging codes and (sometimes) resolve conflicts. Luckily framework uses plugin pattern, which ease development and shipment of new features and concepts.

UNS v5.6.0 node switches Ark protocol from 2.6.X to 2.7.X and benefits from lot of bug and security fixes (See changelog).
This new version also includes natively the Ark Socket Event Forwarder which is responsible of forwarding real-time blockchain events through socket.io

More concretely, it means that anyone can build tools listening and reacting in real-time to blockchain events (like new transaction forged, new bloc forged, new UNIK token minted, …) emitted from its own uns.network node with plugin enabled. Our particular need will be disclosed soon. Stay tuned :oreille:.

If you have found a vulnerability on uns.network protocol, please ping us at security@unikname.com.

WordPress plugin new shipment :navire:

On 19th of April, We have released the 8.5 version of our WordPress pluginThis new version ships new awesome features:

  • You can now choose how progressive is the Unikname authentication switch, by choosing which role requires Unikname Connect to authenticate on your dashboard (customer? Administrator ? Contributor? …).

  • If you’ve taken the plunge, you can completely remove password authentication inputs from the login screen for all your users. Preventing doubts on best option to choose (of course it’s Unikname :clin_d'œil: ) and keeping it really simple for your daily users.

Every version is better due to new functionalities but also with improved documentation, better internationalization, simpler UI and new users :visage_souriant_3_coeurs:More info on dedicated forum post.