What Covid-19 Has Taught Us About Knowledge Management (Information Series Part II)

One thing the Coronavirus outbreak has shown us is that getting quality information based on quantitative-based research and professional recommendations is key to ensure the public is well-informed, and fully educated about a wide-scale health issue (or any issue for that matter).

Photo by 🇨🇭 Claudio Schwarz | @purzlbaum on Unsplash

Subject repositories (or discipline repositories) attempt to collect information based on academic research, about a particular subject or area of interest. They provide a one-stop for quality information, collating educational material, findings and other supporting documentation in a single location. Subject repositories should use well-researched scholarly information and this information should be verified for authenticity and its source should be easily tracked.

Subject repositories are even more important in a decentralised world. Information could be stored and hosted across a number of disparate systems – this is perfect for circumventing the influence over information by nefarious parties who are looking to either control the narrative, or benefit from either playing up or playing down its impact… But by its very nature, decentralised data is difficult to find, search across and extricate meaningful conclusions.

In a decentralised world, subject repositories will be the gathering points for various information from a wide range of sources. It will be more important than ever to attach a pseudonymous path to the original material to ensure both the integrity and truthfulness of the data while also ensuring that the privacy of the source is protected, especially in regimes which single out or punish purveyors of quality, scientific information.

KnowledgeArc Network offers some mind-blowing alternatives to the way ‘the asset of knowledge’ has been managed to date…

When data is archived on a blockchain the information remains:

1. Immutable – the data can never be changed or corrupted

2. Persistent – it will last forever

3. Unique – there is no other information like this, it’s the single source

4. Open – the data is publicly accessible so others can build on the knowledge created

Come +Follow KnowledgeArc Network on LinkedIn for the latest tech and team articles, giving information-power (and potentially tokens) back to the academic researcher and ultimately the communities (who need it most).

Combat Misconduct In Research Using Blockchain

There are issues to be solved in academia. Some claim, and research shows this to be true, that misconduct in research has increased. Can blockchain be a part of the solution to reduce this behaviour? How can we combat misconduct in research using blockchain?

Before we answer this question we need to look at the concept of misconduct. What is misconduct in research?

What is Misconduct in Research?

Misconduct in Research
Photo by Rohan Makhecha on Unsplash

Misconduct in research can stem from many things: it can be pre-meditated or can happen as a result of a lack of knowledge. Both cases are harmful in many ways to society, research and individuals.

Examples of misconduct can include cheating with data, plagiarism or false duplications. This misconduct is severe, and would affect academia in many ways – both directly and indirectly.

As it stands today, there are very few mechanisms to identify and react to misconduct.

One paper where we can read about the increased academic misconduct is in Vijay Mohan’s article: “On the use of blockchain-based mechanisms to tackle academic misconduct” (Mohan, 2019).

Here you can glean some background as to how he believes the “winner takes it all” contest-like situation in academia is building a framework for more incidents of misconduct. The article provides a good basis for understanding the situation.

Back To Blockchain

One of the solutions to combat misconduct, Mohan suggests, is to use blockchain technology. In short, his idea is that blockchain can provide methods and technology for alleviating problems with the academic publishing industry.

The idea is that blockchain can work as a monitoring technology, and thus be a part of a solution to increase the probability that misconduct will be detected. According to Mohan, there are not enough of such monitoring platforms today.

Read the article by Vijay Mohan published in Research Policy 48 (2019) (subscription journal)

KnowledgeArc Network and Blockchain

At KnowledgeArc, we believe in blockchain.

Firstly, we believe that technology can be a way to meet the challenges of open science.

Secondly, we believe technology can be a game-changer when it comes to moving the focus from quantity to quality in publication.

And lastly, we believe blockchain can add security and full openness to the equation.

With this in mind we also believe that blockchain can be one of several initiatives contributing to improved academic processes. These are just some of the ways we can combat misconduct in research using blockchain.

What are your thoughts in this regard? Leave your comments below…

+Follow us on LinkedIn

Read more about our blockchain developments here.

Self-signed certificates with local root CA

