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

\begin{figure}[h!]
	\centering
	\includegraphics[width=1.0\textwidth]{post-tweet-building-block-view}
	\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 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.

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 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}.

\lstinputlisting[label=listing:private-tweet, caption=Private Tweet in 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 P2P storage provider sends the encrypted data via an HTTP POST request to Infura for storage in IPFS. The response contains the hash which addresses the data in IPFS. This hash is stored in Gun together with the timestamp and the author's Twitter user id. For saving to Gun, the 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 is 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 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]{home-timeline-building-block-view}
	\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 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 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 user ids of the users the user follows (so-called friends) are required. These must initially be requested from the Twitter 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 HTTP GET request. The loaded user ids are cached in order to keep the number of requests to the Twitter API to a minimum for later loading processes. For each user id, a lookup for private tweets in the given period is performed. The P2P DB provider queries Gun. If there are private tweets, the hashes for 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, next, the private tweets are loaded and decrypted. First, the P2P storage provider is used to load the data behind the hash addresses from IPFS via Infura. For this purpose, the hash is transferred to Infura with an HTTP GET request, and the data is received from 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 API provider. Afterward, 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 is 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.