fix missing acronyms

thesis/abbreviations.tex

@@ -36,6 +36,7 @@
 	\acro{TCP}{Transmission Control Protocol}
 	\acro{TURN}{Traversal Using Relays around NAT}
 	\acro{TTL}{Time to Live}
+	\acro{URL}{Uniform Resource Locator}
 	\acro{W3C}{World Wide Web Consortium}
 	\acro{WebRTC}{Web Real-Time Communication}
 	\acro{XML}{Extensible Markup Language}

thesis/content/02-background/dapps.tex

@@ -6,7 +6,7 @@ An interpretation of what Web 3.0 is, is all about decentralization, hence it is
 
 \subsection{Characteristics of a \ac{dApp}}
 \label{sec:dapp-characterisitics}
-As with client-server applications, a \ac{dApp} is divided into front and back end. The main difference is that the back end is not represented by a centralized server and thus a single point of failure, but by code that is executed in a decentralized P2P network. In the back end so-called smart contracts are used to perform logical operations, and instead of a database, a blockchain is used. The front end can be created either as an app or website, but it is necessary that calls can be executed from the front end to the back end.
+As with client-server applications, a \ac{dApp} is divided into front and back end. The main difference is that the back end is not represented by a centralized server and thus a single point of failure, but by code that is executed in a decentralized \ac{P2P} network. In the back end so-called smart contracts are used to perform logical operations, and instead of a database, a blockchain is used. The front end can be created either as an app or website, but it is necessary that calls can be executed from the front end to the back end.
 
 Johnston et al. and Siraj Raval name the following four criteria for a \ac{dApp} \cite{johnston2015dapp,raval2016decentralized}:
 

thesis/content/04-concept/requirements.tex

@@ -2,7 +2,7 @@ The solution should meet specific functional and non-functional requirements so
 
 \textbf{Functional requirements}:
 \begin{itemize}
-	\item \textbf{Standard functionality}: With the hybrid solution, all standard functionalities of the \ac{OSN} should be unrestrictedly usable. Otherwise, the user would be forced to continue using the original client. The parallel use of two clients for the same OSN is not user-friendly and would be an argument against the use of the restricted hybrid client.
+	\item \textbf{Standard functionality}: With the hybrid solution, all standard functionalities of the \ac{OSN} should be unrestrictedly usable. Otherwise, the user would be forced to continue using the original client. The parallel use of two clients for the same \ac{OSN} is not user-friendly and would be an argument against the use of the restricted hybrid client.
 	\item \textbf{Client-side solution}: Since there is no control over the \ac{OSN}'s servers and software, changes can only be implemented on the client side. The alternative Facebook client app \enquote{Friendly for Facebook} for example changes the design on the client side and removes advertisements.
 	\item \textbf{Data sovereignty}: The user can actively decide whether his data is stored on the \ac{OSN}'s servers or exchanged with other users via a private, secure channel. This implies that any functionality and the associated data exchange can also be carried out in a private, secure way. The user thus gains sovereignty over his data and can decide for himself whether to entrust it to the \ac{OSN}.
 	\item \textbf{Authorized data access}: Especially the service provider of the \ac{OSN} should not have access to the private data of a user and should under no circumstances be able to relate them to him. As in the \ac{OSN}, the author himself should be able to determine with which users he shares his private data and grants them access.
@@ -16,7 +16,7 @@ The solution should meet specific functional and non-functional requirements so
 \begin{itemize}
 	\item \textbf{Minimal additional effort}: Installation, configuration, and operation should be as simple as possible. Increased complexity is an additional barrier to the acceptance of the solution. All users of the \ac{OSN}, especially technically inexperienced users, should be able to use the hybrid solution. For the success of the hybrid solution, wide distribution is essential, so no user groups should be excluded.
 	\item \textbf{Minimal side effects}: There should be no limitations for regular users who do not use the hybrid solution. Cryptic messages, disturbing content and other disturbing elements should be avoided. Annoying messages could lead to the user being blocked by other users or cutting off contact with them.
