HOSN-app/thesis/content/05-proof-of-concept/technology-decisions.tex

In order to meet the requirements of the concept best, a detailed consideration of the technology to be used is necessary. These decisions include the application framework itself and libraries and protocols for data exchange in a \ac{P2P} network. Basically, there are two conceivable approaches for the \ac{P2P} network:

\begin{itemize}
	\item The creation and buildup of a separate \ac{P2P} network connecting the hybrid clients
	\item The use of an existing \ac{P2P} network for own purpose
\end{itemize}

\subsection{Creation of a \ac{P2P} Network}
\label{sec:create-p2p-network}
The advantage of having an extra \ac{P2P} network is that it is completely under control. Accordingly, it can be designed to fit exactly to the use case and require little or no compromise. However, setting up a \ac{P2P} network is a big challenge and some hurdles must be overcome. These challenges include peer discovery (how peers find each other), global data exchange over the Internet and data storage, and availability of the stored data. In addition, all these requirements must scale. It should work for \ac{P2P} networks with only a few peers and also for a few thousand or even more peers.

In the following, we discuss two options to create the \ac{P2P} network:

\begin{itemize}
	\item The use of an established standard such as Wi-Fi Dircet and \ac{WebRTC}
	\item The use of a library (e.g., Hive2Hive, Yjs) to create a dedicated \ac{P2P} network
\end{itemize}

\subsubsection{Wi-Fi Direct}
\label{sec:wifi-direct}
Wi-Fi Direct is a standard (IEEE 802.11) for data transmission between two WLAN terminals. There is no need for an access point between the two devices. However, the distance that may lie between the two peers is thus limited. Without obstacles, which contribute to the attenuation of the signal, a distance of up to 200\,m is possible \cite{wifiXXXXdistance}. However, the requirement for the \ac{P2P} network to expand Twitter is different. Users can be scattered around the world and may be online through the mobile network. There is no \ac{P2P} connection via Wi-Fi Dircet possible in this case.

