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

This section describes particular processes and relationships between building blocks for two selected scenarios. The first is to write and post a tweet and the second is to display the home timeline. In addition to the description, the two scenarios are also documented by flowcharts.

The goal is to make clear how the building blocks of the system perform their respective tasks and communicate with each other at runtime. The two scenarios were therefore deliberately selected because of their particular importance and require special documentation due to their complexity.

\subsection{Post a Tweet}
\label{sec:post-a-tweet}

On the write-tweet page, new tweets can be written and posted using a form. In addition to the input field for the message text, there is also a status display that informs the user about the character limit, a switch that decides about the target network, and a button to send. The process of writing and publishing a tweet is shown in the flow chart in Figure \ref{fig:post-tweet-flow-chart}. Figure \ref{fig:post-tweet-building-block-view} shows the involved components in the block view.

\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 \ac{P2P} network}
	\label{fig:post-tweet-flow-chart}
\end{figure}

\begin{figure}[h!]
	\centering
	\includegraphics[width=1.0\textwidth]{block-view-write-tweet}
	\caption{Building block view of the interaction between the different modules when posting a new tweet}
	\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 \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 \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}

The crypto provider performs the encryption of the private tweet data. For asymmetrical encryption, the RSA algorithm is used. The \ac{P2P} storage provider sends the encrypted data via an \ac{HTTP} POST request to Infura for storage in \ac{IPFS}. The response contains the hash which addresses the data in \ac{IPFS}. This hash is stored in GUN together with the timestamp and the author's Twitter user id. For saving to GUN, the \ac{P2P} DB provider is used. Besides, the previously extracted hashtags with the timestamp are also stored in GUN with the same provider so that the data in the dashboard are accessible to the service provider without having to conclude individual users.

\subsection{Load the Home Timeline}
\label{sec:load-home-timeline}
When opening the home page, the logged in user gets the latest tweets of the accounts he follows chronologically presented. The tweets are loaded in batches of 20 tweets from the Twitter \ac{API} and enriched with the private tweets for this period. If the user scrolls to the end of the feed, the reloading of the next batch is triggered and automatically inserted at the end. At the top of the feed, a \enquote{pull to refresh} action intents the feed reloading. The loading process is shown in Figure \ref{fig:home-timeline-flow-chart} as a flow chart and in Figure \ref{fig:home-timeline-building-block-view} as a building block view of the interacting components.

\begin{figure}[h!]
	\centering
	\includegraphics[width=1.0\textwidth]{home-timeline-flow-chart}
	\caption{Flow chart of the process for loading the home timeline for a user}
	\label{fig:home-timeline-flow-chart}
\end{figure}

\begin{figure}[h!]
	\centering
	\includegraphics[width=1.0\textwidth]{block-view-home-page}
	\caption{Building block view of the interaction between the different modules when loading the home timeline of a user}
	\label{fig:home-timeline-building-block-view}
\end{figure}

The starting point is the home page, which is accessed by the user. Several components display the data obtained from the feed provider. Using the Twitter \ac{API} provider, the feed provider loads the latest 20 timeline tweets via the corresponding interface (\texttt{statuses/home\_timeline}\footnote{https://developer.twitter.com/en/docs/tweets/timelines/yapi-reference/get-statuses-home\_timeline.html}) via an \ac{HTTP} GET request.

The next step is to load the private tweets that match the period marked by the current timestamp and timestamp of the 20th (the oldest) tweet. Furthermore, the ids of the accounts the user follows (so-called friends) are required. These must initially be requested from the Twitter \ac{API} (\texttt{friends/list}\footnote{https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-friends-list}) via the Twitter Feed provider using an \ac{HTTP} GET request. The loaded user ids are cached in order to keep the number of requests to the Twitter \ac{API} to a minimum for later loading processes. For each user id, a lookup for private tweets in the given period is performed. The \ac{P2P} \ac{DB} provider queries GUN. If there are private tweets, the hashes for \ac{IPFS} are returned together with the \texttt{created\_at} timestamp. If no private tweets are available for the period, the feed provider returns the data of the public tweets to the home page. Otherwise, the private tweets are loaded and decrypted. First, the \ac{P2P} storage provider is used to load the data behind the hash addresses from \ac{IPFS} via Infura. For this purpose, the hash is transferred to Infura with an \ac{HTTP} GET request, and the data are received from \ac{IPFS} as the response. The author's public key, which can be obtained from the user's public key history, is needed for decryption. The public key history is loaded and decrypted via the crypto provider, which in turn uses the Twitter \ac{API} provider. Afterwards, the private tweet is decrypted.

Finally, the private and public tweets are merged and sorted according to their \texttt{created\_at} timestamp in descending order. This data are returned to the home page. If the user triggers a reload by reaching the end of the feed or by \enquote{pull to refresh}, the previously described process starts again.