Analysis of Functionality and Data Models of Social Network Services, Proposal of a protocol based on XMPP/Publish-Subscribe, Comparison to OStatus and OneSocialWeb, Discussion of Inbox

abstract: The Open Services Gateway initiative (OSGi) framework is a standard of module system and service platform that implements a complete and dynamic component model. Currently most of OSGi implementations are implemented by Java, which has similarities of Android language. With the emergence of Android operating system, due to the similarities between Java and Android, the integration of module system and service platform from OSGi to Android system attracts more and more attention. How to make OSGi run in Android is a hot topic, further, how to find a mechanism to enable communication between OSGi and Android system is a more advanced area than simply making OSGi running in Android. This paper, which aimed to fulfill SOA (Service Oriented Architecture) and CBA (Component Based Architecture), proposed a solution on integrating Felix OSGi platform with Android system in order to build up Distributed OSGi framework between mobile phones upon XMPP protocol. And in this paper, it not only successfully makes OSGi run on Android, but also invents a mechanism that makes a seamless collaboration between these two platforms. / Dissertation/Thesis / M.S. Computer Science 2012

Analysis of Functionality and Data Models of Social Network Services, Proposal of a protocol based on XMPP/Publish-Subscribe, Comparison to OStatus and OneSocialWeb, Discussion of Inbox:Contents i List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii 1 Introduction 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 buddycloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Aspects of Social Networks 5 2.1 User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Social Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Topology Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1 Centralized Topology . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.2 Decentralized Topology . . . . . . . . . . . . . . . . . . . . . . 8 2.3.3 Federated Topology . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 Privacy Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.2 Data Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 Data Portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3 Requirements 15 3.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.2 Content Model . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.3 Content Distribution as a Publish-Subscribe System . . . . . . 18 3.1.4 Access Control & Roles . . . . . . . . . . . . . . . . . . . . . . 19 3.1.5 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.6 Interaction with Mobile Users . . . . . . . . . . . . . . . . . . 23 3.2 Non<AD>functional Requirements . . . . . . . . . . . . . . . . . . . . . . 24 3.2.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.2 Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 System Design 27 4.1 Use of XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.2 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.3 XMPP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.4 Federated Topology . . . . . . . . . . . . . . . . . . . . . . . . 30 4.1.5 Causal Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2 XMPP Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2.1 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3 XEP-0060 Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.1 Affliations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.4 Content Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4.1 ATOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.4.2 Discussion Threading . . . . . . . . . . . . . . . . . . . . . . . 36 4.4.3 Activity Stream Semantics . . . . . . . . . . . . . . . . . . . . 36 4.4.4 Geolocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.4.5 Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4.6 Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.5 buddycloud Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.5.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.5.2 Partial Data Transfer . . . . . . . . . . . . . . . . . . . . . . . 42 4.5.3 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.6 Comparison to Other Federated Systems . . . . . . . . . . . . . . . . 51 4.6.1 OStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6.2 OneSocialWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5 Implementation 57 5.1 Setup Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.1.1 Required DNS Configuration . . . . . . . . . . . . . . . . . . . 57 5.1.2 BOSH Endpoint Deployment . . . . . . . . . . . . . . . . . . 58 5.2 Service Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.1 Network Services as Proxies . . . . . . . . . . . . . . . . . . . 58 5.2.2 Database Backend . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Web-based Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.3.1 Client-Side Model . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.2 In-Browser Caching . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.3 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6 Evaluation 65 6.1 Suitability of XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.1.1 Binary Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.2 Suitability of Publish-Subscribe . . . . . . . . . . . . . . . . . . . . . 66 6.2.1 Inboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.2.2 Privacy Considerations . . . . . . . . . . . . . . . . . . . . . . 68 6.2.3 Message Archive Management . . . . . . . . . . . . . . . . . . 68 6.3 Anonymous Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Bibliography 71