This tutorial briefly covers the creating and trusting your own certificate authority (CA) for issuing self-signed SSL certificates, and is designed to work with OribitDB’s new REST API HTTP/2 push services.

This tutorial is aimed at Unix-based systems, in particular Ubuntu and other Debian-based Linux distributions so you will need to modify the commands for your own platform. All code examples are intended to be copied and pasted directly to the command line and will generate certificates in your current working directory.

To get started, we are going to create a root certificate which we will use to sign additional SSL certificates with.

First, create your root CA private key:

openssl genrsa -des3 -out rootSSL.key 2048
Generating RSA private key, 2048 bit long modulus
e is 65537 (0x010001)
Enter pass phrase for rootSSL.key:

You will be prompted for a password. Be sure to specify one that is long enough as you may encounter errors if your password is too short.

Next, use your CA private key to create a root certificate:

openssl req -x509 -new -nodes -key rootSSL.key -sha256 -days 1024 -out rootSSL.pem

Once launched, you will need to re-enter the password you assigned to your private key:

Enter pass phrase for rootSSL.key:

If successful, provide information about your certificate:

 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 Country Name (2 letter code) [AU]:
 State or Province Name (full name) [Some-State]:WA
 Locality Name (eg, city) []:
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:
 Organizational Unit Name (eg, section) []:
 Common Name (e.g. server FQDN or YOUR name) []:localhost
 Email Address []:

You are now ready to install the new CA certificate into your CA trust store. The following commands will copy the root certificate into Ubuntu’s CA store so you may need to modify the paths if you are on a different distribution or OS platform:

sudo mkdir /usr/local/share/ca-certificates/extra
sudo cp rootSSL.pem \/usr/local/share/ca-certificates/extra/rootSSL.crt
sudo update-ca-certificates

Now it is time to generate a certificate for your development environment. Create a private key for your new certificate:

openssl req \
 -new -sha256 -nodes \
 -out localhost.csr \
 -newkey rsa:2048 -keyout localhost.key \
 -subj "/C=AU/ST=WA/L=City/O=Organization/OU=OrganizationUnit/CN=localhost/emailAddress=demo@example.com"

Next, create the certificate, signing it with your Root CA:

openssl x509 \
 -req \
 -in localhost.csr \
 -CA rootSSL.pem -CAkey rootSSL.key -CAcreateserial \
 -out localhost.crt \
 -days 500 \
 -sha256 \
 -extfile <(echo " \
    [ v3_ca ]\n \
    authorityKeyIdentifier=keyid,issuer\n \
    basicConstraints=CA:FALSE\n \
    keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment\n \
    subjectAltName=DNS:localhost \

Your SSL certificate is now ready for use. To use it with OrbitDB’s REST API, launch the cli.js script with the flags –https-key and –https-cert, using the new localhost.key and localhost.crt files we just created:

node src/cli.js api --ipfs-host localhost --orbitdb-dir ./orbitdb --https-cert ./localhost.crt --https-key ./localhost.key

The certificates should validate against your Root CA when used with tools such as curl:

curl -vs --http2 -X POST https://localhost:3000/db/my-feed --data 'create=true' --data 'type=feed'
 successfully set certificate verify locations:
 CAfile: /etc/ssl/certs/ca-certificates.crt
 CApath: /etc/ssl/certs
 SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
 ALPN, server accepted to use h2
 Server certificate:
 subject: C=AU; ST=WA; L=Ellenbrook; O=Organization; OU=OrganizationUnit; CN=localhost; emailAddress=demo@example.com
 start date: May 25 14:56:35 2019 GMT
 expire date: Oct  6 14:56:35 2020 GMT
 common name: localhost (matched)
 issuer: C=AU; ST=WA; L=Ellenbrook; O=Internet Widgits Pty Ltd; CN=Local Certificate
 SSL certificate verify ok. 

In the above, you can see the CA being loaded from the correct location (/etc/ssl/certs) and details about the certificate (Server certificate:).

You can now successfully run the new OrbitDB HTTP API with self-signed certificates on your development environment.


How to get HTTPS working in localhost development environment, secureend.com, https://reactpaths.com/how-to-get-https-working-in-localhost-development-environment-f17de34af046