\subsubsection{\ac{WebRTC}}
\label{sec:webrtc}
\ac{WebRTC} is an open standard\footnote{https://www.w3.org/TR/webrtc/} that provides various communication protocols for real-time communication between two or more peers. Above all, \ac{WebRTC} is popular for its ability to easily perform video calls, as known from Skype, in the browser without a server. Additionally it allows file transfer between peers. In a separate \ac{P2P} network, data could be exchanged between the clients. However, the connection between the clients is complex, beside two peers also a \ac{STUN} server and optionally a \ac{TURN} server is involved. Furthermore, it is unclear whether the system scales.

\subsubsection{Yjs}
\label{sec:yjs}
The JavaScript library Yjs\footnote{https://github.com/y-js/yjs} describes itself as \enquote{a framework for offline-first \ac{P2P} shared editing on structured data-like text, richtext, \ac{JSON}, or \ac{XML}}\cite{yjsXXXXrepo}. The library takes care of solving synchronization conflicts when editing distributed files. By choosing a connector, you can set the protocol for the communication between the peers. There is the possibility to use \ac{WebRTC}, \ac{XMPP} or websockets, but with some connectors running a server is a prerequisite. Further extensions can be used to supplement a database and data types, but the focus here is on the joint editing of data by multiple peers. For all connectors, the authors of the library recommend using an own server. Yjs is released under the MIT license.

\subsubsection{Hive2Hive}
\label{sec:hive2hive}
Hive2Hive\footnote{https://github.com/Hive2Hive/Hive2Hive} is a Java library for \enquote{secure, distributed, \ac{P2P}-based file synchronization and sharing}\cite{hive2hiveXXXXrepo}. There is no less promise than \enquote{a free and open-sourced, distributed and scalable solution that focuses on maximum security and privacy of both users and data}\cite{hive2hiveXXXXrepo}. In order to be able to use Hive2Hive globally via the Internet, it is necessary to operate at least one relay peer - five are recommended for sufficient data replication \cite{hive2hiveXXXXguide}. Since a permanent \ac{TCP} connection between peer and relay peer is maintained, the power consumption is quite high. Constant \ac{TCP} connection can be avoided by using Google Cloud Messaging. However, Google has already discontinued this service. Moreover, the development of Hive2Hive was stopped in March 2015 too, there is currently no solution to this problem. Hive2Hive is released under the MIT license.

\subsubsection{GUN}
\label{sec:gun}
In 2014, Mark Nadal began working on a decentralized database called GUN. GUN\footnote{https://gun.eco} is written in JavaScript and will be further developed by the community as an open source\footnote{https://github.com/amark/gun} project. It is licensed under the Apache License 2.0, so free use is allowed. The \ac{P2P} database exists only within a browser and synchronizes itself with other peers over the Internet. It has offline support, so changes are automatically synchronized and merged as soon as a connection is established. The data are stored in a graph structure in the local storage of the browser. For connecting peers among each other, at least one relay server is required.

\subsubsection{OrbitDB}
\label{sec:orbitdb}
The open source project OrbitDB\footnote{https://github.com/orbitdb/orbit-db} is a serverless, distributed, \ac{P2P} database on top of \ac{IPFS}. The data are stored in \ac{IPFS} and \ac{IPFS} Pubsub is used to sync the database automatically with other peers. Various types of databases are provided like log, feed, key-value, and counter. There is a JavaScript library for usage in browsers and NodeJS which is currently in alpha stage. OrbitDB is released under the MIT license and therefore free to use in private and commercial projects.

\subsection{Using an Existing \ac{P2P} Network}
\label{sec:using-existing-p2p-network}
As mentioned in the previous section, setting up your own \ac{P2P} network involves a number of challenges. If you use an already existing \ac{P2P} network for your own purpose, these challenges can be elegantly avoided. For this purpose, however, a suitable \ac{P2P} network must be found whose properties and possible uses meet the requirements of the hybrid \ac{OSN} client. In the following, various \ac{P2P} networks are considered and examined for their usability for a potential deployment to extend an \ac{OSN}.

\subsubsection{Blockchain}
\label{sec:blockchain}
In a blockchain, the private data of the users could be stored encrypted and shared with other users. The corresponding smart contracts would have to be designed for this purpose. Regardless of the blockchain, executing the smart contracts to store the data, however, consumes a token. The user has to get the tokens beforehand and deposit them in his wallet. To avoid this, a test network (e.g., Rinkeby at Ethereum) could be used. A test network would have the advantage that tokens could be made available to the user free of charge and that the execution of the smart contracts would thus also be free. However, test networks are used to test new software updates and usually do not offer the same security as the main network. They should only be used to test applications before releasing them to the main net. In order to protect against abuse, token requests are usually limited and take a while until they arrive in the user's wallet. Besides, it is often required to post specific content in a social network or to perform another task.

A solution based on a blockchain increases complexity for the user. Since the hybrid solution was required to keep the complexity and additional effort as low as possible, such a solution using a blockchain was categorically excluded.

\subsubsection{\ac{IPFS}}
\label{sec:ipfs}
\ac{IPFS}\footnote{https://ipfs.io/} is a distributed file system that brings together the ideas of other successful \ac{P2P} systems (DHTs, BitTorrent, Self-Certified Filesystems (SFS) and Git) \cite{benet2014ipfs}. The original idea for \ac{IPFS} came from Juan Benet in 2014. Protocol Labs\footnote{https://protocol.ai}, founded by Benet, now manages the open source project \cite{benetXXXXlinkedin}.

The goal of \ac{IPFS} is to connect all computing devices to the same file system. The basis for this is a \ac{P2P} network where the data are distributed and stored. Instead of a location-oriented approach as used in \ac{HTTP}, \ac{IPFS} uses a content-oriented protocol. A cryptographic hash function generates a hash (content identifier) for each file, which can be used to find the file on the \ac{P2P} network using a \ac{DHT}. Unnecessary redundancies are avoided in this way, as the content is only stored once and purposefully replicated. However, deleting data is impossible in \ac{IPFS}. Only if all peers who have stored copies of the file leave, the file can no longer be recovered. Decentralization allows a file to be retrieved from several peers in parallel, thus making the download faster. Besides,

Due to its characteristics, \ac{IPFS} is an ideal complement to the blockchain and the creation of \acp{dApp}. Large amounts of data can be stored out of \ac{IPFS}, and the address hash can be written into the blockchain. This principle is used for example by AKASHA and Peepeth.

\ac{IPFS} clients are available for Max OS X, Linux and Windows. Besides, there are client implementations in JavaScript and Go to include in other applications.

\subsubsection{Conclusion}
First, the goal was to build a \ac{P2P} network among the users of the Hybrid \ac{OSN} app to use it for secure data exchange. Due to its limitation to local use, Wi-Fi Direct was excluded as a possibility. The need for \ac{STUN} and \ac{TURN} servers and the uncertainty regarding the scalability of the system led to the elimination of the \ac{WebRTC} standard as the basis for communication. While Yjs made a promising impression, the use case ultimately did not fit into a hybrid solution for \ac{OSN}. The Java library Hive2Hive dropped out because of the need for at least one, ideally five, relay servers. Furthermore, the library is discontinued since 2015 and therefore questionable to what extent it is compatible with the current Android \ac{SDK} version. Since the potential solutions for building an own \ac{P2P} network are limited or outdated, the idea of an exclusive \ac{P2P} Hybrid \ac{OSN} network was discarded.

As a further solution strategy, the use of third-party services from Google Firebase\footnote{https://firebase.google.com/} and PubNub\footnote{https://www.pubnub.com/}, which provide the functionality of a database, was considered. To a limited extent, the services offered can be used for free. From a particular size of the user base and correspondingly large load, costs for the service use would rise. In order to avoid these charges from the beginning, the idea of using these commercial third-party services was rejected.

The \acp{dApp} AKASHA and Peepeth introduced in Chapter \ref{sec:related-dapps} use the Ethereum blockchain as a database and \ac{IPFS} for data storage. This technology combination meets the technical requirements of a hybrid solution. However, the use of a blockchain was excluded due to the usage costs and complicated configuration for the user (wallet, acquisition of tokens). Nevertheless, \ac{IPFS} is an excellent way to store data decentralized. Accordingly, only a replacement for the database functionality was needed. With OrbitDB and GUN, two technologies came into closer selection for use in Hybrid \ac{OSN}. Since OrbitDB offers database functionality based on \ac{IPFS}, it was initially preferred. However, when using Cordova (the basis of the used application framework Ionic), the JavaScript implementation of \ac{IPFS} and the OrbitDB library, an error occurs. This error has been known for some time but is still unsolved due to its high complexity and the comparatively small number of affected users. Therefore, the final choice was GUN to implement the database functionality of the hybrid solution. At the time of the decision for GUN, it was assumed that the relay server used for testing purposes in the official GUN tutorials could also be used as a relay server within Hybrid OSN. However, later it turned out that the use is very strongly restricted and the limit is already reached after three private tweets. For this reason, a separate relay server was set up as a workaround. GUN provides the necessary code as well as the one-click setup at Heroku\footnote{https://www.heroku.com/} on Github.

\subsection{Application Framework}
\label{sec:application-framework}
With the Android \ac{SDK} apps for Android can be written in Java, Kotlin, and C++. Tools of the Android \ac{SDK} compile code, data, and resource files to an executable \ac{APK}. This way, only device-specific applications for the Android operating system can be created. \cite{androidXXXXfundamentals}

The open source framework Ionic\footnote{https://ionicframework.com/} is used to create hybrid apps and \acp{PWA}. A hybrid app combines the advantages of a native app with those of web applications. With \ac{HTML}, \ac{CSS}, and JavaScript, this framework can be used to design platform-independent applications (including Android and iOS). The core of Ionic is based on the JavaScript Framework Angular and Apache Cordova, which serves as a bridge to access sensors and functions of the device. Ionic can be used free of charge and is published under the MIT license, so private and commercial use is permitted.

Comparing the standard way of programming an Android app to the use of Ionic, the platform independence and the JavaScript language are the two main advantages. With Ionic, the same code can be used to create apps for the majority of mobile operating systems. Additionally, as \ac{PWA} the app runs in every modern web browser. The previously defined requirements of a hybrid solution demanded this independence, thus Ionic is a good match. Regarding the programming language JavaScript, many projects in the field of \acp{dApp} and decentralization in general provide only libraries for JavaScript (e.g., GUN). Besides, JavaScript is the language to write add-ons for browsers. Even though Ionic cannot be used to create browser add-ons, the used JavaScript libraries are able to do so. Hence, the same technology could be used to deliver clients to all popular environments.

With React Native\footnote{https://facebook.github.io/react-native/} and NativeScript\footnote{https://www.nativescript.org/} there are comparable frameworks to Ionic. They also use JavaScript and are used to create hybrid apps for several environments. But the provided components to create the user interface are most promising with Ionic and the initial learning barrier is low compared to the other two. Because of these advantages, Ionic was finally chosen for programming the Hybrid \ac{OSN} client app.