The recent discussion by Zaki Manian and Ben Weintraub (see https://www.youtube.com/watch?v=3JwlbSAjKAI&t=) got me thinking about the value of proof-of-stake tokens. Ben Weintraub is referring to the this article during the discussion and claims Cosmos needs to handle 40.000 transactions per second (TPS) to be valued at the current price. I think the article is fundamentally flawed, since storing something on a public cloud and storing something immutable (forever?!) on a blockchain aren’t the same thing.

In my opinion, it makes more sense to look at the value of Atoms or any proof-of-stake tokens from a potential fees/income perspective with the following equation:

(Transaction Fees - Validator Fees) x Used TPS x 365 x 60 x 60 x 24/Total Supply at the Time of Staking = Income per Token per Year

For example, in the case of Atoms, the equation could look like the following:

(0.01–0) x 200 x 365 x 60 x 60 x 24/ 242360330 = 0.26024061

The assumptions are:

• An average transaction fee of 4 cents (You can argue that this is way too low to store something forever based on the shared security model)
• No validator fees
• An average of 200 used transactions per second
• Your Atoms are staked, and you don’t lose something percentage-wise because of the inflation. In reality you probably gain a little bit percentage-wise because not all Atoms are staked.

This would result in an interest rate of 26 %.

The two most important variables in this equation are: used transactions per second and how secure is the network (= transaction fee). Something like Inter-Blockchain Communication (IBC), in this case, helps to increase the number of used transactions per second. For Ethereum 2.0 the number of used transactions will be mainly increased via smart contracts.

Obviously, like any economic equation, it’s oversimplified. Let me know what you think about this approach.

An On-Chain Governance Model Implemented in Substrate

On-Chain Governance Problems

As part of our Web3 Foundation grant, we are currently exploring a distributed metadata protocol. The goal of this protocol is to tackle existing issues with the Web 3.0 such as non-userfriendly identifiers, copyright problems, and siloed data.

One key aspect of any distributed system is having an equally distributed governance of the protocol, in opposition of one handled by a single party. An example of this centralization is the Algorand protocol, where its team alone is currently responsible for the list of relay node providers.

Preferably, this governance system is based on fully automated smart contracts with hardcoded rules. Validators or node providers, for example, are automatically penalized in the case of a double signing or unavailability. In reality, however, not every attack vector can be incorporated in such a smart contract or runtime. For instance, multiple or even all validators of a distributed ledger could decide to block certain transactions and make them unavailable for the network. In this case, the automated penalization would not take place since the blockchain would never receive the required information. This problem becomes even more evident if certain network providers aren’t directly part of the distributed ledger. Examples are oracle services, databases, or storage layer, which are all part of our Stars Network Research Project.

A potential solution for the governance of these providers is the implementation of Token-Curated Registries (TCR). In 2017, Mike Goldin posted the first article about TCR. Since then these registries are used for all kinds of community-driven curation purposes (e.g., FOAM Protocol, adChain Registry).

A TCR is essentially a decentrally-curated list with intrinsic economic incentives for token holders to participate in the curation. The exact incentivization depends on the implementation of the TCR, and there is currently no standardized TCR model.

Existing Problems and Potential Solutions

TCRs come, however, with different problems, which are still being actively researched and tested (e.g., TCR Party). That’s why we decided to contribute to this research by trying to address different problems of TCRs:

Binary-valued membership

Currently, most TCRs or validator node operator lists have only two states. For example, either you’re a node operator of a potential multibillion-dollar infrastructure, or you aren’t one. This is rather harsh and certainly not how our society currently works: either you are CEO of the company, or you’re unemployed. In reality, you often need to start as an intern or employee before you get a job with more responsibilities. That’s why we adapted Trent McConaghy’s Layered TCR system.

Essentially, the listing consists of different ranks, and a candidate can only be in one layer at a time. In order to get to the next rank, the candidate first needs to be part of a specific rank for a certain time without being successfully challenged, as well as to fulfill the staking requirement of the next rank. In our concrete implementation, the candidate must contribute with distributed storage before he/she is allowed to run a distributed database layer or even become a validator of the network.

Low Voter Turnout

A low voter turnout increases the chance of lower quality of the results (due to potential unequal representation of the population), independently of the stake.

One way to address this problem is to leverage the initial distribution of tokens and the general interest in the ecosystem. The higher the number of participants, the higher the quality of the TCR.

Alternatively, instead of slashing people for misbehavior (e.g., double signing) or charging high listing fees, the participants should be incentivized through an inflation rate. But rather than supplying additional tokens to users each time that they vote, like suggested by Yi Lucy Wang and Bhaskar Krishnamachari, only the users voting for the correct outcome will earn a certain percentage on additional tokens based on their staked tokens and the locked time. Existing distributed ledger governance models based on inflation funding, like the Cosmos network, show that this is a great way to engage people to participate in the network.

Making the voting power also dependent on the lock-up time leads to a high incentive to lock up your tokens as long as possible. More voting power requires, therefore, living with your decisions for longer. Furthermore, it makes the voting power less dependent on the token distribution by adding an additional variable.

Objectivity of the Information

It’s very difficult for the participants of a TCR to come to an agreement if the provided information is subjective. That’s why even if the rules cannot be hardcoded, the voting criteria still need to be clearly defined and, ideally, use simple interfaces which provide a clear overview of these criteria. For example, users should rate storage providers based on quality metrics instead of pure trust. It’s the job of the interface providers to make this is as user-friendly and structured as possible. The protocol developers, therefore, need to define a clear criteria catalog, on which we are currently working.

Conclusion

This article attempts to provide a view of our current research into TCRs, and it does not constitute a finished product. We are currently setting up our first Testnet to actively verify our assumptions and to test different parameters. If you are interested in helping us or want to join our Testnet once it’s live, feel free to join our Discord Server. You can find our current implementation of LITTCR as Substrate Runtime Module called Federation on GitHub.

Layered Inflationary Time-lock Token-Curated Registry — LITTCR (no litter) was originally published in Pact Care on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since the exact definition of a decentralized application (Dapp) is still debatable, let’s simply assume in this article that a Dapp is an application run on a decentralized network without any centralized part like a regular backend. Dapps have numerous advantages (e.g., security by design), but currently, most of the time they have three mandatory requirements, that make them uninteresting for most people:

1. Installation of additional software
2. Complicated sign-up process
3. Necessary transaction fees

On top of it, the typical Dapps are quite expansive to run.

In this tutorial, we show how to create a simple voting application called DVote, which can be hosted completely for free on IPFS and doesn’t require any sign-up process or installation. We achieve this by running almost everything in the browser and only using the distributed ledger technology where it makes sense. DVote uses IOTA, the Web Crypto API, and IPFS. The idea is based on the following popular Ethereum Dapp Tutorial. The purpose of this application is to give you an idea of what is possible with this technology, so it’s not a finished product. For example, to make this really useful you would need to show the load progress (currently you just have to wait) as well as a simple login system, which prevents people from voting multiple times. You can find the full open source code on GitHub.

1. Get started

First, we need to set up our development environment. Make sure you have Node.js and NPM installed. Then run the following commands and answer the questions.

npm init
npm i -D webpack webpack-cli mini-css-extract-plugin css-loader html-webpack-plugin html-webpack-inline-source-plugin

Now you can add the following webpack.config.js to your project:

Webpack helps us to create one single HTML file, which contains the complete source code of our application. This way the app can very easily be upload and distribute on IPFS. To start not from scratch, we use the open source project Versus and put everything unzipped inside the src folder. However, we need to change this project a little bit for our purpose.

2. HTML

The HTML file is our default template for the application. Therefore, we combine both HTML files into one file by copying the whole <div class=”survey-wrapper”> of the output.html into the index.html. We use JavaScript below to display only one part of the application based on the URL.

Additionally, we need to remove all the JavaScript and CSS-imports from the HTML document as well as add some new identifiers. It’s important also to change the old identifiers of the output.html, so you don’t have the same identifier twice in one HTML document. Feel free to also edit the default text or document layout at this stage. For example, we decided to change the previous host input field to show the random IOTA address which we will later use. Therefore, we also make the input field read-only (readonly=”readonly”). Finally, we rename the index.html to dvote.html, just to improve the searchability of this file on the distributed web.

You can find our final HTML file here.

3. CSS

Since Webpack now takes care of our CSS import, we need to add the CSS import to the app.js like below and remove it from every CSS file:

import ‘../css/input.css’;
import ‘../css/main.css’;
import ‘../css/output.css’;
import ‘../css/style.css’;

We also remove the background parts inside the form-wrapper of the input.css and add the following line to the body inside the main.css.

background: linear-gradient(135deg, #2a99ef 20%, #52d9e5 80%);

This way we don’t have to upload an additional background image on IPFS, which should improve the loading time of the application. If you want, you can now remove the image folder since we don’t need it anymore. We also make the previous host input field grey, since its now read-only (see above) and make additional small changes. For example, we change the text alignment of the survey title and info to center (text-align: center;), but overall feel free to get creative here.

The final CSS files can be found here.

4. JavaScript

Now we take a closer look at the JavaScript. The final files can be found here.

4.1 Layout

First, we redesign the app.js file so that it reads the URL Parameters. Depending on these parameters, it will show the layout for creating a survey or voting. To achieve this we copy the getURLParameter.js from Dweb.page to our project. And since you’re here anyway, feel free to also copy the replaceAll.js. Once the window is loaded, we start the initLayout function:

async function initLayout() {
const urltitle = getURLParameter(‘title’);
…
if (typeof urltitle !== ‘undefined’){
voteLayout(urliotaAdd, urltitle, urloptA, urloptB);
} else {
createSurvey();
}}

This layout function then displays the appropriate elements (e.g., document.getElementById(‘divVoteLayout’).style.display = ‘none’;) as well as adds the correct logic.

4.2 Immutable backend

Next, we add an IOTA subfolder to the js-folder. The main reason why we use IOTA for the project is that transactions are feeless. Here we add the getHealthyNode, Iota and iotaConfig files of Dweb.page. For simplicity, we remove everything we don’t need for this project and integrate the external dependencies of these files. Furthermore, we change the getTransactionByAddress and vote function. A new function we add is the generateSurveyAddress function. This function makes sure that every new survey will get its own random and unique IOTA address.

Additionally, we add the IOTA and trytes library to our project, with

npm i iota.lib.js trytes

In the app.js we create a new instance of the Iota class:

const iota = new Iota();

We establish the connection to a random healthy node:

await iota.nodeInitialization();

As well as send the votes to the Tangle:

iota.vote(urliotaAdd, voteObj);

And load existing votes from the Tangle:

const transactions = await iota.getTransactionByAddress(urliotaAdd);
for (let i = 0; i < transactions.length; i += 1) {
awaitMessages.push(iota.getMessage(transactions[i]));
}

For information about IOTA feel free to take a look at the official documentation.

4.3 Signature system

For this part, we use the crypto folder of Dweb.page and integrate a signature system into DVote. Since we don’t integrate an additional login system here, it’s not super useful on its own, but it shows you how you can use the Web Crypto API for your own projects. You can take a closer look at the Dweb.page project to see how you can use it to encrypt information or store non-extractable private keys inside IndexedDB. Furthermore, the Web Crypto examples might be useful for your future projects.

For the Dweb.page compression of the signature key we need to add the big-integer NPM package:

npm i big-integer

In the app.js for voting we generate the keys and extract the public key with the following lines of code:

const sig = new Signature();
const keys = await sig.getKeys();
const publicHexKey = await sig.exportPublicKey(keys.publicKey);

And then create a valid signature with:

const signature = await sig.sign(keys.privateKey, JSON.stringify(voteObj));

Finally, we verify the signature of existing votes with the following line:

const isVerified = await sig.verify(await sig.importPublicKey(messages[j].publicKey),

5 Hosting

Let’s create the finished dvote.html inside the dist/html folder by running the following command:

npm run build

If you open Dweb.page, select the public sharing mode and drag and drop your dvote.html on it. That’s it! Your distributed voting application is hosted on the distributed web and can be accessed via any IPFS gateway and by adding the correct hash.

You can check out our version here and feel free to answer our test survey.

Let us know if you are interested in us providing a JavaScript library for developers based on this tutorial. Or help us to improve the underlying technology as well as the tutorial itself:

• Discord Server
• Dweb.page GitHub
• DVote GitHub

Tutorial: How to build a completely free Dapp was originally published in Pact Care on Medium, where people are continuing the conversation by highlighting and responding to this story.

While search neutrality might be open for discussion, it is pretty clear that Google’s centralized search engine with a market share of above 90 % and quarterly earnings of above 30 billion dollars are far from ideal. Monopolies not only are economically inefficient but also increase the chance of censorship and search bias.

If it comes to finding information on the distributed web, a centralized search engine seems counterintuitive, because it goes against the principles underlying the distributed web. That is why we are currently working hard to create the first fully functional, completely distributed search engine for our project Dweb.page.

Problem

Despite the earlier mentioned downsides of current search engines, we believe multiple reasons have led to difficulties in changing the existing model. At the same time, a distributed and fully transparent search engine for the Dweb comes with a set of challenges:

1. Speed: The speed of the distributed search engine needs to be at least as high as the current solutions, and there are a lot of problems with the transaction times based on distributed ledgers.
2. Device independence: Today more and more people are using mobile phones; the distributed search engine needs to run on PCs and mobile phones without any centralized backend.
3. Indexing: How to collect, parse, and store data to facilitate fast and accurate information retrieval in a distributed way and still ensure that people don’t create fake search entries?
4. Availability: How to ensure that distributed data is still available when requested? Especially since the data can be hosted locally and therefore only be available in certain time slots.
5. Monetization and incentives: How to finance the storage and continuous development of the tool? Without this monetization part figured out, it will be difficult for decentralized solutions to compete with existing centralized ones for example regarding human talent or partnerships/integrations, etc.

A potential solution

To ensure high speed and feeless transactions, it was clear from the beginning that distributed ledger technologies which are limited by either one of the two performance issues were not an option. Therefore, we chose the combination of IPFS and IOTA. IPFS is fulfilling the obvious role of a fast and distributed way to share and host files, whereas IOTA provides the necessary distributed database layer. It is important to notice here that the database only uses a part of the IOTA technology which is already fully functional and independent of future research work (e.g., regarding the coordinator).

This combination allows us to provide an experience which works on all kinds of devices. We even had a prototype running in the Internet Explorer. The unique feature is that we can deliver a fully distributed experience without the additional installation of any software since all the code is running inside a simple, completely open source web page, which by itself is distributed on IPFS. It also means every single user will run their own search engine, which is the ultimate distribution.

Inspired by this distributed interface, we are working on the following concept for a distributed search engine:

We assume two types of users, who we call Authors and Consumers (one person could fulfill both roles though).

Authors upload content on the distributed web via Dweb.page. If they want their content to be publicly found by others, metadata, which is signed by the Authors, is upload on IOTA. This way anyone can create their own metadata instead of a centralized indexing system. On top of it, this signature system would make it impossible to pretend to be someone else, which today happens for example with news stories or bank websites.

When Consumers open for the first time Dweb.page, they will start loading the most recent metadata in the background. Based on this metadata a search engine running locally provides the user with initial and fully transparent search results. These first searches by the user will automatically be used to subscribe to the potentially interesting Authors and this way load additional metadata. This can be seen as a social network for metadata, where Consumers “follow” the Authors. Advantages of the approach include on the one hand that users do not have to load the complete metadata of the entire web and on the other hand, that they can easily block a provider of malicious metadata (e.g., wrongly labeled content). Furthermore, without this subscriber/block model, people could start spamming the search engine.

Additionally, everyone who uses the search engine of Dweb.page will generate information about the availability of content. This means that if someone tries to download some content on the distributed web which is no longer available, the information will be passed to other users. If multiple Authors tell you that a file is no longer available, it’s automatically removed from your search results. If only one tells you about it, the file would still be listed in your search results to give you the option to check, if the Author doesn’t try to prevent you from accessing certain content by lying about its availability.

The last key, challenging, and often overlooked part for every distributed project is how to monetize and provide incentives to storage providers and developers of the distributed web. In a distributed and open source solution without any centralization, it is possible to circumvent any incentive model. That is why a lot of decentralized projects end up having a centralized layer. Furthermore, donation-based systems don’t seem to work well for subscription or long-term based business models. That is why we are considering creating a model benefiting all participants while maintaining complete transparency. The following picture illustrates how this potential solution would work:

The search market is well positioned for advertisement since, even without giving up any privacy, it is possible to show advertisement based on search terms. This advertisement revenue can then be split and be used on the one hand to provide a certain amount of free storage to Authors and, on the other hand, to support the Developer to improve the tool further. If you think for example about Google providing you 15 GB of free cloud storage and still earning billions quarterly, you get the idea that the above model might result in a completely free web for Authors! Also, it is important to point out that, a large share of the population is not against advertisement per se, but against the misuse of their personal data, which would be impossible based on this model.

Naturally, this model needs to be set up completely transparent on a distributed ledger. If this is the case, a normal contract between all participants might be sufficient at the beginning since you could easily sue the malicious parties (e.g., if money gets misused instead of invested into the infrastructure). However, this contract should also contain right from the beginning the option to change over time based on a voting system for example. Otherwise, a model like this would be unable to adapt to future developments, for example, storage prices might get so cheap that it makes sense to use the money for other purposes. This and other aspects of the system, like the quality of the provided storage or advertisement, might be difficult to integrate into smart contracts. Nevertheless, at a later stage, this setup should be replaced with fully automated smart contracts.

This article provides a view of our current research, and it does not constitute a finished product. We believe that we can only achieve this vision if we are transparent right from the start and we appreciate any feedback or contribution. Help us in achieving this vision:

• GitHub
• Discord Server

A Distributed Search Engine for the Distributed Web was originally published in Pact Care on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hosting a distributed webpage with Dweb.page

The Interplanetary File System (IPFS) is a peer-to-peer hypermedia protocol aimed to replace HTTP with a name-based system. One of the main use cases for this new technology is that it allows you to host distributed websites.

However, IPFS currently presents two major barriers when it comes to the setup of these distributed websites:

1. The name/address of the distributed website is far from human readable
2. The upload of pages isn’t easy, and most of the time the website loads slowly

The first problem will be addressed over the coming weeks, as part of an additional article around the search engine of Dweb.page. The current article will focus on how to host distributed web pages with Dweb.page in literally a couple of seconds!

There are several tutorials on how to do this (e.g. here or here). In these tutorials, you usually need to install IPFS on your computer, make sure that your website contains only relative links and upload the whole folder to your IPFS gateway (with ipfs add -r folder/). This allows your distributed website to load fast on your local gateway, but once your site is requested from a different gateway like ipfs.io/ipfs/, it takes quite a while to load the page.

The reason for this slow loading is because once your hash is requested and loaded from the public gateway (by entering ipfs.io/ipfs/yourAwesomeHash), it starts requesting other necessary hashes from the network (e.g. the hash containing the CSS or Javascript file). And even though the propagation of hashes through the IPFS network has been improving, it still takes a some time if your website is not fully distributed yet. This initial loading time is just something people aren’t used to. Additionally, if you click on a link, the whole process starts from the beginning, and if one part of your site, like the CSS file, is deleted from the IPFS network, the whole site will stop working.

The best way to solve this is to create a single page application (SPA) and put all the code into one HTML file. This way your webpage loads much faster on the distributed web and you don’t have any issues with links. Of course, creating a small hello world website by putting all the code into one HTML file is fine, but for a big project, you might want to use something else.

That is why for the development of Dweb.page we are using Webpack together with the HTML Webpack Plugin as well as html-webpack-inline-source-plugin. If you never heard of Webpack, there are tons of helpful tutorial out there, like the YouTube tutorial series by Ihatetomatoes.

One final note here. If you plan on creating a more advanced Dweb application, you probably don’t want to integrate a centralized backend. You should rather take a look at decentralized solutions based for example on OrbitDB, IOTA or any other distributed ledger.

Now, after you created your awesome webpage, we can host it on the distributed web. Just take the HTML file, select the public sharing mode and upload it on Dweb.page. That’s it. I bet you never hosted a distributed webpage or even a normal webpage so fast!

You now can request your website from any ipfs gateway, like https://ipfs.io/ipfs/, https://ipfs.infura.io/ipfs/ or https://ipfs.eternum.io/ipfs/ + your hash.

If you want to keep this file available, even though people might not constantly open it, you need to pin it to an IPFS gateway. We can help you with this, just send us the hash of your webpage, and we make sure it stays online. And since you are sending us an email anyway, maybe include some feedback/ideas for the further improvement of Dweb.page 😉

Tutorial: How to create your own distributed website in just a few seconds was originally published in Pact Care on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last tutorial we showed you how to host our service locally. Now we’re going to cover how you can set up your own IPFS node and be part of Dweb.page. It’s important to mention that you can use an IPFS node for a lot of interesting projects and ideas. So even if you have no interested in Dweb.page this tutorial might still provide some value for you.

The following is based on the great tutorial series by Carson Farmer.

Getting a server

To host an IPFS node online, you’re going to need an Ubuntu web server. Generally, you can choose between a lot of different companies for this. Our recommendation for an IPFS node is to look out for the data transfer pricing model because that will be the most expensive part of running your node. For example, AWS charges $0.09/GB which can be quite expensive, and it doesn’t help to decentralize the web if everyone is using AWS 😉.

We’ll be using the Cloud Server M with Ubuntu 18.04 by IONOS for this tutorial since they charge nothing for the data transfer and with the 100$ credit, you can test everything for free at the beginning. But there might be other even better solutions so feel free to use whatever you prefer!

Connecting to your server

We’re using PuTTY to connect to our server. PuTTY is a Secure Shell (SSH) client, which gives us access to the command line of our web server. You can download it here. Once you installed it, you need to know your DNS Hostname. On IONOS you find it in the cloud panel if you click on your server. Next, open PuTTY and enter your hostname. Make sure the port number is set to 22. You can now save this to open the connection in the future easily.

Now click on open and enter your name plus password. Depending on your service provider you either did create a password during the setup process, or you need to create pem file or create a new password first. If everything is correct you should see something like this:

Install IPFS

For installing IPFS on your server, we need to type quite a lot of Linux commands. We’ll present you the commands first, and the explain them a below. So, if you’re not interested in it, you can copy paste it into your command line.

wget https://dist.ipfs.io/go-ipfs/v0.4.18/go-ipfs_v0.4.18_linux-amd64.tar.gz
tar xvfz go-ipfs_v0.4.18_linux-amd64.tar.gz
rm go-ipfs_v0.4.18_linux-amd64.tar.gz
sudo mv go-ipfs/ipfs /usr/local/bin
rm -rf go-ipfs
ipfs init -p server

The wget command downloads the latest IPFS version on your machine. Then you unpack it with tar xvfz and remove the downloaded archive with rm. sudo mv then moves it to a different directory, and we remove the unpacked folder with rm.

echo 'export IPFS_PATH=/data/ipfs' >>~/.bash_profile
source ~/.bash_profile
sudo mkdir -p $IPFS_PATH
sudo chown root:root $IPFS_PATH

The above lines of code add our repo path to our bash profile to make the IPFS commands easily available in our command line.

ipfs init -p server
ipfs config Addresses.Gateway /ip4/0.0.0.0/tcp/8080

With ipfs init -p server you change the IPFS settings to the server profile, which are optimized settings for running IPFS on a web server. The second line makes our IPFS gateway public accessible.

sudo bash -c 'cat >/lib/systemd/system/ipfs.service <<EOL
[Unit]
Description=ipfs daemon
[Service]
ExecStart=/usr/local/bin/ipfs daemon --enable-gc --writable
Restart=always
User=root
Group=root
Environment="IPFS_PATH=/data/ipfs"
[Install]
WantedBy=multi-user.target
EOL'

The above code creates a service, which makes sure that IPFS is always running on our server. It also gives people write access to your Gateway, which is necessary for Dweb.page. This means that people can use your IPFS gateway to upload content. Usually, this is turned off by default, but people can always request files from your gateway, which is practically the same as uploading content to your gateway directly so that you can turn it on anyway (even if you’re not interested in using Dweb.page).

sudo systemctl daemon-reload
sudo systemctl enable ipfs.service
sudo systemctl start ipfs
sudo systemctl status ipfs

And finally, these commands setup our service and start IPFS. The sudo systemctl status ipsf command checks the status of your IPFS installation. If everything is working, it should look like this:

Setting up a custom domain

You probably want to have your IPFS server running behind a secure public domain, like https://example.com. The first thing you need to do is to buy a custom domain or use a subdomain and point it to the IP Address of your server. Next, we install Nginx on our server with the following commands:

sudo apt-get update
sudo apt-get install nginx

If everything worked, you should see the image below if you open your domain address:

HTTPS

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get install python-certbot-nginx
sudo certbot --nginx -d pactcare.online

The first commands will install the certbot on your web server and make it easier for you to get Let’s Encrypt certificates (HTTPS) for your website. After the last command, a dialog will start inside your command line, which guides you through the setup process. It’s generally recommended to select option 2, which enables automatic redirect.

If you reload your domain now, you should be connected to it via https instead of HTTP.

Update configurations files

Now we need to change our IPFS setup to make it work with https. Therefore, we can use FileZilla. After you have installed it, you can easily establish a connection to your server by opening the Site Manager (File -> Site Manager). It should look similar to the image below:

Under the general tab, you need to change your connection to SFTP and enter your IP address in the host field. Furthermore, you probably need to switch to “Ask for password” and enter your Username. Now you can connect to your server. The first time you establish a connection you also need to agree that you trust this host.

Next, you navigate to /etc/nginx/sites-available. Here we’re going to replace the default config file by our own version below:

In the above file, you need to replace EXAMPLE.COM with your domain. The config is also set up in a way that people can use your Gateway to upload files up to 1 GB. If you don’t want this, simply remove all appearances of client_max_body_size 1000M. Now let’s finally test everything by opening Dweb.page on your IPFS node, for example by entering your domain name plus “/ipfs/SSFQNEKDAMMAJSTMLRPIHSKZMHQTMYITPPLUWLOPYKS9K9YDGJZKTNQHJVD9YGZFOVZKAZHDIDMFWJGUYFZOTSAS9C/”.

If you want to participate in Dweb.page officially, all that is left to do is to send us an email at info[at]pact[dot]care or join or discord server so we can integrate your side on Dweb.page.

Currently, we share the IOTA donations equally among all participants at the end of every month. In the future, we might set up an advertising or long-term storage payment model to make it more attractive for IPFS nodes to participate.

Tutorial: Host your own IPFS node and help the next generation of web was originally published in Pact Care on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Reason

Chances are that when you read or hear about distributed ledger technology (DTL) or blockchain, privacy and security concerns come to your mind. One reason for this might be the well-known illegal use cases of bitcoin at the beginning (e.g. Silk Road). Silk Road was an online black market and one of the first real use cases for bitcoin, best known as a platform for selling illegal drugs. However, looking behind these initial illicit use cases, the technology itself can actually lead to significant improvements in making future digital transactions more transparent.

Take for example the process of medication approval. In general, it involves multiple parties with different roles and objectives (e.g. patients, pharmaceutical companies, research institutions, clinicians and governments). The successful launch and use of a new drug requires that all of these parties trust each other along this process.

However, numerous issues have been reported such as:

1. invalid consent collection due to unapproved forms or missing information (affecting almost 10% of the trials, according to the FDA) [1]
2. document fraud and [2]
3. untrustworthy underlying research (see for example “Why Most Published Research Findings Are False”) [3].

Distributed ledger offers a third party that anyone can trust, and no one can influence once the information is uploaded there. For example, once the patient gives consent to a study, this can be logged on the ledger and nobody can alter or change this log entry anymore. You could do the same with the anonymized results of the trial.

This might sound like a niche case, but it’s actually not. Every time you have a situation in which multiple parties don’t fully trust each other but need to work together, distributed ledger offers the perfect solution. Other use cases that could highly benefit from this additional transparency are for example: immutable tracking within supply chains, peer to peer energy trading, real estate records, or simply digital identity.

The Technology

Since we believe that decentralized logging of data needs to take place feeless and almost instantly, we decided to use IOTA for the logging system of our prototype pact.online. The existing problem of long-term storage of the data in IOTA can be easily resolved by setting up a decentralized backup system (for example an IPFS cluster) or the involved parties just keep a copy of the “official agreement” since it’s probably in their interest anyway.

To make sure the log entry is created by the right person, we sign every log entry with a digital signature. Together with the public key of this transaction, you can prove to others that you are the creator or receiver of this transfer. Therefore, we’re currently testing the Elliptic Curve Digital Signature Algorithm (ECDSA) Secp256k1 to digitally sign the content of the message. It’s the same system Bitcoin uses [4]. This signature algorithm allows us to include the log information as well as multiple signatures in one single IOTA transaction.

Additionally, the content of the transfer is clearly identifiable by the unique hash of the file included in the transaction log. This also means that if you show somebody else your public key, you also can prove that you are in possession of this file.

So, for example, if you have a great idea, you write down your thoughts on a digital document. If you upload this document, you can prove to everyone in the future when you initially had the idea. This might, for example, be interesting for you if you want to patent something.

The Authentication Problem

But there is a drawback that I haven’t mentioned yet: what if you tell somebody else your public key in person? This person can later claim to be the owner of this particular transfer (as long as this person doesn’t have access to your file, you can easily disprove this claim). What you would normally do is to present your public key to a trusted authority first, which can then tell anyone that you are the rightful owner of this transaction.

However, we have set ourselves the goal to create a truly decentralized web application, which makes the development process a lot more complicated, but also has great benefits (check my previous article). In a decentralized setup, you don’t want to depend on this trusted authority. This is why we suggest publishing this public key on a channel like Twitter as an interim solution, which immediately tells a lot of people who the rightful owner of the file is. The next step includes the use of a digital identity that also might be stored on IOTA directly.

The Data Integrity Problem

Let’s come back to the example from the beginning: If a pharmaceutical company uploads information to the distributed ledger system, who ensures that the uploaded data, which consists of unique hash and the log information, is actually correct? Maybe the company somehow created a log entry containing a different, more promising study (another file hash) or added a wrong timestamp.

The most secure answer is that the involved parties simply check the logging information after it’s uploaded. If there is an issue with the data, you immediately know who is responsible for the missing or wrong information. But this additional control process might also result in further security issues when people forget to check the integrity of the data and it definitely means extra work for the participating parties.

That’s why we try to make the forging of pact.online created log entries as difficult as possible. Since the website is completely running in your browser we can never fully prevent you from changing the code or blocking log entries. It’s comparable to a car: you can do with it whatever you want to after you bought it, e.g. manipulating the mileage indicator. But what we can do, is to make this process as complicated as possible for people with bad intentions. Therefore we use different Javascript obfuscation techniques and hide additional signature keys in the code. As mentioned before, this never results in a situation in which you are 100 % sure about the integrity of the data without looking at the actual log entries. In cases in which I do not fully trust the receivers and the content is important to me, I simply check the entries. Btw. something which you can’t do with the mileage indicator because there aren’t any public immutable logs.

Next steps

As described in the beginning, the use cases of this kind of technology go far beyond a simple file transfer. For a lot of specific use cases, it might make sense to integrate a system like this into an established and partly centralized software solution. In this case, you can easily set up a login system and the identification process can be resolved a lot more user-friendly. That’s why pact.online is only our first prototype to prove that the technology actually works.

If you are interested in working with us on a concrete use case, feel free to reach out to us.

The biggest value of a distributed ledger is transparency was originally published in Pact Care on Medium, where people are continuing the conversation by highlighting and responding to this story.

For those who have never heard of the InterPlanetary File System (IPFS), here is a quick introduction by Wikipedia:

“InterPlanetary File System (IPFS) is a protocol and network designed to create a content-addressable, peer-to-peer method of storing and sharing hypermedia in a distributed file system.”

Let us explore IPFS through an example. At present, we use the combination “https://www” plus an address to find information on the internet. This is a location-based system. It works in a way that resembles saying to someone that they can find a copy of a book at the library in Alexandria, on the second floor, section 2, shelf number 5. However, the same information — other copies of this book — may be found at different, perhaps even nearer locations, but unless you specifically know where to search for, you will not find this information.

The fundamental difference with IPFS is that it uses a name-based system. The name is a unique “hash”, which is a combination of letters and numbers. This is how a real-world hash looks like: QmaSpmvTr68z3EgTp2XFZdBzc1HwNPQXWHyF34rpctJgCs. To illustrate how this impacts our previous book example: unique hashes allow a person to search specifically for the information they are looking for (i.e. title of the book). Any individual who has this information can provide it — independent of their location. Usually, this means that the person can find a place much closer than the library of Alexandria to get this information, saving valuable resources and time. If you want to learn more about it, here is a more detailed yet digestible article: https://medium.com/@ConsenSys/an-introduction-to-ipfs-9bba4860abd0. For our use case, just replace Ethereum with IOTA.

Now one of the biggest advantages with a name-based system is that you can create a complete distributed web application (links don’t point to specific locations anymore), that can run on every server, even on your local machine. That’s why we will show you how to run our Dweb.page on your local computer, which means you can share files end-to-end encrypted with a transparent IOTA based logging system without trusting any web server.

The first two steps below describe the current process of setting up IPFS on your local machine. We expect that this process will take place automatically in the future: there is already a browser extension under active development that simplifies this.

Step 1: Install IPFS

First, you need to download the go-ipfs client for your operating system. At the time of writing, you can do this using the following link: https://dist.ipfs.io/#go-ipfs

Next, extract the zip file. No need to click on the EXE file to install it or anything else at this stage.

Step 2: Start IPFS

Second, open your command line. On Windows, you can search for the command prompt by typing cmd in the search tool in the lower left corner. On a Mac, you need to search for the terminal. In the command line, you need to open the go-ipfs folder. You can do this by copying the address in your explorer (right click on it -> copy address):

Next, you need to type the cd command (change directory) plus the address in your command line, for example:

The process is similar on Mac.

All that is left to do in this step is to set up your IPFS installation by typing:

ipfs init

And get everything up and running with:

ipfs daemon --writable

If everything works correctly it should look similar to this:

Step 3: Start sharing

Third, just open your preferred browser and type http://localhost:8080/ipfs/ plus the most recent hash of Dweb.page. This is basically like asking people on the street for the specific version of Dweb.page. For example, at the time of writing the whole address should look like this:

http://localhost:8080/ipfs/QmUheca9RxWkN31vEdzP7DFgrfonUPzCyq3gkenD9sJTuG/

Now it will take some time to load the page. Once the page is loaded you can start using Dweb.page on your local machine! And the great thing is, that if the receiver of your file starts an IPFS server on their own computer, they can simply open your access link and download your file directly from your computer (might take some time).

Future perspectives

At present, we imagine that this setup has two drawbacks:

1. Currently, the person who should get the file probably knows little to nothing about IPFS and
2. You both might not run your IPFS servers at the exact same time.

To address these issues, we will show you in the next tutorial how to host your own file sharing system permanently online.

And if you’re not interested in setting up your own IPFS server at all, you can always just open Dweb.page, which will automatically redirect you to one of the participating IPFS servers. This way, you and your recipients can take advantage of all the benefits of simple, decentralized, fast and highly secure IPFS-based file sharing on your pc.

Tutorial: How to host your own distributed file sharing service on your pc was originally published in Pact Care on Medium, where people are continuing the conversation by highlighting and responding to this story.

When you open Google’s privacy policy you can read the following statement:

“When you use Google services, you trust us with your data.”

This is probably more honest than a lot of other companies. But DO you really trust all these companies with your data?

Your personal data is becoming an increasingly valuable asset for many companies (sometimes regarded as the new oil). Additionally, your personal data might not be as secure as you think (e.g. Equifax breach or Facebook privacy scandal) nor as confidential as you’d hope. Let’s be honest: how exactly do Facebook and Google earn money?

Okay, to stick with honesty here, until now I was using Google, Facebook and Co every day and I’m not using any of the more secure alternatives (like searchencrypt.com or minds.com, maybe I should switch). That’s because I think my search terms aren’t too important and I’m also quite lazy. However, this changes when it comes to more sensitive data. If someone asks for information about my bank account or a copy of my passport, I probably wouldn’t share this data with everyone (keep in mind Google might already know this stuff based on my search terms). So, to summarize there is some data I’m giving away for free to use all these cool technical gadgets and other data which I don’t give away and that causes me to sometimes live in a technical stone age (fax machine 📠, I am looking at you!).

Now, what if there was a way that allowed you to still enjoy the use of software without trading your privacy for it? Well, there may be a solution on the horizon. I’m talking about end-to-end encrypted decentralized solutions, where nobody except yourself is in control of your data. With this goal in mind, we developed a file-sharing tool called Dweb.page that aims to make data sharing really simple and secure.

If you upload your file on Dweb.page it will be completely encrypted 🔒 inside your browser (AES256-GCM) on your local device. This means all the information which is uploaded to our server is already fully encrypted thanks to the Web Cryptography API. You wonder why you should trust us? Good! Feel free to open the developer console and take a look at our code. There is nothing hidden from you. It’s all running in your browser. Furthermore, the server isn’t a simple server, it’s an IPFS node (hopefully soon a decentralized cluster) which shares all data with the rest of the IPFS network.

Here’s an example to make the benefits of decentralization even more clear. Imagine you load some data on a server and you wish to store it for a longer period of time. Later, if you want to get all your data back, the owner of the server could decide to charge you a pricey amount 💵 for it. If this would happen, you can simply request your data from any other publicly available IPFS node because of the decentralized storage of data! Another benefit is that browsers, such as Firefox, have started to support IPFS. So instead of going to a website, you can practically request this file from every network participant.

In addition, certain laws and regulations dictate that a log should be kept of your shared information. A decentralized third party keeping track of these transactions may then make sense. In this case, making sure that the decentralized transaction logging system is secure and immutable is important, where you have a fixed address to look up the logs (with IPFS the address would change with every new log entry) and it’s not possible to easily delete this log entry. Therefore, we are using the network (called tangle) of a distributed ledger technology called IOTA.

So, there you have it: a decentralized file sharing service, which (except for some early bugs) works as fast as any other file sharing service. And I’m quite optimistic that this is only the beginning.

Please distrust us, test Dweb.page! 😉

A new approach for file sharing you don’t need to trust! was originally published in Pact Care on Medium, where people are continuing the conversation by highlighting and responding to this story.

During the Blockchain mobility hackathon, I had lots of great discussions with different people about IOTA. However, I sometimes got the feeling that most people still believe it will take like 5 or 10 years for IOTA to be used in real-world applications. I definitely can’t predict the future, but I think that a lot of problems, which were mentioned around IOTA can be solved today. For example, the project we developed during the hackathon “Pac-Man on wheels” (see our project on Github) can in my opinion easily be used in a real-world application right now.

In this article, I will list some of the problems mentioned during the hackathon as well as possible solutions.

Problem 1: MAM isn’t finished and therefore you can’t exchange data securely

MAM (Masked Authenticated Messaging) is in an early stage. It’s not proven to be completely secure and it’s missing some key components like a key exchange. However, there are plenty of secure asymmetric cryptography systems out there, like RSA and all of them can be used together with IOTA. So, if you completely trust these systems you can start using them right now!

The reason why we decided to use NTRU in our project “Pac-Man on wheels” is simply that we wanted to use a quantum secure encryption. We believe anyone who is currently using an encryption systems should think about applying a quantum secure systems no matter what technology or cryptocurrency you are using. See for example “How secure will our data be in the post-quantum era? It’s the end of modern cryptography as we know it, and we feel fine.“

Problem 2: You can’t exchange huge amounts of data efficiently with IOTA

It’s true that you need to do multiple proof-of-works for uploading a huge amount of data and that this process is inefficient compared to the current state. But why would you want to upload your complete data to the tangle? It’s enough to upload just a link to your data and if you use IPFS to upload a unique hash instead of the link this solution is also completely decentralized and future-proof.

If you want to test IPFS together with IOTA feel free to use my public IPFS gateway. You can even use the following API to pin content, see https://ipfsnode.de (for testing only ⚗️). If you’re a C# developer take a look at the Chiota Code as well as my wiki entry.

Problem 3: You won’t get paid for your data with IOTA because you can’t setup smart contracts

Qubic is at an early stage and you can’t use it right now in a productive system. However, the great thing about IOTA is that you don’t need smart contracts for most IoT use cases. Imagine if you want to sell some data, which is valued at 1€. With IOTA, you can offer an interested party a first part of the data, for a portion of the value (e.g 1 cent). If you get the money via IOTA microtransactions you can continue to offer the next part of the data (worth another 1 cent for example), if not, you simply stop the transaction, and you have lost 1 cent. A system like this can easily be set up today.

Problem 4: IOTA isn’t decentralized and potentially never will be

At the moment, the tangle still has a centralized coordinator to be secure against attacks. This way you can argue that the system isn’t completely decentralized. Since the details about the potential solution called “Network-Bound Proof-of-Work” aren’t fully published yet (you can take a look at the “Radio Resource Testing” part of the this paper if you’re really interested in it), I agree that it’s difficult to completely trust in this explanation at this stage. However, in my humble opinion, there is more than one solution to this problem, which at least could work as a potential answer for the current setup. For example, if it turns out that the “Network-Bound Proof-of-Work” doesn’t work, you can simply decentralize the coordinator (similar to EOS). Furthermore, there are already other concepts for direct acyclic graphs researched (e.g. SPECTRE or Algorand), which might have interesting solutions for IOTA as well.

IMHO: That’s why I strongly believe it’s only a matter of time before IOTA is completely decentralized and I think you can start using IOTA for decentralized data exchange today!

Why you can start using IOTA for decentralized data exchange today! was originally published in Pact Care on Medium, where people are continuing the conversation by highlighting and responding to this story.