Browse Source

add captions to images

Carsten Porth 5 years ago
parent
commit
df69c37072

+ 1 - 1
thesis/content/02-background/p2p.tex

@@ -17,7 +17,7 @@ To address the problem of inefficient and complicated searching for resources, c
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=0.85\textwidth]{unstructured-p2p-networks}
-	\caption{Search process in unstructured \ac{P2P} systems \cite{moltchanov2014p2p-networks}}
+	\caption{File retrieval process in unstructured \ac{P2P} systems exemplary shown for Napster, Gnutella v0.4, FastTrack/Gnutella v0.6 and BitTorrent \cite{moltchanov2014p2p-networks}}
 	\label{fig:unstructured-p2p}
 \end{figure}
 

+ 1 - 1
thesis/content/02-background/software-system-architecture.tex

@@ -20,7 +20,7 @@ In the following, the characteristics and peculiarities of the different archite
 		\caption{Distributed}
 		\label{fig:architecture-distributed}
 	\end{subfigure}
-	\caption{Schematic representation of various software system architectures. In centralized applications (A), all clients (blue) are in connection with a central server (red), while in decentralized applications (B) several servers provide for improved stability. In distributed applications (C), all nodes have the same role with the same tasks, hence they are called peers (green).}
+	\caption{Schematic representation of various software system architectures. In centralized applications (a), all clients (blue) are in connection with a central server (red), while in decentralized applications (b) several servers provide for improved stability. In distributed applications (c), all nodes have the same role with the same tasks, hence they are called peers (green).}
 	\label{fig:software-system-architecture}
 \end{figure}
 

+ 3 - 3
thesis/content/03-related-work/activitypub.tex

@@ -4,11 +4,11 @@ The principle behind ActivityPub is similar to that of e-mail. Servers can be un
 
 \subsubsection{Client to Server (Social \ac{API})}
 \label{sec:social-api}
-Users are called actors in ActivityPub and are represented by an associated account on the server. Since there can be several servers, it is important to emphasize that an account is bound to one server and user names must always be unique only within a server. Each actor has an inbox and an outbox on the server on which he is registered with his account. These are the two endpoints with which the client application communicates via \ac{HTTP} requests. More is not necessary, because the server ensures that all messages and information for the user end up in his inbox and that the messages in his outbox are forwarded to the desired recipients (see \ref{sec:federation-protocol}). For ensuring that only authorized clients store content in an outbox, the sender must sign the posts.
+Users are called actors in ActivityPub and are represented by an associated account on the server. Since there can be several servers, it is important to emphasize that an account is bound to one server and user names must always be unique only within a server. Each actor has an inbox and an outbox on the server on which he is registered with his account. These are the two endpoints with which the client application communicates via \ac{HTTP} requests. More is not necessary, because the server ensures that all messages and information for the user end up in his inbox and that the messages in his outbox are forwarded to the desired recipients (see\,\ref{sec:federation-protocol}). For ensuring that only authorized clients store content in an outbox, the sender must sign the posts.
 
-\begin{figure}[h]
+\begin{figure}[h!]
 	\includegraphics[width=1.0\textwidth]{activitypub-communication}
-	\caption{Concept behind ActivityPub \cite{w3c2018activity-pub}}
+	\caption{Concept of the Social \ac{API} protocol: The user fetches messages with an \ac{HTTP} GET request to his inbox and posts messages using an \ac{HTTP} POST request. The inbox is filled by \ac{HTTP} POST requests from other users. \cite{w3c2018activity-pub}}
 	\label{fig:activitypub-communication}
 \end{figure}
 

+ 3 - 3
thesis/content/03-related-work/lifesocial.tex

@@ -9,7 +9,7 @@ Initially, Graffi et al. designed a framework for \ac{P2P}-based multimedia onli
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=.5\textwidth]{lifesocial-framework}
-	\caption{\cite{graffi2008distributed}}
+	\caption{Layered architecture as used in the framework for \ac{P2P} based social networks by Graffi et al. \cite{graffi2008distributed}}
 	\label{fig:lifesocial-architecture}
 \end{figure}
 
@@ -28,7 +28,7 @@ In order to store the data effectively, Graffi introduced the Distributed Linked
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=0.8\textwidth]{lifesocial-data-structure}
-	\caption{An example for the use of the data type Distributed Linked List. The user albums object on the left points to several album data objects which again point to the image objects. \cite{graffi2008distributed}}
+	\caption{An example for the use of the data type Distributed Linked List. The user albums object on the left points to several album data objects which again point to the image objects. Each object has a unique id and a body to store data. \cite{graffi2008distributed}}
 	\label{fig:lifesocial-data-structure}
 \end{figure}
 
@@ -50,7 +50,7 @@ LifeSocial is based on the previously described framework. The software runs und
 	\begin{subfigure}[b]{0.49\textwidth}
 		\includegraphics[width=\textwidth]{lifesocial-screenshot-02}
 	\end{subfigure}
-	\caption{Screenshots of the LifeSocial GUI \cite{graffi2011lifesocial}}
+	\caption{Screenshots of the LifeSocial GUI showing multiple plugins for profile, friends, message system and photos \cite{graffi2011lifesocial}}
 	\label{fig:lifesocial-screenshots}
 \end{figure}
 

+ 1 - 1
thesis/content/03-related-work/peepeth.tex

@@ -13,7 +13,7 @@ While the smart contracts are open source, the front end is closed source. So it
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=1.0\textwidth]{peepeth-architecture}
-	\caption{Peepeth architecture}
+	\caption{System architecture of Peepeth. The front end website communicates with a back end server and loads images from \ac{AWS}. The back end is connected to the Ethereum blockchain and \ac{IPFS}.}
 	\label{fig:peepeth-architecture}
 \end{figure}
 

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

@@ -16,7 +16,7 @@ Infura\footnote{https://infura.io/} is a service that provides access to Ethereu
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=1.0\textwidth]{building-block-view}
-	\caption{.}
+	\caption{Black box view on Hybrid \ac{OSN} showing the scope and context of the application. The adjacent systems are the user of the app, the Twitter API, the \ac{P2P} database GUN, and \ac{IPFS} via the Infura gateway.}
 	\label{fig:building-block-view}
 \end{figure}
 
@@ -27,7 +27,7 @@ The Ionic framework uses Angular in the core. Accordingly, the Hybrid \ac{OSN} a
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=1.0\textwidth]{building-block-view-level1}
-	\caption{.}
+	\caption{White box view on the basic building blocks and their connections. The user always faces and interacts with pages. These pages are built using components. Providers handle all data and communicate with the interfaces of other systems like GUN, the Twitter API, and Infura.}
 	\label{fig:building-block-view-level1}
 \end{figure}