<p>Opera är främst en webbläsare, men innehåller även klienter för bl.a. mail och chat. Innan den här rapporten skrevs saknades dock en klient för instant messaging-protokollet Jabber. Denna rapport beskriver arbetsgången och resultatet av utvecklandet av en Jabberklient till Opera.</p><p>Eftersom det inte fanns nog med tid att utveckla en fullfjädrad Jabberklient beslutades det att målet skulle vara ett s.k. ”proof of concept”. Kraven sattes till grundläggande instant messagingfunktionalitet, som närvarostatushantering och möjlighet att skicka och ta emot meddelanden.</p><p>Målet uppfylldes och resultatet blev en Jabberklient med grundläggande funktionalitet. I enlighet med direktiven lades relativt lite fokus på gränssnittet. Klienten har kända brister och användarvänligheten går att öka.</p><p>Resultatet skulle kunna utgöra grunden för en komplett Jabberklient. Kvar att göra är att förbättra gränssnittet för att matcha resten av Opera i användbarhet. Alla krav i Jabberspecifikationen bör också uppfyllas, speciellt eftersom företaget är stolt över att Opera följer standarder väl1. För att inte vara sämre rustad än andra Jabberklienter bör även extra funktionalitet läggas till, såsom samtalshistorik, filöverföring och möjligheten att använda andra instant messaging-protokoll via Jabberkontot.</p> / <p>Opera is first and foremost a web browser, but it also has e-mail and chat clients. Before this thesis was written however, it did not have a client for the instant messaging protocol Jabber. This thesis describes the workflow and the results of the development of a Jabber client for Opera.</p><p>Since there wasn’t enough time to develop a full-featured Jabber client, it was decided that the goal would be a proof of concept. The requirements were basic instant messaging functionality, which means the proper handling of presence information and the ability to send and receive instant messages.</p><p>The goal was achieved and the result was a Jabber client with basic functionality. In accordance with the directives, the user interface was not a primary focus. The client has known flaws and the usability is not as good as it could be.</p><p>The result could be used as the foundation of a releasable Jabber client. One of the things left to do is to improve the user interface so it matches the usability of the rest of Opera. All the requirements of the Jabber specification should also be fulfilled, especially since the company takes pride in the standards compliance of Opera2. In order to match the features of other Jabber clients, extra functionality should be added as well. Some examples would be message history, file transfer and the ability to use other instant messaging protocols through the Jabber account.</p>

Större kommuner och industrier använder alltmer automatiserade processer för tjänster och rutinerså som kundcenter och felhantering. Flexeurope AB är ett företag med flera års erfarenhet av auto-matiserade processer och arbetar med att definiera, visualisera, konstruera och optimera processer.Företaget utvecklar även ett webbaserad IT-system för processhantering, kallat flexiteBPMS. Inom en kommun eller industri arbetar ofta flera handläggare, ibland uppemot hundratals, med atthantera ärenden i processer. Detta ställer krav på att handläggare kan kommunicera med varand-ra. Effektivare kommunikation där handläggare snabbare får svar innebär effektivare hantering avärenden. Marknaden har till följd av detta uttryck önskningar om att möjliggöra en form av realtids-kommunikation kring ärenden i flexiteBPMS. Med detta som bakgrund har det här arbetet undersökt, planerat och genomfört en integration av enXMPP-baserad chatt med flexiteBPMS. Det slutgiltiga integrerade systemet möjliggör för handläggareatt chatta med andra handläggare samt att spara delar av en chattkonversation som ett meddelandekopplat till ett ärende; alternativt att skapa ett nytt ärende i flexiteBPMS. Resultatet av arbetet inne-bär, vid eventuell framtida lansering, bättre förutsättningar för handläggare att effektivare utföra sittarbete, vilket medför att tiden för ärendehantering kan reduceras. / Municipality, large enterprises and companies are using more and more automated processes forprocedures such as service recovery and customer services. Flexeurope AB is a company speciali-zed in business process automation and it has several years of experience of defining, visualizing,constructing and optimizing processes. The company is also developing a commercial web basedapplication for managing processes called flexiteBPMS. Within a municipality or enterprise it is not unusual that a large amount of administrators and caseworkers are dealing with processes and errands. In large organizations, who may consisting of up toa hundred case workers, the communication possibilities are vital for the work effectiveness, whenadministrators needs information from each other. Due to this realization Flexeurope AB have recei-ved requests of enabling another type of communication in flexiteBPMS. As a result of the above described background, this work have studied, planned and carried outan integration of a XMPP based instant messaging system, called chat, with flexiteBPMS. The final,integrated system enables peer-to-peer conversation in real time between case workers and offers thepossibility to save a chat conversation in flexiteBPMS, either as a message linked to an errand or as anew errand connected to a process. The result of this work, in case of a possible future launch, wouldinduce for administrators to work more effective and in course of time this means a reduced time forhandling of a matter.

Táto práca sa venuje probému prepojovania rôznych typov sietí, konkrétne sietí typu IEEE 802.15.4 a Ethernetu. Motivácia vychádza zo stále sa rozširujúceho využitia bezdrátových senzorických sietí, potreby zberu dát z nich a ich integrácie. To vyžaduje aby sieť obsahovala prvky schopné preniesť dáta z bezdrátovej siete do okolitého sveta a prípadne poskytnúť konfiguračné a riadiace informácie do vnútra siete. Z hľadiska protokolov a programového vybavenia sa prepojenie uskutočňuje na rôznej úrovni, od sieťovej až po aplikačnú vrstvu komunikačného modelu ISO/OSI, s podporou hardvéru na fyzickej a linkovej vrstve.

The aim of this master thesis is to design and create the whiteboard application which allows to draw and share multimedia content in realtime using protocol XMPP between two users in the network environment. Application is a part of the open source IM client Kopete in KDE and operation system Linux.

