The Cloud Browser differs from traditional browsers in that web pages are rendered in the cloud and only the UI output of the web page is streamed to the client using appropriate video streaming technologies. The Client is in general a simple device that is only capable to decode and play a video stream. It doesn't have the capabilities to run a Browser, render web pages or perform computing intensive operations. It only offers capability to interact with the user e.g. using Remote Control. All user interactions need to be sent to the cloud browser and triggered on the corresponding web page.
One potential use case of cloud browser is a Set-Top-Box that runs in the cloud. The operator provides low performance and cheap devices to costumers that connect to its cloud infrastructure. In this case, the operator doesn't need to supply new kind of devices if he wants to offer new services that requires new hardware or software capabilities. Using the Cloud Browser solution, he needs only to update the cloud browser software stack for all customers at once. Another use case is the rendering of 360° Video in the cloud instead of the local browser. The approach has two main advantages: (1) there is no need to stream the whole 360° video to the client, but only the view requested by the user and (2) there is no need to render the 360° video locally which requires expensive computing operations.
One important requirement for Cloud Browsers is the zero-latency streaming of the current view. The time between a user interaction and the receiving of the corresponding frames that show the effect of his interaction must not exceed a threshold of few milliseconds. The WebRTC technology could be one potential technology that fulfills this requirement.
- You will implement a Cloud Browser framework that includes the following components:
- Server that offers the Cloud Browser functionality and is capable to serve multiple users and sessions in parallel. The Server should also offer an API for receiving user inputs.
- Client that offers a player for video stream received from the cloud browser and is capable to open new sessions on the Cloud Browser using appropriate APIs. The Client needs also to intercept user inputs and send them to the server. The Client may be implemented on low capability devices
Decentralized user-friendly instant messaging
How will we do messaging in future?
E-Mail and the Web are two famous examples of ubiquitous decentralized systems we use on a daily basis. This both open standards based services have driven and still drive innovation and products world-wide over the last decades. On the other hand most of us use instant messaging services that are centralized and mostly owned by singe entities. Must this remain forever? The goal of this semester project is to understand, elaborate and explore in practice how a decentralized user-friendly instant messaging works.
- Research and evaluate existing decentralized open-source messaging systems
- Analyse requirements with regard to decentralization and user-friendliness, define a feature set (in consultation with supervisor)
- Integrate a fully functional federated messaging system and understand its API
- Develop an own user-friendly messaging user interface (primary targeted: Web browsers, but mobile Apps with Web engines possible if knowledge sufficient)
- Optionally: integrate end to end secure audio/video communication (without central authorities or central signaling)
- Good knowledge in HTTP, HTTP/2, WebRTC, TLS, DNS/DDNS, p2p networks (required to be able to understand, explain and use the chosen federated pods and communication)
- Basic knowledge in Node.js or python or ruby or similar scripting languages (to be able to setup and extend the federated pods with regard to agreed feature set)
Basic knowledge in front-end development (to be able to design and realize an user-friendly messaging user interface) with e.g. Vue.js
- No fears of contacts with regard to system integration and deployment e.g. with Docker and Kubernetes
- Matrix defines a set of open APIs for decentralised communication, suitable for securely publishing, persisting and subscribing to data over a global open federation of servers with no single point of control.
- Social networking, back in your hands
- Solid (derived from "social linked data") is a proposed set of conventions and tools for building decentralized social applications based on Linked Data principles.
- The ActivityPub protocol is a decentralized social networking protocol
Supervisor: Martin Lasak
Develop student signup website with React
Develop frontend and backend for a web application where students as a group can sign up to projects and where administrators can offer projects as well as view and managed students that signed up for a project.
- Design a layout with the required UI components
- Students should see one page with all projects categorized by topic
- Each project has a title, a description and requirements
- Students should be able to pick maximum three projects and register with their name, email and matriculation number
- Students can also give the names and emails of their group members
- Administrators have a password protected page where they can add new projects with title, description and category
- Administrators can see which students registered for which projects
- Handle Students that signed up multiple times as a group
- Design a HTTP REST API for the backend that supports all of the above points
- Student registrations and projects are saved to a SQL database
- Data that is saved in the database needs to be compliant as outlined in the GDPR
- Prior knowledge of React is a plus