-	\item \textbf{Free service}: Since the use of all significant OSNs is free of charge the user also expects the free use of a hybrid solution. Costs would have a deterrent effect in this use case and prevent the user from accepting the solution.
+	\item \textbf{Free service}: Since the use of all significant \acp{OSN} is free of charge the user also expects the free use of a hybrid solution. Costs would have a deterrent effect in this use case and prevent the user from accepting the solution.
 	\item \textbf{Compliance with policies}: By registering, the user agrees to the terms of service/use. It is important not to violate these conditions; otherwise, the user would have to bear the consequences. The severity of the consequences depends on the respective terms of use and the type of violation. For the hybrid solution, it is therefore essential to adhere to the \ac{OSN} terms of use as well. Otherwise, legal use is not possible.\\
 	The Twitter Terms and Conditions allow the crawling of content within the rules set in the robots.txt file \cite{twitterXXXXtos}. Facebook completely prohibits the use of automated methods, thus excluding the possibility of crawling \cite{facebookXXXXtos}. Compliance with the guidelines therefore also directly restricts the possibilities of technical implementation. 
 	\item \textbf{Good user experience}: The user should be offered the best possible user experience to increase the acceptance for the solution. A bad user experience causes frustration and will in the long run not lead to success of the hybrid solution. Good user experience includes:

thesis/content/04-concept/restrictions.tex

@@ -1,7 +1,7 @@
 When designing the hybrid \ac{OSN}, there are some limitations that need to be considered, for which appropriate solutions have to be found. These restrictions include:
 
 \begin{itemize}
-	\item \textbf{\ac{API} of the \ac{OSN}}: Ideally the \ac{OSN} offers a public \ac{API} with full functionality. An API consists of multiple endpoints that can be used to retrieve, add, or modify specific data. Since the user's data should be protected as best as possible, access via the \ac{API} is usually restricted. The restriction may be due to a limited number of requests per time interval or a limited range of offered functions.
+	\item \textbf{\ac{API} of the \ac{OSN}}: Ideally the \ac{OSN} offers a public \ac{API} with full functionality. An \ac{API} consists of multiple endpoints that can be used to retrieve, add, or modify specific data. Since the user's data should be protected as best as possible, access via the \ac{API} is usually restricted. The restriction may be due to a limited number of requests per time interval or a limited range of offered functions.
 	\item \textbf{Crawling the \ac{OSN} web pages}: If there is no official \ac{API} or if it is sharply restricted, the contents can theoretically also be extracted by crawling. However, this brings with it several challenges. Modern web pages load many contents asynchronously so that the initial \ac{HTML} does not yet contain these contents. Furthermore, there are sophisticated mechanisms that notice crawling and lock out crawlers. Likewise, it may be difficult to add data to the \ac{OSN}. For security reasons, in most cases, special tokens are sent along with each request to detect and prevent abuse and fake requests.
 	\item \textbf{Creation, operation and licensing costs}: Costs for the creation, operation and licensing of third-party software may be incurred. At best, conscious decisions lead to the avoidance of expenses.
 	\item \textbf{Operating system or runtime environment}: Nowadays \acp{OSN} can be used on almost all devices; independent of their operating system. In order to achieve the same user experience, the hybrid \ac{OSN} should be usable on the same variety of operating systems. Any restrictions imposed by the operating system (user and application rights, connectivity) must be taken into account during creation.

thesis/content/04-concept/solution-strategy-architecture.tex

@@ -3,7 +3,7 @@ Various models can be used to implement a secure data exchange between the users
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=1.0\textwidth]{solution-strategy-architecture}
-	\caption{Architectures for secure data exchange among users: (a) by the use of an additional server, (b) via a P2P network connecting all users or (c) via a hybrid P2P network with servers acting as super-peers}
+	\caption{Architectures for secure data exchange among users: (a) by the use of an additional server, (b) via a \ac{P2P} network connecting all users or (c) via a hybrid \ac{P2P} network with servers acting as super-peers}
 	\label{fig:solution-strategy-architecture}
 \end{figure}
 
@@ -94,8 +94,8 @@ Table \ref{tab:solution-strategy-architecture-comparison} lists the advantages a
 		\cline{2-3}
 		& \textbf{Advantages} & \textbf{Disadvantages} \\ \hline
 		\multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Own infrastructure\\ (centralized)\end{tabular}}}        & \advantageoi                    & \disadvantageoi                       \\ \hline
-		\multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}P2P network\\ (decentralized)\end{tabular}}}             & \advantageon                    & \disadvantageon                       \\ \hline
+		\multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}\ac{P2P} network\\ (decentralized)\end{tabular}}}        & \advantageon                    & \disadvantageon                       \\ \hline
-		\multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Hybrid P2P network\\ (decentralized)\end{tabular}}}      & \advantagehn                    & \disadvantagehn                       \\ \hline
+		\multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Hybrid \ac{P2P} network\\ (decentralized)\end{tabular}}} & \advantagehn                    & \disadvantagehn                       \\ \hline
 		\multicolumn{1}{|l|}{\textbf{External infrastructure}}                                                           & \advantageei                    & \disadvantageei                       \\ \hline
 	\end{tabularx}
 	\caption{Advantages and disadvantages of the different solution strategies for the hybrid \ac{OSN} architecture.}

