|
|
@@ -0,0 +1,87 @@
|
|
|
+In Chapter \ref{sec:requirements}, several functional and non-functional requirements were defined. In addition, in Chapter \ref{sec:quality-goals} multiple quality goals were set to ensure a high quality of the code. In the following, for each requirement and goal, a critical discussion is given on the achievement in the Hybrid OSN app.
|
|
|
+
|
|
|
+\subsection{Functional Requirements}
|
|
|
+With regard to the functional requirements previously defined in Chapter \ref{sec:requirements}, their implementation in the Hybrid OSN app are discussed in the following.
|
|
|
+
|
|
|
+\subsubsection{Standard Functionality}
|
|
|
+As part of this work, a prototype with limited functionality was created. Accordingly, numerous functionalities, such as the direct messaging system, notifications, the posting of images, gifs, videos or surveys, and much more are not implemented. However, it was considered that the prototype implements all essential functionalities so that the basic use of Twitter is possible. These basic functions include displaying the home feed and user feeds (profiles), searching for users and managing the connection (follow, unfollow, mute, block), as well as liking tweets and posting new tweets (incl. reply, retweet).
|
|
|
+
|
|
|
+While the majority of the missing functions were deliberately omitted for time reasons, the API also sets limits. For this reason, this requirement must be evaluated as not fulfilled. However, due to the limitations of the \ac{API}, it could not have been fully met. While Twitter is an extremely grateful example due to its simple functionality and generous \ac{API}, the limitations of other \acp{OSN} are much more severe. A missing \ac{API} and crawling prohibited by terms of service would make data exchange between a client and the \ac{OSN} virtually impossible.
|
|
|
+
|
|
|
+\subsubsection{Client-side Solution}
|
|
|
+Since it is not possible to execute code on the \ac{OSN}'s servers, no other solution than a client-side approach is possible. Accordingly, all functions are implemented on the client side, and the requirement is fulfilled.
|
|
|
+
|
|
|
+As described in Chapter \ref{sec:solution-strategy-architecture}, a solution architecture either contains or does not contain additional servers. In the objectives in Chapter \ref{sec:objective}, a solution without additional servers was preferred. However, since GUN requires a relay server to establish the connection between the peers, this self-imposed goal could not be achieved.
|
|
|
+
|
|
|
+\subsubsection{Data Sovereignty}
|
|
|
+The user can decide for himself whether the data is shared with other users via the private network or the Twitter servers when posting or liking a tweet. Since other functionalities that require data from the user (e.g., information in the profile, direct messages) have not been implemented, at least the prototype fulfills the requirement partly.
|
|
|
+
|
|
|
+However, data about user behavior can still be collected. The user is authenticated against the \ac{API} so that his requests can be unambiguously assigned. Using this usage data, Twitter can record which profiles are called up and what the user searches for. This data can also be used to conclude a user's preferences and interests. Hybrid \ac{OSN} offers no protection against this type of data collection.
|
|
|
+
|
|
|
+\subsubsection{Authorized Data Access and Encryption}
|
|
|
+Private data should be accessible only to those users for whom they are intended. However, they should not be accessible to the service provider. Twitter only distinguishes between public and private profiles. While with public profiles every other Twitter user has access to the profile and the tweets, with private profiles only authorized followers can view tweets.
|
|
|
+
|
|
|
+By distributing the public key to decrypt the data via the profile, the same user group is granted access to a user's private tweets, which can also see the official Twitter tweets. The additional symmetric encryption of the public key history by the Hybrid \ac{OSN} app ensures that Twitter cannot decrypt the public key history and thus also the private tweets. Therefore, the requirement can be evaluated as fulfilled.
|
|
|
+
|
|
|
+The implementation differs from the standard solution for this problem. Typically, data is encrypted with the recipient's public key to ensure that only the recipient can decrypt it with their private key. However, in the case of Twitter and the public profiles, the recipient circle of a tweet is not known. Accordingly, it is not possible to explicitly encrypt data for a specific recipient.
|
|
|
+
|
|
|
+An alternative to the implementation in Hybrid \ac{OSN} would be to encrypt data with the symmetrical Hybrid \ac{OSN} key for public profiles and to encrypt data asymmetrically with the public keys of the recipient for private profiles. The advantage would be that users with a public profile would not have to generate keys and the configuration effort would be reduced. A simpler configuration would have a positive effect on the requirement for minimal configuration effort. The disadvantage would be that a user with a private profile and a large number of approved followers would have to calculate the encryption and upload the data for each. This would be in contrast to the requirement to conserve resources.
|
|
|
+
|
|
|
+\subsubsection{Flexible Data Format}
|
|
|
+The flexibility of GUN and the \ac{JSON} data format allow effective data storage. The established structures can also be easily adapted for future requirements. Due to the immutability of the data stored in \ac{IPFS}, it is not possible to retroactively change the data structure. Should this nevertheless be necessary, the changes would have to be implemented in the program logic. However, the requirement must be regarded as fulfilled.
|
|
|
+
|
|
|
+\subsubsection{Platform Independence}
|
|
|
+The requirement for a platform-independent solution contradicts the actual requirement to develop an Android client. Nevertheless, the requirement was taken into account in the decisions made. The targeted selection of the Ionic framework laid the basis for platform independence. Even though Ionic was primarily used to create an Android application within the scope of this work, it should be possible to use the same code with some effort to create an app for iOS or a \ac{PWA}. Since Twitter can be used on almost all platforms up to the feature phone, the idealistic goal of creating a similar client variety is almost utopian. Taking all that into account, the requirement is therefore only partially fulfilled.
|
|
|
+
|
|
|
+\subsubsection{Anonymized Data for the Service Provider}
|
|
|
+Anonymous data from the private network should be shared with Twitter to prevent the service provider's business model from failing. Approximately 87\% (\$\,791 million) of Twitter's revenues in the fourth quarter 2018 were generated by advertisements \cite{twitter2019reportq4}. Thus, the central pillar of Twitter's business model is personalized advertising. Accordingly, data should be of particular interest for Twitter if it is related to a person. Only if Twitter gains knowledge about a user, this knowledge can be used to place targeted advertisements. However, it is precisely this connection between data and user that should be avoided by using Hybrid \ac{OSN}.
|
|
|
+
|
|
|
+As a result, the implementation of the requirement is almost impossible. Even though all data would be transferred to Twitter in an anonymous form for further processing, this data would be entirely worthless for Twitter's business model.
|
|
|
+
|
|
|
+In this context, it should be emphasized that the use of the \ac{API} does not result in any advertising being displayed to the user. Twitter therefore deliberately accepts that client applications that use the \ac{API} do not contribute to the generation of profits. Against this background, the implementation of this requirement is questionable although it is an essential aspect in the hybrid \ac{OSN} concept.
|
|
|
+
|
|
|
+In order to meet the request and at least to prove the feasibility of the anonymized data provision, the hashtags used were provided anonymously. Twitter could use this data to improve trend recognition and inform users about current, much-discussed topics. Thus, a full analysis of popular hashtags throughout the system enables precise statements.
|
|
|
+
|
|
|
+\subsection{Non-Functional Requirements}
|
|
|
+The following part is about the non-functional requirements as defined in Chapter \ref{sec:requirements}. It is discussed to which extent they are considered in the Hybrid \ac{OSN} prototype.
|
|
|
+
|
|
|
+\subsubsection{Minimal Additional Effort}
|
|
|
+The Hybrid \ac{OSN} app is available as \ac{APK} file and can be installed on an Android device. Since it is only a prototype so far, the app is not available from the Google Play Store. Theoretically, this is possible and would simplify the installation and updating of the app.
|
|
|
+
|
|
|
+The app works out of the box and does not require any particular configuration. For passive use, i.e., just consuming the content, the app works from the beginning. No additional registration is necessary; the Twitter login is sufficient. For the encryption of the private tweets, a key pair is required, which can be generated in the settings by clicking on a button. The configuration effort is therefore limited to a minimum. If the key pair is not yet stored, the user is notified before posting the private tweet and referred to the necessary configuration on the settings page.
|
|
|
+
|
|
|
+If the user uninstalls the app or logs out of his account, the configurations and thus also the public and private key are deleted. If the keys have not been saved elsewhere and cannot be restored, the next time the user uses Hybrid \ac{OSN} again, there are no restrictions on generating a new key pair. With the public key history, it is verified that old tweets are always decryptable.
|
|
|
+
|
|
|
+During the conception phase, this requirement was always given high priority. The implementation as a \ac{dApp} and the associated need for corresponding tokens and a wallet were especially rejected because of this requirement. The current implementation completely meets the requirement for minimal configuration effort.
|
|
|
+
|
|
|
+\subsubsection{Minimal Side Effects}
|
|
|
+In the context of the publication of the public key history, changes that are visible to other users become noticeable in two places. First, the \ac{IPFS} hash of the public key history is posted in a tweet. Second, a reference to this tweet is stored in the profile description of the user. While the tweet will show up in all followers' timelines, a change in the profile description has no direct influence on the user experience of other users. During regular use, the public key history is rarely extended by new entries. Thus the side effects are limited to a minimum, and the requirement is fulfilled accordingly.
|
|
|
+
|
|
|
+\subsubsection{Compliance with Policies}
|
|
|
+The Twitter Developer Terms and the Twitter Terms and Conditions were respected. For example, \ac{API} guidelines do not allow the redistribution of Twitter content. For this reason, when tweeting or quoting tweets over the private network, only their ids are stored, not the entire content. Hence, the requirement is fulfilled.
|
|
|
+
|
|
|
+\subsubsection{Good User Experience}
|
|
|
+A good user experience should be achieved by short loading times and understandable and appealing design. The loading times of the private data in Hybrid OSN consist of two parts. With GUN, objects of interest must be identified and the data loaded from IPFS. In both cases, it has a significant influence on the loading time whether there are enough peers with the searched information in the network. Both systems are designed for short reaction times. However, the loading times cannot be given in figures, since no reliable result could be measured due to the non-reproducible circumstances concerning peer availability.
|
|
|
+
|
|
|
+There are no objective standards for an understandable and appealing design. The following examples are intended to show how these demands on the user interface were nevertheless met.
|
|
|
+
|
|
|
+\begin{itemize}
|
|
|
+ \item Icons extend items in the menu. The icons allow quick identification of the purpose of the page without having to read the title.
|
|
|
+ \item The structure of a tweet corresponds to the structure known from Twitter so that no acclimatization is necessary.
|
|
|
+ \item When writing a tweet, a circle animation visualizes compliance with the character limit. The user is thus visually informed about how many characters have already been used and how many are still possible.
|
|
|
+ \item When sharing data, the private mode is indicated by a sunglasses icon, the public mode by the Twitter logo. This can be found when writing a new tweet as well as when likening tweets.
|
|
|
+ \item Private tweets are represented by a dark background so that the data source can be identified easily.
|
|
|
+ \item Loading processes are represented to the user by a loading animation. When posting a private tweet, the user is also informed about the current processing step.
|
|
|
+ \item When using sensitive keywords in tweets, the user is informed about this circumstance and recommended to post the tweet privately. On the settings page, the user can configure the keywords himself.
|
|
|
+\end{itemize}
|
|
|
+
|
|
|
+\subsection{Quality Goals}
|
|
|
+Quality goals, as defined in Chapter\ref{sec:quality-goals}, should motivate developers to write high-quality code that is easy to customize and maintain.
|
|
|
+
|
|
|
+Concerning the analyzability of Hybrid OSN, all modules, classes, methods, and variables were titled with English names. The public methods of the provider classes were documented, and the Clean Code principles were adhered to.
|
|
|
+
|
|
|
+With JavaScript, the application is written in a language that ranks on eighth place in the TIOBE Index, which measures the popularity of a programming language \cite{}. At GitHub, JavaScript leads all statistics \cite{}. Most new repositories are created for JavaScript projects, and most contributions are written in JavaScript. Due to its popularity, many developers should be able to use the Hybrid \ac{OSN} codebase and find their way around quickly. The interfaces to GUN and \ac{IPFS} have been outsourced to individual providers so that they are interchangeable. Thus, the technology can be easily exchanged.
|
|
|
+
|
|
|
+Tests are used to check the proper functioning of the application. For time reasons, this quality goal was neglected for Hybrid \ac{OSN} and thus not achieved. In principle, however, the testing of ionic applications is possible.
|
|
|
+
|
|
|
+The source code should be managed as an open source project to increase confidence in the application. Although version management is used with Git and is also centrally managed on the Git server of the Telecommunication Working Group, the code is not freely accessible here. Thus Hybrid OSN cannot be considered an open source application.
|