Every day there are internet users all over the world who sends a total sum of millions of emails and instant messages and a majority of these are sent and transmitted without any form of encryption. When we send an unencrypted message it can be monitored, analyzed and even stored by organiza-tions and individuals. Therefore using encrypted communication is vital for not having our privacy violated. One of the problems that needs to be solved is to allow two persons to communicate in (near) real time through text over internet in a secure and easy way for the user, while at the same time allowing the user to have a good experience and maintaining confidentiality. The chat client should be able to communicate with other platforms than only itself and must therefore use and fol-low an existing protocol for instant messaging. To receive a true end-to-end encryption, all data needs to be encrypted and decrypted locally on the user's computer before it is sent out on the inter-net. SSL / TLS can be used as a protective layer, but it must be complemented by an extra and sepa-rate layer of encryption since SSL / TLS is not an authentic end-to-end encryption. This is because of the SSL data is decrypted when they land on the server, while true end-to-end data is only de-crypted locally on the receivers computer. This thesis have resulted in a working chat client built on the XMPP protocol with support for using OTR encryption that offers true end-to-end encryption. / Varje dag finns det internetanvändare världen över som sammanlagt skickar miljontals email och direktmeddelanden vilka majoriteten skickas och överförs utan någon form utav kryptering. När vi skickar ett okrypterat meddelande kan det bli övervakat, analyserat och till och med lagrat utav or-ganisationer och individer. Därför är användande utav krypterad kommunikation avgörande för att inte vår integritet ska kränkas. Ett utav problemen som behöver lösas är att tillåta två personer att kommunicera i (nära) realtid genom text över internet på ett säkert och enkelt sätt för användaren. Detta samtidigt som användaren har en bra användarupplevelse och bibehåller konfidentialitet. Chattklienten ska kunna kommunicera med andra plattformar än sig själv och måste därmed an-vända sig utav och följa ett existerande protokoll för direktmeddelanden. För att få en riktig end-to-end kryptering måste all data krypteras och dekrypteras lokalt på användarens dator innan det skickas över internet. SSL / TLS kan användas som ett skyddande lager, men måste kompletteras av ett extra och separat lager av kryptering då SSL / TLS inte är äkta "end-to-end" kryptering. Detta är på grund utav att SSL data är dekrypterad när det kommer till servern, medan äkta "end-to-end" kryptering endast är dekrypterat lokalt på mottagarens dator. Denna avhandling resulterade i en fungerande chattklient byggt på XMPP protokollet med stöd för OTR kryptering som erbjuder äkta "end-to-end" kryptering.

The aim of the "Shared Board" project is to design and implement an application that will allow a real-time collaboration on workgroup projects in a network environment. The communication can be accomplished using Instant Messaging or multimedia whiteboard with a possibility of drawing, attaching interactive objects and combined with voice and video communication. The term project part solves utilization of interactive whiteboards, design of communication protocol and grafical user interface. Implementation is solved as masters thesis part.

Das Internet of Things (IoT) ist aktuell ein junger Wachstumsmarkt, dessen Bedeutung für unsere Gesellschaft in naher Zukunft vielen Menschen erst noch wirklich bewusst werden wird. Die Subdomänen Smart-Home, Smart-Grid, Smart-Mobility, Industrie 4.0, Smart-Health und viele mehr sind wichtig für unsere zukünftige Wettbewerbsfähigkeit, die Herausforderungen zur Bewältigung des Klimawandels, unsere Gesundheit, aber auch für trivialere Dinge wie Komfort. Andererseits ergibt sich hierbei bereits dasselbe große Problem, das in einer ähnlichen Form schon bei klassischem Cloud-Computing bekannt ist: Vendor-Silos, die keinen hersteller- oder anbieterübergreifenden Austausch von Gerätedaten ermöglichen, verhindern eine schnelle Verbreitung dieser neuen Technologie. Diensteanbieter müssen ihre Produkte aufwendig für unzählige Technologien bereitstellen, was die Entwicklung von Diensten unnötig teuer macht und letztendlich das Dienstangebot insgesamt einschränkt. Cloud-Computing wird dabei in Zukunft eine wichtige Rolle spielen. Die Dissertation beschäftigt sich daher mit dem Problem IoT-Gerätedaten an IoT-Clouds plattformübergreifend und anbieterübergreifend nutzbar zu machen. Die Motivation und die adressierte Forschungslücke zeigen die Notwendigkeit der Beschäftigung mit dem Thema auf. Ausgehend davon, wird das Konzept einer dezentral organisierten IoT-Intercloud vorgeschlagen, welches in der Lage ist heterogene IoT-Clouds zu integrieren. Die Analyse des Standes der Technik zeigt, das IoT-Clouds genügend Eigenschaften teilen, um in Zukunft eine Adaption zu einer einheitlichen Schnittstelle für die IoT-Intercloud zu schaffen. Das Konzept umfasst zunächst die Komponentenarchitektur eines Intercloud-Brokers zur Etablierung einer IoT-Intercloud. Ausgehend davon wird in vertiefenden Teilkonzepten ein Discovery-Service zum Finden von Gerätedaten und einem Push-Stream-Provider, für die Zustellung von IoT-Event-Notifications in Echtzeit, behandelt. Eine Evaluation zeigt letztlich die praxistaugliche Realisierbarkeit, Skalierbarkeit und Performance der Konzeption und des implementierten Prototyps.