thesis/content/04-concept/solution-strategy-client.tex

@@ -1,6 +1,6 @@
 Concerning the implementation of the hybrid approach, two possibilities are conceivable. On the one hand, the extension of the original \ac{OSN} client (app or web front end) as an add-on. On the other hand, the development of an entirely new client.
 
-When an add-on extends the \ac{OSN}, there is no need to take care of the standard functionality of the \ac{OSN}. Therefore, the development can entirely focus on the add-on and the private extension. At crucial points, the add-on extends the interface by additional elements that enable secure data exchange. The service providers usually do not offer developers an interface to extend the OSN with such own functionalities. With web front ends it is possible to manipulate the website content using browser add-ons. One example for doing so is FaceCloak. Since such browser extensions manipulate the \ac{DOM}, knowledge about the document structure is necessary for the successful function in order to make changes in the right places. The short release cycles of \acp{OSN} and the associated frequent changes to this \ac{DOM} structure make it difficult to keep up with the changes. When consuming the \ac{OSN} via the official apps on mobile devices, an extension or manipulation is not possible.
+When an add-on extends the \ac{OSN}, there is no need to take care of the standard functionality of the \ac{OSN}. Therefore, the development can entirely focus on the add-on and the private extension. At crucial points, the add-on extends the interface by additional elements that enable secure data exchange. The service providers usually do not offer developers an interface to extend the \ac{OSN} with such own functionalities. With web front ends it is possible to manipulate the website content using browser add-ons. One example for doing so is FaceCloak. Since such browser extensions manipulate the \ac{DOM}, knowledge about the document structure is necessary for the successful function in order to make changes in the right places. The short release cycles of \acp{OSN} and the associated frequent changes to this \ac{DOM} structure make it difficult to keep up with the changes. When consuming the \ac{OSN} via the official apps on mobile devices, an extension or manipulation is not possible.
 
 The alternative to the extension approach described above is a new hybrid client app. The entire functional range of the \ac{OSN} must be implemented and kept up to date. As already mentioned with the restrictions (see Chapter \ref{sec:requirements}), the functions are usually not entirely provided via an \ac{API}, and the crawling of the content 
 confronts several challenges. By having complete control over the development of the client, the additional protected, secure communication can be added at the appropriate points. In the best-case scenario, at least one hybrid app is available for every operating system for which an official \ac{OSN} app exists.

thesis/content/04-concept/stakeholders.tex

@@ -1,6 +1,6 @@
-Everyone who is affected by a hybrid extension to an OSN has interests which should be considered. These so-called stakeholders can be people, groups or organizations which have the same opinion and the same goals. In the case of an OSN, there is a service provider who operates the platform. The users are split into those who care about their privacy and therefore want to use a hybrid solution and those who just want to use the OSN as it is. The developers of the hybrid solution have interests as well, and lastly, the government is highly interested that law and order are respected.
+Everyone who is affected by a hybrid extension to an \ac{OSN} has interests which should be considered. These so-called stakeholders can be people, groups or organizations which have the same opinion and the same goals. In the case of an \ac{OSN}, there is a service provider who operates the platform. The users are split into those who care about their privacy and therefore want to use a hybrid solution and those who just want to use the \ac{OSN} as it is. The developers of the hybrid solution have interests as well, and lastly, the government is highly interested that law and order are respected.
 
