Spelling

README.md

@@ -80,8 +80,8 @@ The defined milestones give detailed descriptions on what should be when achieve
 
 ##### Solid Pod
 
-- [Docker Let's Encrypt & NGiNX-proxy](https://github.com/nginx-proxy/docker-letsencrypt-nginx-proxy-companion)
-- [DigitalOcean NGiNX reverse proxy](https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-web-server-and-reverse-proxy-for-apache-on-one-ubuntu-20-04-server)
+- [Docker Let's Encrypt & NGINX-proxy](https://github.com/nginx-proxy/docker-letsencrypt-nginx-proxy-companion)
+- [DigitalOcean NGINX reverse proxy](https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-web-server-and-reverse-proxy-for-apache-on-one-ubuntu-20-04-server)
 - [Let's Encrypt](https://letsencrypt.org/getting-started/)
 - [Node.js Solid server: HTTP request handling flow](https://github.com/solid/solid-architecture/blob/master/server/request-flow.md)
 - [Solid server – Selected architectural diagrams v1.3.0](https://rubenverborgh.github.io/solid-server-architecture/solid-architecture-v1-3-0.pdf)

notes/pod.md

@@ -4,7 +4,7 @@
 
 ### Containerized
 
-- [NGiNX proxy with Let's Encrypt certificates](https://github.com/evertramos/docker-compose-letsencrypt-nginx-proxy-companion), only problem when using this: [Running Solid behind a reverse proxy](#running-solid-behind-a-reverse-proxy)
+- [NGINX proxy with Let's Encrypt certificates](https://github.com/evertramos/docker-compose-letsencrypt-nginx-proxy-companion), only problem when using this: [Running Solid behind a reverse proxy](#running-solid-behind-a-reverse-proxy)
 - [https://github.com/angelo-v/docker-solid-server](https://github.com/angelo-v/docker-solid-server) provides a one-click solution. I think this uses single-user mode though.
 
 ### Running Solid behind a reverse proxy
@@ -54,10 +54,10 @@ This is strictly speaking not needed and at the moment not being capitalized. A
 
 >One of Solid's authentication mechanisms is WebID-TLS: the client [sends its client certificate during the TLS handshake](https://blog.cloudflare.com/introducing-tls-client-auth/#handshakeswithtlsclientauth). However, by default, this requires the client to set up a TLS connection directly with the Solid server: if the TLS handshake is performed by an intermediary, the Solid server cannot see the client certificate [Source](https://github.com/solid/node-solid-server/wiki/Running-Solid-behind-a-reverse-proxy).
 
-Configuration for NGiNX as reverse proxy to make it work with the Node Solid Server (NSS).
+Configuration for NGINX as reverse proxy to make it work with the Node Solid Server (NSS).
 
 ```
-# Configuration for NGiNX as reverse proxy
+# Configuration for NGINX as reverse proxy
 # Nginx configuration for Solid on Port 8443
 ## Redirects all HTTP traffic to the HTTPS host
 server {
@@ -116,7 +116,7 @@ root /var/www/janschill.de; #webroot
 
 *[Source for the configuration](https://solidproject.org/for-developers/pod-server/nginx)*
 
-Restart NGiNX
+Restart NGINX
 
 ```bash
 systemctl restart nginx
@@ -177,8 +177,8 @@ mkdir /var/www/janschill.de/.db
 ## Lessons learned
 
 - Wildcard certificates are not available with the popular Let's Encrypt Docker image. This is because it does not support. More information around this, can be found in this [issue](https://github.com/nginx-proxy/docker-letsencrypt-nginx-proxy-companion/issues/319). Why was this needed in the first place? Because when wanting to set up and run a multiuser Solid pod, wildcard certificates are needed, as the server will create {username}.janschill.de subdomains to host their user base.
-  - [Docker NGiNX with Let's Encrypt](https://github.com/evertramos/docker-compose-letsencrypt-nginx-proxy-companion)
-  - [Docker with Solid pod, NGiNX reverse proxy, Let's Encrypt](https://github.com/angelo-v/docker-solid-server/blob/master/examples/docker-compose.all-in-one.yml). This is nice, but only allows single-user mode and not multiuser.
+  - [Docker NGINX with Let's Encrypt](https://github.com/evertramos/docker-compose-letsencrypt-nginx-proxy-companion)
+  - [Docker with Solid pod, NGINX reverse proxy, Let's Encrypt](https://github.com/angelo-v/docker-solid-server/blob/master/examples/docker-compose.all-in-one.yml). This is nice, but only allows single-user mode and not multiuser.
   - When setting up the one-click version use janschill.de as host
 - Running Solid behind a reverse proxy. [Source](https://github.com/solid/node-solid-server/wiki/Running-Solid-behind-a-reverse-proxy)
 - Do not use certbot-auto with Ubuntu

notes/solid.md

@@ -35,7 +35,7 @@ Notes and direct quotes from the paper "A Demonstration of the Solid Platform fo
 
 ## Abstract
 
-* "Users' data is managed independetly of the applications that create and consume this data."
+* "Users' data is managed independently of the applications that create and consume this data."
 * "Users store their data in a Web-accessible personal online datastore (pod)."
 * "Users can have multiple pods and easily switch between them."
 * "Applications access the data using defined protocols."

report/report/evaluation-solid-implementations.md

@@ -23,7 +23,7 @@ TODO: More here
 
 The original Solid server was developed at the Massachusetts Institute of Technology (MIT) by PhD students. This server is still to this day the only server that passes most test cases of the [Solid Test Suite](https://github.com/solid/test-suite), which is a set of checks developed to test an implementation against the Solid specifications. The Test Suite for Solid is also still in development and constantly extended by more tests for the different categories of a Solid server.\
 This server is completely open-source, written in JavaScript with the help of the web framework Node.js and is commonly referred to as Node Solid Server (NSS).\
-NSS implements a pod server and and identity provider (IDP), meaning users can register a WebID, create a data pod and authenticate with it.
+NSS implements a pod server and identity provider (IDP), meaning users can register a WebID, create a data pod and authenticate with it.
 https://inrupt.net/ and https://solidcommunity.net/ [[Source]](https://solidproject.org//users/get-a-pod) are currently the two domains hosting the NSS and allowing users to register and use these services.
 
 Because NSS was started as a research project, the code base was subject to a lot of experiments. These experiments were sometimes successful and improved the server experience by implementing useful functionality, but sometimes it would also introduce vulnerabilities or not yield the expected outcomes.

thesis/latex/sections/03a-proof-of-concept.tex

@@ -5,7 +5,7 @@ \section{Proof of Concepts}
 The goal of these modules is the symbiosis of decentralized stored data in a highly functional system without comprising its \textit{Performance}, \textit{Security}, or \textit{Usability}.
 
 % subsection POC A
-\input{thesis/latex/sections/03aa-commeting-module}
+\input{thesis/latex/sections/03aa-commenting-module}
 \newpage
 % subsection POC B
 \input{thesis/latex/sections/03ab-conference-registration}

thesis/latex/sections/03aa-commeting-module.tex → thesis/latex/sections/03aa-commenting-module.tex

@@ -27,7 +27,7 @@ \subsubsection{Architectural Analysis and Synthesis}\mbox{}\\
 \vspace{0.5cm}
 \paragraph{Type of Users}\mbox{}\\
 
-There are two types of users in the system. The first group of users is the active authors of comments or observers of such. These will interact with the module by logging in to their data pod and compose comments. The other subset of users is the administrators of the application (Indico). This type of user is interested in keeping the tone of comments to the community guidelines and not allow any misuse.
+There are two types of users in the system. The first group of users is the active authors of comments or observers of such. These will interact with the module by logging into their data pod and compose comments. The other subset of users is the administrators of the application (Indico). This type of user is interested in keeping the tone of comments to the community guidelines and not allow any misuse.
 \vspace{0.5cm}
 \paragraph{Context Diagram}\mbox{}\\
 

thesis/latex/sections/03ab-conference-registration.tex

@@ -184,7 +184,7 @@ \subsubsection{Integration With Indico}\mbox{}\\
   const callback = (mutationsList, observer) => {
     // Contains all mutations in the targetNode
     for (const mutation of mutationsList) {
-      // Node has beed added or removed
+      // Node has been added or removed
       if (mutation.type === 'childList') {
         // Look at all added nodes
         for (const node of mutation.addedNodes) {

thesis/latex/sections/04-conclusion.tex

@@ -5,7 +5,7 @@ \chapter{Conclusion}
 
 The paper presented two working Solid apps embedded into Indico and has shown how data can reside in user's control while still be served purposeful to others. The applications have also shown how existing information in one's data pod can be used in other systems. These two insights from storing data outside of Indico and enabling information to flow back into the system has shown admirable features for the future of the Web: control through external data pods and reuse thanks to interoperable data formats of Linked Data. The third principle of Solid, decentralized authentication was also enabled and necessary for the development, but had a lesser impact due to restricting the prototype to only Indico and not guiding testing participants to other applications. Further, a decentralized \gls{sso} service is already in use at \gls{cern}.
 
-The implementation of Solid comes with imperfections. The detailed analysis and evaluation of the Solid apps have shown those flaws in the synergy between Indico and Solid principles. The flaws being mainly performance regressions in the retrieval and distribution of data from several external data pods. Where in centralized systems the data is stored in one place and can be processed and prepared for clients neatly, in a decentralized architecture several requests are required to retrieve the data first. The prototypes' design was as decoupled as possible from Indico to not infiltrate Indico's functionality and allow other systems to integrate the modules as well. The decoupling has proven that the two systems are too distant and implementations need to be closer to Indico. A more imminent solution means Indico is required to change too. The data flow from the data pod back in to Indico, as demonstrated in the second implementation of the \gls{poc}, is challenging by reason of lacking any semantic structure whatsoever in Indico.
+The implementation of Solid comes with imperfections. The detailed analysis and evaluation of the Solid apps have shown those flaws in the synergy between Indico and Solid principles. The flaws being mainly performance regressions in the retrieval and distribution of data from several external data pods. Where in centralized systems the data is stored in one place and can be processed and prepared for clients neatly, in a decentralized architecture several requests are required to retrieve the data first. The prototypes' design was as decoupled as possible from Indico to not infiltrate Indico's functionality and allow other systems to integrate the modules as well. The decoupling has proven that the two systems are too distant and implementations need to be closer to Indico. A more imminent solution means Indico is required to change too. The data flow from the data pod back into Indico, as demonstrated in the second implementation of the \gls{poc}, is challenging by reason of lacking any semantic structure whatsoever in Indico.
 
 The \glspl{poc} and analyses have displayed that decentralization brings many challenges for the development of applications. However, as Tim Berners-Lee once said: “Data is a precious thing and will last longer than the systems themselves.” it is sensible to decouple applications from data to allow innovation not through owning data, but by building applications without relying on having the data.