-Even if the stakeholders are not necessarily directly involved in the development process of a hybrid solution, it is still essential to understand the views and interests of the various parties and take them into account. Table \ref{tab:steakholders} shows the interests and points of view of the parties involved directly and indirectly with the hybrid extension of the OSN.
+Even if the stakeholders are not necessarily directly involved in the development process of a hybrid solution, it is still essential to understand the views and interests of the various parties and take them into account. Table \ref{tab:steakholders} shows the interests and points of view of the parties involved directly and indirectly with the hybrid extension of the \ac{OSN}.
 
 % Interests
 \newcommand{\interestsSP}{\begin{minipage} [t] {0.4\textwidth} 
@@ -78,8 +78,8 @@ Even if the stakeholders are not necessarily directly involved in the developmen
 \newcommand{\influenceSP}{\begin{minipage} [t] {0.4\textwidth} 
 		\begin{itemize}
 			\item No direct influence on the hybrid solution
-			\item By identification of the hybrid OSN users their exclusion
+			\item By identification of the hybrid \ac{OSN} users their exclusion
-			\item Blocking the hybrid OSN
+			\item Blocking the hybrid \ac{OSN}
 			\item Great influence			
 		\end{itemize}
 \end{minipage}}
@@ -123,7 +123,7 @@ Even if the stakeholders are not necessarily directly involved in the developmen
 			\begin{tabular}[c]{@{}l@{}}Developer\\ hybrid OSN\end{tabular} & \interestsDevHOSN  & \attitudeDevHOSN                     & \influenceDevHOSN                \\ \hline
 			Governments                                                    & \interestsGov      & \attitudeGov                         & \influenceGov                    \\ \hline
 		\end{tabular}
-		\caption{The table shows the interests, attitudes towards a hybrid solution and influence on the hybrid solution of several stakeholders.}
+		\caption{The table shows the interests, attitudes towards and influence on the hybrid solution of several stakeholders.}
 		\label{tab:steakholders}
 	\end{table}
 \end{landscape}

thesis/content/05-proof-of-concept.tex

@@ -6,7 +6,7 @@
 \label{sec:objective}
 \input{content/05-proof-of-concept/objective}
 
-\section{Selection of the OSN}
+\section{Selection of the \ac{OSN}}
 \label{sec:osn-selection}
 \input{content/05-proof-of-concept/osn-selection}
 
@@ -14,7 +14,7 @@
 \label{sec:technology-decisions}
 \input{content/05-proof-of-concept/technology-decisions}
 
-\section{Presenting Hybrid OSN for Twitter}
+\section{Presenting Hybrid \ac{OSN} for Twitter}
 \label{sec:hybrid-osn-presentation}
 \input{content/05-proof-of-concept/hybrid-osn}
 

thesis/content/05-proof-of-concept/building-block-view.tex

@@ -27,7 +27,7 @@ The Ionic framework uses Angular in the core. Accordingly, the Hybrid \ac{OSN} a
 
 \subsubsection{Providers}
 \label{providers}
-Data access is performed using providers (known as services in Angular). For the external services (Twitter \ac{API}, \ac{P2P} database, \ac{P2P} storage), there is one provider each to handle the communication. Besides, providers are used as helper classes providing specific functionality that is used several times. This functionality includes, for example, encryption and decryption and the compilation of aggregated timelines. Providers are injected into components using the constructor. Table \ref{tab:providers} lists all providers used in Hybrid OSN and their functional descriptions.
+Data access is performed using providers (known as services in Angular). For the external services (Twitter \ac{API}, \ac{P2P} database, \ac{P2P} storage), there is one provider each to handle the communication. Besides, providers are used as helper classes providing specific functionality that is used several times. This functionality includes, for example, encryption and decryption and the compilation of aggregated timelines. Providers are injected into components using the constructor. Table \ref{tab:providers} lists all providers used in Hybrid \ac{OSN} and their functional descriptions.
 
 \begin{table}[h!]
 	\begin{tabularx}{\textwidth}{|l|X|}

thesis/content/05-proof-of-concept/hybrid-osn.tex

@@ -18,7 +18,7 @@ When the user opens the app for the first time, the login page is displayed (see
 		\caption{}
 		\label{fig:screenshot-menu}
 	\end{subfigure}
-	\caption{Screenshots of the Hybrid OSN app for the login page (a), the home feed (b) and the menu (c).}
+	\caption{Screenshots of the Hybrid \ac{OSN} app for the login page (a), the home feed (b) and the menu (c).}
 \end{figure}
 
 % Home + Menu
@@ -40,7 +40,7 @@ A tweet consists of information about the author and the time of the writing, th
 		\caption{}
 		\label{fig:user-actions}
 	\end{subfigure}
-	\caption{Screenshots of the Hybrid OSN app for tweet and its actions (a) and the menu with user-specific actions (b)}
+	\caption{Screenshots of the Hybrid \ac{OSN} app for tweet and its actions (a) and the menu with user-specific actions (b)}
 \end{figure}
 
 % Settings
@@ -69,7 +69,7 @@ The page for composing a new tweet is also used when replying to a tweet or retw
 		\caption{}
 		\label{fig:screenshot-warning}
 	\end{subfigure}
-	\caption{Screenshots of the Hybrid OSN app for replying to a tweet (a), writing a tweet containing a keyword triggering the private mode (b) and the warning message related for the use of the keyword in public mode (c).}
+	\caption{Screenshots of the Hybrid \ac{OSN} app for replying to a tweet (a), writing a tweet containing a keyword triggering the private mode (b) and the warning message related for the use of the keyword in public mode (c).}
 \end{figure}
 
 % Profile

thesis/content/05-proof-of-concept/osn-selection.tex

@@ -19,7 +19,7 @@ Finally, Twitter was chosen for the prototype. With 321 million active users per
 Twitter offers several \acp{API} for developers that serve different purposes. The current \acp{API} are \cite{twitterXXXXdev-getting-started}:
 \begin{itemize}
 	\item \textbf{Standard \ac{API}}: the free and public \ac{API} offering basic query functionality and foundational access to Twitter data.
-	\item \textbf{Premium \ac{API}}: introduced in November 2017 to close the gap between Standard and Entrprise \ac{API}. Improvements over the Standard \ac{API}: \enquote{more Tweets per request, higher rate limits, a counts endpoint that returns time-series counts of Tweets, more complex queries and metadata enrichments, such as expanded URLs and improved profile geo information}\cite{twitter2017premium-api}. Prices to use this \ac{API} start at 149\$/month.
+	\item \textbf{Premium \ac{API}}: introduced in November 2017 to close the gap between Standard and Entrprise \ac{API}. Improvements over the Standard \ac{API}: \enquote{more Tweets per request, higher rate limits, a counts endpoint that returns time-series counts of Tweets, more complex queries and metadata enrichments, such as expanded \acp{URL} and improved profile geo information}\cite{twitter2017premium-api}. Prices to use this \ac{API} start at 149\$/month.
 	\item \textbf{Enterprise \ac{API}}: tailored packages with annual contracts for those who depend on Twitter data.
 	\item \textbf{Ads \ac{API}}: this \ac{API} is only of interest for creating and managing ad campaigns.
 	%\item \textbf{Twitter for websites}: this is more a suite of tools than an \ac{API}. It's free to use and enables people to embed tweets and tweet buttons on their website.

thesis/content/05-proof-of-concept/runtime-view.tex

@@ -10,7 +10,7 @@ On the write-tweet page, new tweets can be written and posted using a form. In a
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=1.0\textwidth]{post-tweet-flow-chart}
-	\caption{Flow chart of the process for posting a new tweet either on the public Twitter network or on the private P2P network}
+	\caption{Flow chart of the process for posting a new tweet either on the public Twitter network or on the private \ac{P2P} network}
 	\label{fig:post-tweet-flow-chart}
 \end{figure}
 
@@ -21,11 +21,11 @@ On the write-tweet page, new tweets can be written and posted using a form. In a
 	\label{fig:post-tweet-building-block-view}
 \end{figure}
 
-After entering the message in the input field, determining the destination network, and pressing the \enquote{TWEET!} button, processing starts in the WriteTweetPage class. If the message is destined for Twitter, the Twitter API provider sends an HTTP POST request with the data to the \texttt{statuses/update}\footnote{https://developer.twitter.com/en/docs/tweets/post-and-engage/api-reference/post-statuses-update} interface. In this case, nothing more needs to be done, as the Twitter API takes over the preparation of the data and extracts, for example, hashtags, mentions, and URLs.
+After entering the message in the input field, determining the destination network, and pressing the \enquote{TWEET!} button, processing starts in the WriteTweetPage class. If the message is destined for Twitter, the Twitter \ac{API} provider sends an HTTP POST request with the data to the \texttt{statuses/update}\footnote{https://developer.twitter.com/en/docs/tweets/post-and-engage/api-reference/post-statuses-update} interface. In this case, nothing more needs to be done, as the Twitter \ac{API} takes over the preparation of the data and extracts, for example, hashtags, mentions, and \acp{URL}.
 
 When publishing in the private network, the system first checks whether the public key has already been published. The Crypto provider performs this check using the Twitter \ac{API} provider (for further information about the handling of public keys see the section about security \ref{sec:security}). If the public key has not yet been published, the user receives a warning, and the posting process is aborted. Otherwise, the private tweet will be constructed. The entered text is converted into a simplified tweet object (see Twitter documentation for original tweet object\footnote{https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/tweet-object.html}) that contains the essential information.
 
-Beside the message (\texttt{full\_text}) the Twitter user id (\texttt{user\_id}) and the timestamp (\texttt{created\_at}) are set. In addition, there is a flag (\texttt{private\_tweet: true}) to distinguish the private tweet, which later influences the design. The \texttt{display\_text\_range} indicates the beginning and end of the relevant part in \texttt{full\_text}. For private tweets, this is always the entire text, for tweets from the Twitter API an additional, not needed URL may be appended, which is cut off by clipping. Furthermore, the tweet entities are extracted. The extraction includes URLs, hashtags and user mentions. An example of a private tweet is shown in Listing \ref{listing:private-tweet}.
+Beside the message (\texttt{full\_text}) the Twitter user id (\texttt{user\_id}) and the timestamp (\texttt{created\_at}) are set. In addition, there is a flag (\texttt{private\_tweet: true}) to distinguish the private tweet, which later influences the design. The \texttt{display\_text\_range} indicates the beginning and end of the relevant part in \texttt{full\_text}. For private tweets, this is always the entire text, for tweets from the Twitter \ac{API} an additional, not needed \ac{URL} may be appended, which is cut off by clipping. Furthermore, the tweet entities are extracted. The extraction includes \acp{URL}, hashtags and user mentions. An example of a private tweet is shown in Listing \ref{listing:private-tweet}.
 
 \lstinputlisting[label=listing:private-tweet, caption=Private Tweet in \ac{JSON} format]{listings/private-tweet.json}
 

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

@@ -7,7 +7,7 @@ In order to meet the requirements of the concept best, a detailed consideration
 
 \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 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}
@@ -38,7 +38,7 @@ In 2014, Mark Nadal began working on a decentralized database called GUN. GUN\fo
 \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 P2P Network}
+\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.
 
@@ -55,9 +55,9 @@ A solution based on a blockchain increases complexity for the user. Since the hy
 
 \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 IPFS came from Juan Benet in 2014. Protocol Labs\footnote{https://protocol.ai}, founded by Benet, now manages the open source project \cite{benetXXXXlinkedin}.
+\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 is 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 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,
+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 is 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.
 

thesis/content/06-discussion.tex

@@ -1,6 +1,6 @@
 \chapter{Evaluation}
 \label{ch:evaluation}
-This chapter is on the evaluation of the Hybrid OSN app. It is discussed to which extent the previously defined requirements and quality goals were fulfilled and validated how realistic the requirements are in general. Afterwards, limitations are discussed, and a threat model mentions potential problems.
+This chapter is on the evaluation of the Hybrid \ac{OSN} app. It is discussed to which extent the previously defined requirements and quality goals were fulfilled and validated how realistic the requirements are in general. Afterwards, limitations are discussed, and a threat model mentions potential problems.
 %Furthermore, a comparison to other related work is carried out.
 
 \section{Fulfillment of Requirements and Achievement of Objectives}

thesis/content/06-discussion/threat-model.tex

@@ -20,7 +20,7 @@ For preventing the hashtag and private tweet timestamps from connecting, the tim
 
 The greatest threat is that an attacker may modify or delete data. By deleting entries, private tweets would no longer be found and thus no longer displayed. Changing the \ac{IPFS} hash would mean that the data could not be found and would also not be displayed. Manipulation of the timestamp would result in private tweets being loaded at the wrong time interval when the feed is loaded and thus positioned at the wrong place. Furthermore, the timestamp in GUN is used to use the appropriate public key from the public key history for decryption. Under certain circumstances, the wrong key would be selected and the private tweet could not be decrypted.
 
-Creating entries for private tweets does not have a significant effect because the associated content stored in IPFS must be encrypted with the private key, which is unknown to a third party. Adding wrong or modifying existing hashtag entries for trend detection is also possible and poses a significant risk as it allows manipulation of the trends. Ultimately, it is not possible to verify which hashtags were used and how often. The same applies to private likes. Since in this case the complete information is stored in GUN and can be changed, it is not possible to determine whether data has been manipulated.
+Creating entries for private tweets does not have a significant effect because the associated content stored in \ac{IPFS} must be encrypted with the private key, which is unknown to a third party. Adding wrong or modifying existing hashtag entries for trend detection is also possible and poses a significant risk as it allows manipulation of the trends. Ultimately, it is not possible to verify which hashtags were used and how often. The same applies to private likes. Since in this case the complete information is stored in GUN and can be changed, it is not possible to determine whether data has been manipulated.
 
 \subsection{\ac{IPFS}}
 \label{sec:threat-model-ipfs}