Fakult¨at Ingenieurwissenschaften und Informatik

Masterarbeit

uber¨ das Thema

Mit anderen agieren: dezentrales pump.io und etablierte Soziale Netzwerke

vorgelegt durch Mathias Gebbe [email protected] Matrikelnummer: 395409

Erstpruferin:¨ Frau Prof. Michaela Ramm

Zweitprufer:¨ Dipl.Systemwiss., MSc. Bernhard E. Reiter

Abgabedatum: 20.08.2014 ^^ ^^ .. .. [] [] .:[]:_ ^^ ,:[]:. .: :[]: :-. ,-: :[]: :. .: : :[]: : :‘._ ,.’: : :[]: : :. .: : : :[]: : : : :-._ _,-: : : : :[]: : : :. _..: : : : :[]: : : : : : :-.______.-: : : : : : :[]: : : : :-._ _:_:_:_:_:_:[]:_:_:_:_:_:_:_:_:_:_:_:_:_:_:_:_:_:_:_:[]:_:_:_:_:_:_ !!!!!!!!!!!![]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![]!!!!!!!!!!!!! ^^^^^^^^^^^^[]^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^[]^^^^^^^^^^^^^ [] [] [] [] [] [] ~~^-~^_~^~/ \~^-~^~_~^-~_^~-^~_^~~-^~_~^~-~_~-^~_^/ \~^-~_~^-~~- ~ _~~- ~^-^~-^~~- ^~_^-^~~_ -~^_ -~_-~~^- _~~_~-^_ ~^-^~~-_^-~ ~^ ~ ^- _~~_- ~~ _ ~ ^~ - ~~^ _ - ^~- ~ _ ~~^ - ~_ - ~^_~ ~- ^_ ~^ - ^~ _ - ~^~ _ _~^~- _ ~~^ - _ ~ - _ ~~^ - ~^ -_ ~^^ -_ ~ _ - _ ~^~- _~ -_ ~- _ ~^ _ - ~ ^- ~^~ - _ ^ - ~~~ _ - _ ~-^ ~ __- ~_ - ~ ~^_- ~ ~- ^~ - ~^ - ~ ^~ - ~~ ^~ - ~

Ein besonderer Dank gilt meiner Professorin Michaela Ramm und meinem Betreuer Bernhard Reiter. Weiter m¨ochte ich mich herzlich bei den Admins Sascha & Thomas und der gesamten Intevation GmbH bedanken. Danke an meine Eltern, Maili und alle echten Freunde. KURZFASSUNG

I Kurzfassung

Die vorliegende Arbeit besch¨aftigt sich mit der Konzeptionierung und dem Entwurf einer Architektur, die bidirektional Nachrichten und Aktionen zwischen etablierten zentrali- sierten Sozialen Netzwerken und dem auf Freie Software basierenden dezentralen Sozialen Netzwerk pump.io austauscht. Im Gegensatz zu den verbreiteten unidirektionalen Cross- posting-Werkzeugen, werden Inhalte und Metainformationen in beide Richtungen ausge- tauscht und Informationen uber¨ die Grenzen von Sozialen Netzwerken hinweg vermittelt. Ziel ist es zu kl¨aren, inwiefern sich die vorhandenen Schnittstellen und Strukturen eige- nen, einen gemeinsamen konsolidierten Informationsstrom bereitzustellen, anzuzeigen und zu verarbeiten. Mit der Brucke¨ zwischen den Netzwerken werden Benutzer und Inhalte von außerhalb in das dezentrale Soziale Netzwerk eingebunden, um damit die sogenannte kritische Masse zu erreichen. Benutzer sollen dadurch animiert werden, die alternative Plattform, die großen Wert auf Datenschutz und Privatsph¨are legt, dauerhaft zu nutzen. Durch den durchgefuhrten¨ Machbarkeitsnachweis und die daraus resultierenden Ergebnis- se wird deutlich, dass sich die offiziellen restriktiven Schnittstellen der etablierten Netze kaum eignen dieses Ziel zu erreichen. Es wird klar, dass durch die Zusammenfuhrung¨ meh- rerer unterschiedlich priorisierter Informationsstr¨ome die Ubersicht¨ verloren gehen kann und eine intelligente Filterung und Sortierung im Server oder Client notwendig wird. Abstract The present paper deals with the conceptual design and development of a software that is able to share messages and actions bidirectional between established centralized social networks and the distributed social network pump.io, which is Free Software. Compared with unidirectional crossposting tools the software shares content and meta-information in both directions beyond the borders of only one social network. A goal is to clarify if the existing interfaces and structures are able to provide, display and process one consolidated stream of information. By the integration of content to the decentralized social network the bridge trys to reach the critical mass and nonetheless provide data protection and privacy to users. The proof of concept implementation shows that the official restrictive interfaces of the established networks cannot achieve this goal. It also shows that a user may lose track of information by merging multiple different prioritized streams. It is necessary to filter and sort the combined stream (messages, videos, pictures etc.) by the server or client.

Seite I INHALTSVERZEICHNIS

II Inhaltsverzeichnis

I KurzfassungI

II InhaltsverzeichnisII

III AbbildungsverzeichnisIV

IV TabellenverzeichnisVI

V Listing-VerzeichnisVII

1 Einfuhrung¨ 1 1.1 Einfuhrung¨ in die Thematik...... 1 1.2 Motivation und Ziele...... 9 1.3 Aufbau der Arbeit ...... 12

2 Stand der Wissenschaft (State of Social Media) 12 2.1 Typen Sozialer Netzwerke ...... 13 2.1.1 Zentrale Netzwerke...... 13 2.1.2 Dezentrale Netzwerke...... 14 2.1.3 Vollst¨andig verteilte Netzwerke ...... 15 2.2 Etablierte Soziale Netzwerke...... 15 2.3 Funktionen in Sozialen Netzwerken ...... 19 2.4 Das dezentrale Soziale Netzwerk pump.io...... 29 2.4.1 Endpunkte...... 31 2.4.2 Zustellen von Aktivit¨aten ...... 32 2.4.3 Probleme und Risiken ...... 35 2.5 Rechtliches ...... 37

3 Konzeption 41 3.1 Die Nachricht im Sozialen Netzwerk...... 41 3.1.1 Facebook ...... 46 3.1.2 Googleplus...... 47 3.1.3 Twitter ...... 48 3.1.4 pump.io...... 49 3.2 Bidirektionale Kommunikation zwischen mehreren Sozialen Netzwerken . . 50 3.2.1 Zu etablierten Sozialen Netzwerken kommunizieren ...... 52 3.2.2 Von etablierten Sozialen Netzwerken zu pump.io kommunizieren . . 60 3.2.3 Eine gemeinsame Sprache ...... 64 3.3 Anwendungsf¨alle und Szenarien...... 65 3.3.1 Mehrwert ...... 68 3.4 Architektur ...... 70 3.4.1 Proxy-Benutzer – Zustellung uber¨ Stellvertreter...... 71 3.4.2 Allgemein repr¨asentativer Benutzer in pump.io...... 74 3.5 Daten und Inhalt – Referenz oder Kopie ...... 75 3.6 Datenschema ...... 82

Seite II INHALTSVERZEICHNIS

3.7 Filterung des zusammengefuhrten¨ Streams...... 83 3.8 Probleme und Grenzen...... 85

4 Implementierung – Proof of Concept 87 4.1 Planung ...... 87 4.1.1 Angeschlossene etablierte Netzwerke ...... 88 4.2 Software und Betrieb...... 89 4.2.1 Verwendete Werkzeuge...... 89 4.2.2 Arbeitsweise und Betrieb...... 90 4.2.3 Restriktive Schnittstellen...... 94 4.3 Messung...... 95 4.3.1 Testumgebung und gemessene Daten ...... 96 4.3.2 Evaluierung...... 98 4.3.3 Resonanz ...... 100

5 Fazit 103 5.1 Ausblick...... 104

Quellenverzeichnis 105

Abkurzungsverzeichnis¨ 111

Glossar 112

Anhang 114 Inhalt der CD...... 119

Eidesstattliche Erkl¨arung 120

Seite III VERZEICHNISSE

III Abbildungsverzeichnis Abb. 1 Social Software Vulkan. Weiterentwicklung des Dreiecksmodells [Ehm10]3 Abb. 2 Der Netzwerkeffekt ...... 7 Abb. 3 Ziel: Der Pump.io-Client (mitte) als Multiplexer zwischen Etablierten Sozialen Netzwerken und Empf¨anger eines synthetisierten Feeds . . . 12 Abb. 4 (a) Zentrale (b) Dezentrale und (c) Verteilte Peer to Peer (P2P) Netz- werke [Bar64] ...... 14 Abb. 5 Nutzerzahlen in etablierten und dezentralen Sozialen Netzwerken welt- weit [Jun14][rob14][jpo14]...... 17 Abb. 6 Social Media und soziale Netzwerke – Nutzerzahlen in Deutschland 2014 [Bug14]...... 17 Abb. 7 Die Funktionen des IT-gestutzten¨ Social Networking nach Richter et. al.[RK08]...... 22 Abb. 8 Detailierte Funktionen in einer Auswahl von Sozialen Netzwerken als Grundlage fur¨ eine gemeinsame Basis ...... 27 Abb. 9 Ein beispielhafter Sozialer Graph des fiktiven Nutzers Maili, wie er in Sozialen Netzwerken entsteht...... 28 Abb. 10 Vereinfachtes Flussdiagramm zur Auslieferung einer Aktivit¨at . . . . . 33 Abb. 11 Das Kommunikationsquadrat von Friedemann Schulz von Thun. Jede Außerungen¨ enth¨alt vier Botschaften [Gem14] [Thu14]...... 44 Abb. 12 Schematischer Aufbau einer Nachricht aus Sozialen Netzwerken; ein- deutiger Identifizierer, Zeit, Absender, Empf¨anger, Inhalt, Favorisie- rung, Kommentare und Verteilung...... 44 Abb. 13 Typischer Facebook-Post mit Bild (von einem Upload per Handy) mit Kommentaren...... 47 Abb. 14 Typischer Googleplus-Post an eine Community (Gruppe) mit Kom- mentaren uber¨ die Web-UI abgerufen ...... 48 Abb. 15 Typischer Tweet einer Tageszeitung mit einem Kommentar der Has- htags enth¨alt...... 49 Abb. 16 pump.io-Post mit Kommentaren von Benutzern auf anderen Instanzen 50 Abb. 17 pump.io zu pump.io, Facebook, Twitter und Googleplus und Kom- mentare aus den Netzwerken zuruck¨ ...... 54 Abb. 18 pump.io Nachricht aus Abbildung 17 im etablierten Sozialen Netzwerk Facebook mit Kommentar im Namen von Benutzer Klaus aus pump.io 54 Abb. 19 Schritt 1 – Synchronisation der Nachrichten in andere Soziale Netzwerke. 56 Abb. 20 Schritt 2 – Synchronisation aller neuen Kommentare in andere Soziale Netzwerke und zuruck¨ ...... 58 Abb. 21 Eine Nachricht kann uber¨ die Brucke¨ an Ziele und Personen in ver- schiedene Netzwerke verschickt werden ...... 59 Abb. 22 Abonnement – Synchronisation aller Neuigkeiten und Nachrichten aus angebundenen etablierten Sozialen Netzwerken...... 63 Abb. 23 Use-Case-Diagramm der Software-Brucke.¨ Das Digramm zeigt die ben¨otigten Anwendungsf¨alle die das Softwaresystem abbildet...... 66

Seite IV VERZEICHNISSE

Abb. 24 Schutz vor Zensur und Blockierung. Eine Nachricht aus Googleplus wird uber¨ die Brucke¨ an etablierte Netzwerke und viele weiter pump.io- Instanzen verteilt...... 70 Abb. 25 Nachricht aus Twitter die durch den repr¨asentativen Benutzer bridge dargestellt wird...... 75 Abb. 26 Eingebettete Googleplus-Nachricht in pump.io ...... 81 Abb. 27 Datenschema der Daten in der Software-Brucke¨ ...... 83 Abb. 28 Einfache Filter um die Feeds der angeschlossenen etablierten Sozialen Netzwerke ab- oder anzuschalten (im Bild ist der Twitter-Stream ist ausgeschaltet)...... 84 Abb. 29 Facebook Schnittstellen-Management fur¨ Entwickler von Facebook-Apps 89 Abb. 30 Durch die Referenz-Implementierung aufbereitete Nachricht aus Face- book (Original siehe Abbildung 31) in pump.io. Der Benutzer hat die Nachricht favorisiert und kommentiert...... 92 Abb. 31 Die Favorisierung und das Kommentar des pump.io-Nutzers wurden aus der Kopie (siehe Abbildung 30) ubernommen¨ ...... 93 Abb. 32 Auslastung des virtuellen Servers ...... 97 Abb. 33 Flussdiagramm fur¨ den Abruf von Nachrichten aus etablierten Sozia- len Netzwerken und Zustellung durch Stellvertreter ...... 114 Abb. 34 Flussdiagramm fur¨ den Abruf von Nachrichten aus etablierten Sozia- len Netzwerken und Zustellung durch einen repr¨asentativen Benutzer . 115 Abb. 35 Login-Oberfl¨ache der pumpbridge. Beliebige pump.io-Accounts k¨onnen sich registrieren ...... 116 Abb. 36 Hauptseite der pumpbridge. Hier k¨onnen die jeweiligen Zugangsdaten fur¨ die etablierten Soziale Netzwerke hinterlegt und gel¨oscht werden . 116 Abb. 37 Autorisierung-Mechanismus fur¨ die Verbindung der pumpbridge-App in Twitter ...... 117

Seite V VERZEICHNISSE

IV Tabellenverzeichnis Tab. 1 Ursachen die zur Nichtnutzung oder L¨oschung des Accounts in einem Sozialen Netzwerks fuhren¨ k¨onnen...... 18 Tab. 2 Fokus und Schwerpunkt einer Auswahl etablierter Sozialer Netzwerke 25 Tab. 3 Vor- und Nachteile bei der Nutzung von Referenzen oder Kopien in der Software-Brucke¨ ...... 80 Tab. 4 Hardware-Spezifikation des eingesetzte Brucken-Servers¨ ...... 96 Tab. 5 Auswertung der Datenmengen der Brucken-Software¨ (pumpbridge) nach 2 monatigem Betrieb ...... 97

Seite VI VERZEICHNISSE

V Listing-Verzeichnis Lst. 1 Webfinger Aufruf eines pump.io-Accounts...... 31 Lst. 2 Ben¨otigte Accountinformationen zu einem pump.io-Benutzer...... 73 Lst. 3 Dienst (Deamon) der in einem bestimmten Zeitintervall die Synchro- nisation fur¨ Benutzer aus dem User-Mapping fur¨ das jeweilge Soziale Netzwerk startet...... 117

Seite VII Kapitel 1 Einfuhrung¨

1 Einfuhrung¨

In diesem Kapitel werden Thematik und Motivation der Arbeit beschrieben. Grundlegende Begrifflichkeiten werden erkl¨art und die Bedeutung, Anwendungsgebiete und Arten von digitalen Sozialen Netzwerken im heutigen Alltag er¨ortert. Weiterhin sind die Ziele sowie der Aufbau der Arbeit beschrieben.

1.1 Einfuhrung¨ in die Thematik

Soziale Netzwerke bilden die Verbindungen menschlicher Interaktion ab. Sie stillen das Grundbedurfnis¨ nach sozialen Beziehungen, Anerkennung und Selbstverwirklichung (vgl. Maslowsche Bedurfnispyramide¨ fur¨ Soziale Netzwerke [Fir14]). Bei Sozialen Netzwerken handelt es sich aus Sicht der Informatik um meist webbasierte Dienste (sogenannte Social Software), in denen Benutzer alleine oder kollaborativ verschiedene angebotene Funktio- nen nutzen k¨onnen. Ein Benutzer in einem Sozialen Netzwerk kann sich h¨aufig mit anderen Benutzer verknupfen¨ bzw. verbinden und stellt sich selbst durch ein eigenes einmaliges Profil dar. K¨onnen die Teilnehmer in dieser Gemeinschaft selbst Inhalte, beispielsweise in Form von Text oder Bild erzeugen, spricht man von Social Media oder dem Begriff Web 2.0. Soziale Netzwerke haben ihren Einzug in unseren Alltag gehalten sind allge- genw¨artig und fester Bestandteil unserer heutigen Gesellschaft. Mehr als drei Viertel (78 Prozent) der Internetnutzer in Deutschland sind in mindestens einem Sozialen Netzwerk angemeldet [Gmb13] und aktiv. In der Altersklasse der 14–29 J¨ahrigen sind sogar uber¨ 90 Prozent in einem oder mehreren Netzwerken registriert. Bei dieser Altersgruppe spricht man von den Digital Natives (dt.: digitale Eingeborene)[WM08]. Die Jugendlichen und jungen Erwachsenen sind mit den technischen Errungenschaften wie Handy, Computer und Internet aufgewachsen. Sie k¨onnen sich ein Leben ohne diese digitalen Medien und Kommunikationswerkzeuge nicht mehr vorstellen. 89 Prozent der Digital Natives sind t¨aglich in ihren Lieblings Netzwerken aktiv [Gmb13]. Die genutzten Plattformen, Funkti- on und Nutzungsmuster der Anwender ¨andern sich fortlaufend. Waren vor einigen Jahren MySpace, wer-kennt-wen und die VZ-Netzwerke in Deutschland am beliebtesten, dominie- ren heute die Plattformen Facebook, Twitter und Googleplus auf den vordersten Pl¨atzen [Sch14]. Die Netzwerke schulerVZ¨ und wer-kennt-wen wurden inzwischen vollst¨andig ab- geschaltet. Was nach der Abschaltung und im Betrieb der Netzwerke mit den sensiblen Daten der Benutzer passiert bleibt oft ungekl¨art. Facebook z¨ahlt mit seinen 1,2 Milliarden Mitgliedern zu dem gr¨oßten Sozialen Netzwerk weltweit[Ver14]. An einem durchschnittli- chen Tag im Juni 2014 haben 829 Millionen Leute Facebook genutzt [HV14]. Die Sozialen Netzwerke werden l¨angst nicht mehr ausschließlich privat genutzt. Viele Firmen haben

Seite 1 Kapitel 1 Einfuhrung¨ das Potenzial und die Vorteile von Social Software zur internen und externen Kommuni- kation und Pr¨asentation erkannt. Die Plattformen Xing und LinkedIn setzen ihren Fokus auf die Business-Welt und fast die H¨alfte der Unternehmen in Deutschland (47 Prozent Bitkom Stand 2012 ) nutzt Social Media im Alltagsgesch¨aft. Weitere 15 Prozent planen die Nutzung bereits konkret [Gmb12]. Es wird zwischen internen (inklusive B2B) und externen Sozialen Netzwerken unterschieden. Die meisten Unternehmen nutzen die Platt- formen extern um Offentlichkeitsarbeit,¨ Marketing und Werbung zu betreiben. Intern werden die Plattformen bevorzugt fur¨ Wissensmanagement und Kommunikation genutzt, um beispielsweise die eigene Produktivit¨at zu erh¨ohen und die Mitarbeiter untereinander besser zu vernetzen. Je nach technischen Aufbau ergeben sich gewisse Typen von Sozialen Netzwerken, in denen sich die verschiedenen Angebote unterteilen lassen [EGH11]. Diese verschiedenen Plattformen platzieren sich selbst in dem Social Software Vulkan (vgl. Ab- bildung1 auf Seite3) nach Karsten Ehms (Dr. phil., Dipl.-Psych.)[Ehm10]. Der Social Software Vulkan gilt fur¨ interne und externe Social Software gleichermaßen.

Wikis dienen zur kollaborativen Erstellung von Inhalten (z.B. Text). Sie platzieren sich im Feld Informations-Management und Zusammenarbeit.

Blogs sind pers¨onliche Journale, die in der Regel von Einzelpersonen gepflegt werden. Diese werden h¨aufig durch einfache Webseiten dargestellt. Die Gemeinschaft entsteht durch die Vernetzung von mehreren Blogs untereinander und beispielsweise Kom- mentarfunktionen fur¨ Leser. Sie bewegen sich im Feld Informations-Management und Vernetzung.

Microblogs sind eine spezielle Form von Blogs. Benutzer k¨onnen kurze, SMS-¨ahnliche Text-Nachrichten ver¨offentlichen. Der bekannteste Microblogging-Dienst ist Twitter, der eine maximale Nachrichtenl¨ange von 140 Zeichen erlaubt. Microblogs plazieren sich ¨ahnlich wie Blogs, haben aber eine st¨arkere Tendenz zur Vernetzung und werden h¨aufig auf einer gemeinsamen Plattform betrieben. Benutzer k¨onnen beispielsweise Nachrichten anderer Nutzer aufgreifen und weiter teilen. Bei Twitter wird diese Funktionalit¨at retweet genannt.

Social-Network-Dienste dienen dem Aufbau und der Pflege von Beziehungsnetzwer- ken. Sie stellen die klassische Form der Sozialen Netzwerke dar. Die Netzwerke generell fur¨ die Interaktion mit anderen Menschen genutzt. Facebook ist der gr¨oßte Social-Network-Dienst weltweit. Einige Plattformen richtigen sich an spezielle Be- nutzergruppen wie Akademiker, Tierliebhaber oder Gesch¨aftsleute. Diese klassi- schen Sozialen Netzwerke platzieren sich im Feld Kommunikation und Vernetzung. Die Dienste gehen st¨arker in Richtung Kommunikation bzw. Beziehungspflege und

Seite 2 Kapitel 1 Einfuhrung¨

weniger in Richtung Zusammenarbeit. Social-Network-Dienste schliessen ebenfalls Online-Communitys und Foren mit ein.

Social Sharing beschreibt eine Gruppe von Plattformen, die den Tausch von digitalen Inhalten, wie Videos oder Bilder in den Vordergrund stellen. Ein Beispiel hierfur¨ ist die Video-Plattform YouTube oder das Foto-Sharing Portal Instagram. Diese Plattformen platzieren sich ¨ahnlich wie Microblogs gehen aber weiter in Richtung Informations-Management. Video-Blogs Vlogs sind ein wichtiger Bestandteil der heutigen Netzkultur.

Erweiterungen beschreiben Elemente, die auf fast allen Arten und Plattformen der So- cial Media zu finden sind. Beispielsweise die Standardisierung Really Simple Syndi- cation (RSS) oder das Verteilen von eingebetteten Nachrichten aus einer Anwendung heraus. Die Erweiterungen schließen den gesamten Software Vulkan ein.

Abbildung 1: Social Software Vulkan. Weiterentwicklung des Dreiecksmodells [Ehm10]

Die konkreten Absichten hinter dem Einsatz von externer Social Media im Unternehmen sind unterschiedlicher Natur, lassen sich aber grob in funf¨ Kategorien unterteilen:

Marketing und Vertrieb Werbung und Offentlichkeitsarbeit¨ (Public-Relations) zum Beispiel durch die bloße Pr¨asenz im Sozialen Netzwerk, einem Gewinnspiel oder dem Angebot und Verkauf von Produkten und Dienstleistungen. Viele Netzwerke bieten Shop-Apps an und verkaufen Werbefl¨ache.

Monitoring Systematische Beobachtung und Analyse des Kunden und Marktes z.B.

Seite 3 Kapitel 1 Einfuhrung¨

durch einen ¨offentlichen Diskussionsthreads: Wie ist die aktuelle Nachfrage? – Wie ist das aktuelle Stimmungsbild? – Was will der Kunde?

Kundenservice Der Auftritt im Sozialen Netzwerk als direkter moderner Ansprechpart- ner fur¨ den Endkunden – mit zus¨atzlicher Offentlichkeitswirkung¨ (Kundenservice nah am Kunden).

Human Ressource und Employer Branding Das Unternehmensimage verbessern, attraktiv und modern wirken und Pr¨asenz zeigen. In dem Netzwerk neues Personal akquirieren oder bestehende Mitarbeiter an das Unternehmen binden. Das Unter- nehmen als Marke verkaufen.

Bei der externen Kommunikation wird in der Regel breit gestreut und alle relevanten Kan¨ale der etablierten Sozialen Netzwerke befullt¨ [Kra13]. Unternehmen setzen fur¨ das Managen der vielen Netzwerke h¨aufig spezielle Software ein. Ein Beispiel hierfur¨ ist die propriet¨are Anwendung HootSuite, mit der sich mehrere Soziale Netzwerke gleichzeitig steuern lassen. HootSuite bezeichnet sich selbst als Social Media Dashboard, dass alle wichtigen Informationen zusammenfasst, verarbeitet und auf Unternehmen ausgerichtete Monitoring-Funktion bereitstellt. HootSuite bietet als sogenannter Multi- bzw. Crosspos- ter die M¨oglichkeit eine Nachricht automatisch in mehrere angeschlossene Soziale Netzwer- ke zu verteilen. Software dieser Art, Nachrichten unidirektional zu versenden, gibt es auch fur¨ den privaten Sektor. Vereinzelt findet sich auch Software, die ¨offentliche Nachrichten- str¨ome aus mehreren Sozialen Netzwerken zusammenfasst aber keine direkte weitere In- teraktion zul¨asst. Ein Soziales Netzwerk, dass mehrere vorhandene Netzwerke vollst¨andig verbindet und eine bidirektionale Kommunikation erm¨oglicht wurde bei der Recherche die- ser Arbeit nicht gefunden. Fur¨ interne Kommunikation innerhalb der Unternehmen wird in der Regel angepasste Social Software bzw. sogenannte Social-Enterprise-L¨osungen ein- gesetzt, die in der eigenen Infrastruktur oder Cloud betrieben wird. Sie bilden die internen Sozialen Netzwerke fur¨ Unternehmen ab [Wyl14]. Die individuellen Softwarel¨osungen ba- sieren oftmals auf Produkten wie Chatter von Salesforce, Jive oder Yammer, dass seit einiger Zeit zu Microsoft geh¨ort. Das firmeneigene Soziale Netzwerk ASN (Allianz So- cial Network) der Allianz Gruppe wurde beispielsweise zusammen mit der Firma Jive entwickelt. Der Einsatz von internen Sozialen Netzwerken erlaubt den Unternehmen, die Kontrolle uber¨ die ausgetauschten Daten und registrierten Mitglieder zu behalten und dennoch von dem Vorteil der Vernetzung zu profitieren. Sensible Informationen oder gar interne Dokumente auf Facebook, Xing und Co sind fur¨ so gut wie jedes Unternehmen ein Alptraum [Kra13]. Große etablierten Soziale Netzwerke wie Facebook und Google sind fur¨ den Benutzer kostenfrei. Sie sammeln, analysieren und verkaufen dafur¨ aber die Daten ihrer Benutzer um beispielsweise gezielt Werbung anzuzeigen. Unklar ist, welche Daten

Seite 4 Kapitel 1 Einfuhrung¨ genau dauerhaft gespeichert, ausgewertet und weitergegeben werden. Eine vollst¨andige L¨oschung der eigenen Daten ist meistens nicht m¨oglich. Facebook l¨oscht zum Beispiel die vom Benutzer entfernten Inhalte nicht tats¨achlich aus der eigenen Datenbanken [Sch11].

Nichtsdestotrotz bieten die etablierten Netzwerke speziell auf Firmen zugeschnittene An- gebote wie z.B. Google Business an, die ein Rundum-sorglos-Paket versprechen, dass auf externen Servern in der Cloud betrieben wird. Allzu oft kommt es vor, dass Mitarbeiter oder Abteilungen eine gewisse Eigendynamik entwickeln und neben der h¨aufig veralteten oder langsamen Infrastruktur des Unternehmens ¨offentlich zug¨angliche Kollaborations- werkzeuge wie zum Beispiel Dropbox oder Google Drive zur elektronischen Datenverar- beitung und Austausch nutzen. Dieser Betrieb von Software neben der eigentlichen Infra- struktur kann einen Kundigungsgrund¨ darstellen, da unter Umst¨anden gegen Unterneh- mensrecht verstoßen wird. Im schlimmsten Fall macht sich ein Mitarbeiter sogar strafbar, da das Datenschutzgesetz verletzt wird und sensible Informationen ungesichert und un- kontrolliert verteilt werden. Unternehmen die oben genannte propriet¨are Social Software einsetzen, haben allerdings ebenfalls mit Problemen zu k¨ampfen. Durch die Einfuhrung¨ propriet¨arer Software geraten die Unternehmen oft in starke Abh¨angigkeit zu einem be- stimmten Hersteller und deren Produkte. Sollen Anderungen¨ oder Anpassungen an der Software vorgenommen werden, mussen¨ diese durch den Hersteller, im Normalfall kos- tenpflichtig, implementiert oder Zusatzmodule eingekauft werden. Treten Fehler in dem Produkt auf, kann immer nur bedingt reagiert, eingegriffen und korrigiert werden. Der Zugriff auf die eigentlichen Kern-Daten des Systems sind ebenfalls h¨aufig, dank geschlos- sener Datei- und Datenformate, beschr¨ankt und ein vollst¨andiger Export ist nur selten m¨oglich. Ein ganz anderes Problem der eigenen Datensicherheit: Bei einem Großteil der Enterprise-Social Software Hersteller wie z.B. Jive, Microsoft, Salesforce, VMWare usw. handelt es sich um US-Amerikanische Unternehmen. Durch die globale Uberwachungs-¨ und Spionageaff¨are der NSA (National Security Agency) und den Enthullungen¨ von Ed- ward Snowden, ist der Offentlichkeit¨ bewusst, dass die Vereinigten Staaten im großen Rah- men weltweit Telekommunikationsdaten, Software und das Internet uberwachen¨ [JH14]. Firmen wie Apple, AOL, Twitter, LinkedIn, Facebook, Microsoft und Google wehren sich mit einer Kampagne und in einem offen Brief an der US-Regierung gegen die Spionage- programme internationaler Geheimdienste [HV13]. Die Firmen wollen genaue Angaben ver¨offentlichen durfen,¨ wie oft und warum Regierungen die Herausgabe von Nutzerin- formationen verlangen. Diese eigene Aussage der Firmen zeigt, dass die US-Unternehmen gezwungen werden, sensible Informationen ohne konkreten Verdachtsmoment herauszuge- ben. In einigen F¨allen sind sogar Hinterturen¨ in Hardware-Produkten eingebaut worden, die direkten Zugriff auf Infrastruktur-Systeme erlauben [Sny14].

Seite 5 Kapitel 1 Einfuhrung¨

In der Vergangenheit sind zentral organisierte Soziale Netzwerke immer wieder Opfer von Angriffen, gezielter Zensur oder vollst¨andiger Sperrungen durch Regierungen und Hacker geworden. Im M¨arz 2014 wurde zum Beispiel in der Turkei¨ der Zugriff auf Twitter vollst¨andig gesperrt [Kaz14]. China blockiert schon seit Jahren mit dem sogenannten Golden Shield Project den Zugriff auf Facebook, Googleplus und Co [pin11]. Das Problem der zentralen Architektur ist nicht nur, dass einzelne Betreiber Zugriff auf alle Daten im Netzwerk haben, sondern auch, dass der Zugriff von außen technisch relativ einfach unterbunden werden kann. Durch Sperrung eines Fully Qualified Domain Name (FQDN) wie www.twitter.com oder einer bzw. einiger weniger IP-Adressen kann die Funktionalit¨at des gesamten Netzen beeintr¨achtigt werden. Technisch unversierte k¨onnen das Netzwerk dann uberhaupt¨ nicht mehr nutzen.

Mittlerweile reagieren einige Benutzer skeptisch und suchen Alternativen. Nachdem Fa- cebook den Instant-Messaging-Dienst Whatsapp im Februar 2014 kaufte [Ver14], fuhlten¨ sich viele Menschen animiert, zu wechseln und der Monopolisierung des als Datenkrake verrufenen Herstellers zu entfliehen. Eine der Alternativen zu zentralen Sozialen Netzwer- ken stellen die freien dezentralen Sozialen Netzwerke dar. Sie ben¨otigen keinen zentralen Server, auf dem alle Nutzerdaten gespeichert werden und bestehen aus einem Verbund von unabh¨angig verwalteten Instanzen [Hab13], die jeweils nur die fur¨ sich ben¨otigten Informationen und Berechtigungen vorhalten. Die einzelnen Server werden h¨aufig von den Nutzern selbst bereitgestellt (gehostet) und administriert. Jeder Knoten h¨alt lokale Benutzerinformationen bereit und gibt nur bestimmte Daten zu anderen Servern nach außen weiter. Die gespeicherten Daten eines jeweiligen Knoten liegen in der Obhut des Administrators. Werden Ressourcen von einem Knoten gel¨oscht, sind diese fur¨ andere Nutzer und Betreiber im Netzwerk nicht mehr erreichbar und werden auch lokal nicht weiter vorgehalten. Das verhindert naturlich¨ nicht, dass ¨offentlich geteilte Daten die den Server verlassen haben, wie zum Beispiel ein Bild, von anderen Benutzern manuell ko- piert werden (nach dem Motto: Einmal im Internet – immer im Internet). Falls aber beispielsweise zwei Benutzer eines Knotens dem Administrator vertrauen, k¨onnen diese untereinander sicher, getrennt von anderen, kommunizieren. Keine Informationen werden nach außen getragen und zentral gesammelt. Fur¨ die Kommunikation zwischen Servern werden offene Schnittstellen und Standards verwendet, mit denen sich alle Funktionen des Netzwerkes steuern und abbilden lassen. Diese Standards sollen nicht nur die Kom- munikation innerhalb eines dezentralen Sozialen Netzwerkes erm¨oglichen, sondern einen grenzenlosen Austausch mit anderen Systemen und Clients erlauben [Hab13]. Es existie- ren bereits viele dezentrale Soziale Netzwerke, die fast ausschliesslich auf Freier Software basieren [WF14] und eine solide Funktionsvielfalt und interessante Sonderfunktionen wie z.B. Ende-zu-Ende-Verschlusselung¨ liefern. Selten schaffen es die Alternativen aber in

Seite 6 Kapitel 1 Einfuhrung¨

Sachen User Experience und Masse an Funktionalit¨at mit den großen etablierten Sozia- len Netzwerken mitzuhalten. Durch die vollst¨andige Quelloffenheit und die M¨oglichkeit die Software zu ver¨andern, bieten die Freie Software L¨osungen aber ein H¨ochstmaß an Transparenz und Anpassungsm¨oglichkeit. Die Alternativen versuchen gezielt Probleme der Interoperabilit¨at, Sicherheit und Offenheit gegenuber¨ externen Netzwerken zu l¨osen. Alle alternativen dezentralen Sozialen Netzwerke erreichen bei ihren Bemuhungen¨ aller- dings nicht die sogenannte kritische Masse an Nutzern und leiden unter dem direkten Netzwerkeffekt. Katarina Stanoevska-Slabeva [SS08] schreibt zu dem Netzwerkeffekt:

Insgesamt existieren in Web 2.0 Plattformen starke Lock-in und Netzwerkef- ” fekte. Je mehr der Benutzer Inhalte in die Community einbringt desto gr¨oßer ist die Hurde¨ zu anderen Communities zu wechseln. Je mehr Teilnehmer ei- ne Community aufweist, desto interessanter wird der Gesamtinhalt und desto relevanter wird die Konzentration von Inhalten. Es entsteht eine selbstorgani- sierende Spirale, die mit jedem Eintrag zu einem neuen Gesamtzustand fuhrt,¨ die verfugbaren¨ Input zu Meinungsmehrheiten konsolidiert und die Wirkung der Community verst¨arkt. Diese Eigenschaften fuhren¨ zudem dazu, dass sich die Benutzer und die Inhalte schnell vernetzen und verbreiten.“ [SS08]

Zusammengefasst fugt¨ jeder weitere Nutzer einem Sozialen Netzwerk einen zus¨atzlichen Wert hinzu, von dem alle anderen profitieren – ein Soziales Netzwerk mit nur einem Benutzer macht wenig bis keinen Sinn. Je mehr Nutzer in einem Netzwerk aktiv sind und neue Inhalte oder Aktivit¨aten produzieren, desto attraktiver wird das Angebot fur¨ neue Mitglieder (vgl. Abbildung2 auf Seite7).

Abbildung 2: Der Netzwerkeffekt

Sind zum Beispiel Familie, Freunde und Bekannte in einem Netzwerk verankert, ist an- zunehmen, dass der vollst¨andige Wechsel zu einer anderen Plattform schwer f¨allt. Meist finden sich in den alternativen Plattformen Hacker, Netzaktivisten und Benutzer die dem

Seite 7 Kapitel 1 Einfuhrung¨ allgemeinen etablierten Sozialen Netzwerken kritisch gegenuberstehen¨ und nur wenige sogenannte Casual User. Der Freundes- oder Kollegenkreis und endlose Inhalte frem- der Benutzer, die zu der regelm¨aßigen Nutzung eines bestimmten Netzwerkes animieren, k¨onnen auf Grund der insgesamt geringen Nutzerzahlen in den alternativen Netzwerken nur selten bis gar nicht erreicht werden. Die angenommenen Ursachen, die den durch- schnittlichen Benutzer abhalten alternative dezentrale Soziale Netzwerke zu nutzen, sind ganz unterschiedlicher Natur und versucht worden im Folgenden zusammengetragen:

• Die alternativen Sozialen Netzwerke sind unbekannt und nicht weit verbreitet. An- bietern der Alternativen stehen in der Regel keine besonders großen Werbemittel zur Verfugung.¨ Viele Benutzer kennen die Alternativen schlichtweg nicht. In der dezentralen Struktur gibt h¨aufig keine zentrale Anlaufstelle fur¨ neue Mitglieder.

• Die Alternativen bieten nicht den selben Umfang an Funktionalit¨at. Drittanbieter entwickeln ihre Software (Apps) fur¨ etablierte Soziale Netzwerke, da sie sich dort den gr¨oßten Absatz erhoffen.

• Die Netzwerke weisen h¨aufig noch gewisse technische M¨angel auf. Einiges funktio- niert Out-of-the-Box nicht. Hinter den einzelnen Projekten stehen Einzelpersonen oder kleinere Entwicklergruppen und Communitys – keine milliardenschweren Kon- zerne wie Google und Facebook.

• Der Betrieb eines eigenen Servers in einem dezentralen Sozialen Netzwerk ist mit Aufwand und Kosten verbunden und setzt ein gewisses administratives Know-How voraus. Viele Anwender kennen niemanden der einen Server bereitstellt oder verste- hen das Konzept hinter der dezentralen Architektur nicht.

• Bekannte, Freunde, Kollegen und der Sportverein (das komplette Soziale Umfeld ei- ner Person) nutzen als Beispiel bereits eines der etablierten Sozialen Netzwerke mit zentraler Architektur. Der Hauptgrund fur¨ die Nutzung von Sozialen Netzwerken ist die Kommunikation mit einer bestimmten Personengruppe bzw. einem Personen- kreis. Kann diese Gruppe durch das Netzwerk nicht erreicht werden, ist die Nutzung sinnlos.

• Angebote die nicht direkt etwas mit dem Sozialen Netzwerk zu tun haben, setzen eine Anmeldung voraus. Ein Beispiel sind die h¨aufig genutzten Facebook- und Google- Logins fur¨ Webseiten und Anwendungen Dritter.

• Durch die geringen Nutzerzahlen werden insgesamt nur wenig neue Inhalte produ- ziert. Das st¨obern nach Neuigkeiten und Personen ist in kleinen Netzwerken be- schr¨ankt.

Seite 8 Kapitel 1 Einfuhrung¨

Es gibt bereits viele gute Ans¨atze fur¨ Alternativen. Die angenommen Ursachen zeigen jedoch, dass es keine L¨osung ist, weitere neue autarke Soziale Netzwerke zu entwickeln, anzubieten und zu betreiben. Solange die kritische Masse an Nutzern nicht erreicht wird, bleiben die alternativen Angebote fur¨ den durchschnittlichen Benutzer und Otto Normalverbraucher unattraktiv – auch wenn dafur¨ die Datensicherheit und der Daten- schutz hinten anstehen muss. Um attraktiv zu werden mussen¨ die Vorteile der alternati- ven Plattform uberwiegen¨ und eine echte Koexistenz aller Netze erm¨oglicht werden. Eine M¨oglichkeit dieses Ziel zu erreichen, ist die Anbindung der etablierten Kan¨ale an das dezentrale Soziale Netzwerke. Dieser Ansatz wurden¨ den bereits erw¨ahnten Netzwerkef- fekt aushebeln. Durch die Verknupfung¨ k¨onnten in den alternativen dezentralen Sozialen Netzwerken pl¨otzlich sogar die (kritischen) Massen mehrerer, in sich geschlossener Syste- me, erreicht werden. Etablierte Soziale Netzwerke bilden zur Zeit ihre eigenen Netze ab (Netze-im-Netz) und verhalten sich nach außen historisch gesehen anders als beispielswei- se die E-Mail, die Kommunikation uber¨ Provider- und Anbietergrenzen hinweg erlaubt und sich als erfolgreiches als Kommunikationsmedium durchgesetzt hat. Es ist allerdings zu vermuten, dass die Anbieter der Sozialen Netzwerke im Kampf um jeden Nutzer auf der eigenen Plattform kein Interesse daran haben, alternative konsolidierte Nachrichtenstr¨ome und Feeds anderer Anbieter zu unterstutzen.¨

1.2 Motivation und Ziele

Laut der Bitkom-Studie Soziale Netzwerke 2013 ist die Motivation zur Nutzung Sozialer Netzwerke in erster Linie auf die Vernetzung mit Freunden ausgerichtet [Gmb13]. Viele Anwender sind schon jetzt in mehreren verschieden Sozialen Netzwerken angemeldet und aktiv. Ein Beispiel: Die Familie nutzt Facebook, der Freundeskreis Googleplus und die Kollegen Twitter um Neuigkeiten auszutauschen. Hinzu kommen noch die internen Sozia- len Netzwerke, die innerhalb der Unternehmen eingesetzt werden. Um alle Kommunika- tionspartner zu erreichen, ist der Einsatz einer Vielzahl von Clients und Webseiten n¨otig. Zus¨atzlich gibt es fur¨ verschiedenen Plattformen wie z.B. Mobil und Desktop wiederum unterschiedliche Clients. Dabei kann es vorkommen, dass der Uberblick¨ verloren geht oder Informationen schlichtweg ubersehen¨ werden; ein ¨ahnliches Ph¨anomen wie bei E-Mails, die zu sp¨at gelesen oder versehentlich als Spam markiert werden. Eine optimale L¨osung zur Steuerung aller Netzwerke und Personenkreise wurde¨ einen Synthese-Client vorausset- zen, der alle relevanten Informationen zusammentr¨agt und standardisiert in einem Format ausgibt. Im Bereich der Informatik spricht man von einem Aggregator, der digitale Me- dieninhalte zusammenfasst. Hinter dieser Arbeit steckt die Motivation ein Konzept zu entwickeln, dass theoretisch eine bidirektionale Kommunikation zwischen einem dezentra-

Seite 9 Kapitel 1 Einfuhrung¨ len Sozialen Netzwerk und mehreren etablierten Sozialen Netzwerken erm¨oglicht. Durch eine rudiment¨are Implementierung der Funktion soll der Machbarkeitsnachweis erbracht und aktuelle Probleme aufgezeigt werden. Im Vorfeld zu dieser Arbeit ist im Rahmen ei- nes Projekts die Social Software pump.io in einem Unternehmen eingefuhrt¨ worden. Das Vorprojekt beschreibt die Inbetriebnahme und Erweiterung des unter eigener Kontrol- le stehenden, freien und verteilten Sozialen Netzwerks als Alternative zu den bekannten ¨offentlichen Plattformen (auch gegenuber¨ anderen freien L¨osungen). Das Netzwerk wird dazu genutzt, automatisiert Informationsstr¨ome fur¨ Neuigkeiten und Bekanntmachungen auf Webseiten zu verteilen und um Social-Media-Pr¨asenz zu zeigen. Daruber¨ hinaus wur- de mit dem Sozialen Netzwerk versucht, den allgemeinen Fluss von Informationen inner- halb des Unternehmens zu verbessern. Bereits interessierte und potenzielle neue Kunden k¨onnen uber¨ die eingefuhrte¨ Social Software aktueller informiert werden als vorher. Viel spricht fur¨ den Einsatz dezentral organisierter Freie Software Netzwerke, dennoch leiden die Produkte unter der im Kapitel Einfuhrung¨ in die Thematik erw¨ahnten Probleme.

Die Motivation und Ziele der Arbeiten sind in den folgenden Punkten und Schlagworten festgelegt:

Verbinden: Eine Verbindung zwischen freien dezentralen und etablierten Sozialen Netz- werken schaffen. Den Menschen oder den Kunden auf der Plattform erreichen auf der er sich bereits befindet und wohl fuhlt.¨

Verbessern: Die Verbesserung der User Experience im Umgang und Nutzung alternati- ver sozialer Netzwerke. Neue sinnvolle Funktionen.

Bereitstellen: Ein gemeinsames Meta-Netzwerke aus der Zusammenfuhrung¨ verschie- dener Sozialer Netzwerke schaffen (vgl. Abbildung3 auf Seite 12). Ein Verbinder und Multiplexer zwischen verschiedenen Netzwerken anbieten. Das weiter teilen von Nachrichten schafft Verbindungen von Nutzern uber¨ die Grenzen der in sich ge- schlossenen Netzwerke hinweg. Es gilt zu untersuchen, ob die M¨oglichkeit besteht, Menschen in unterschiedlichen Sozialen Netzwerk zu verbinden.

Nachhaltigkeit: Die M¨oglichkeit, ein eigenes Synthese-Netzwerk inklusive eines einzigen Clients zu betreiben. Der Client bleibt immer der gleiche, selbst wenn angebunde- ne Dienste ruckl¨ ¨aufige Nutzerzahlen vorweisen, nicht mehr genutzt, abgeschaltet oder blockiert werden. Diese Nachhaltigkeit bietet die M¨oglichkeit einer dauerhaf- ten Nutzung einer bekannten Umgebung. Clients der etablierten Anbieter werden h¨aufig ge¨andert und es fallen Funktion weg.

Vorteile: Die Vorteile im Hinblick auf Datenschutz, Privatsph¨are, Sicherheit, Offenheit, Wartbarkeit und Nachhaltigkeit herausstellen und alternative Soziale Netzwerke fur¨

Seite 10 Kapitel 1 Einfuhrung¨

den durchschnittlichen Anwender attraktiver und zug¨anglicher machen. Fur¨ den Benutzer wichtig: Weiterhin die Facebook-Freunde erreichen.

Probleme: Probleme bei den Schnittstellen (Application Programming Interface (API)) und Nutzungsbedingungen (Terms of Service (TOS)) etablierter Sozialer Netzwerke aufzeigen.

Filtern: Informationen filtern. Einen gemeinsamen Stream zusammenfassen und unwich- tige oder nicht gewunschte¨ Nachrichten filtern. Die Ubersicht¨ bei der Nutzung vieler verschiedener Sozialer Netzwerke verbessern und wichtige Informationen hervorhe- ben und sortieren.

Erkenntnis: Erkenntnisse uber¨ Ressourcenverbrauch, Datenmengen und Nutzerverhal- ten gewinnen und auswerten. Es ist unklar, ob Probleme zentraler Server-Architektur (Konzept, Skalierbarkeit, Komplexit¨at, Sicherheit, Privatsph¨are, Sichtbarkeiten, Zen- sur) durch dezentrale Server-Architektur gel¨ost werden und vor allem ob und welche neuen Probleme auftreten. Da sich Zielgruppen in Sozialen Netzwerken unterschei- den, ist es fur¨ den Anwender eines synthetisierten Netzwerks wichtig zu wissen und zu sehen, wer wo Informationen wahrnimmt.

Ziel der Arbeit ist es nicht, andere bereits etablierte Plattformen wie Facebook oder Twit- ter zu verdr¨angen, untergraben oder g¨anzlich abzul¨osen. Alternativen gibt es viele – die Zersplitterung der einzelnen Nutzer auf viele verschiedene Plattformen ist das eigentliche Problem von Sozialen Netzwerken. Es gilt zu untersuchen, ob es m¨oglich ist, ein Netzwerk mit Freier Software aufzubauen, das externe Soziale Netzwerke miteinander verbindet und Nachrichten uber¨ deren Grenzen hinweg austauscht. Die sp¨atere Konzeption soll zeigen, welche konkreten Inhalte aus externen Netzwerken aufbereitet und gespeichert werden mussen,¨ um eine m¨oglichst hohe Transparenz herzustellen und keine gelieferte Informatio- nen zu verf¨alschen oder im Kontext unbrauchbar zu machen. In der Vision spielt es keine Rolle, aus welchem Netzwerk oder Quelle eine Nachricht ursprunglich¨ stammt. Nur der Zusammenhang und digitale Inhalt sind fur¨ den Empf¨anger relevant – und auch nur die- ser wird eigentlich wahrgenommen. Naturlich¨ lassen sich nicht alle Funktionen innerhalb aller Netzwerke vereinheitlichen, sodass die Vielfalt von Social Media weiter gerechtfertigt bleibt. Die Menschen k¨onnen fur¨ sich selbst entscheiden, welche Plattform sie nutzen und unterstutzen¨ wollen.

Seite 11 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Abbildung 3: Ziel: Der Pump.io-Client (mitte) als Multiplexer zwischen Etablierten So- zialen Netzwerken und Empf¨anger eines synthetisierten Feeds

1.3 Aufbau der Arbeit

Der Aufbau dieser Arbeit gliedert sich in mehrere Kapitel, die im Folgenden vorgestellt werden. In Kapitel 2 der Arbeit wird der aktuelle Stand von Social Media untersucht, etablierte Soziale Netzwerke vorgestellt und das dezentrale Soziale Netzwerk pump.io beschrieben und die gemeinsamen Grundfunktionalit¨aten herausgearbeitet. Der Schwer- punkt der Arbeit liegt in Kapitel 3. Dort wird die Konzeption einer Software-Brucke¨ zum bidirektionalen Datenaustausch zwischen etablierten Sozialen Netzwerken und pump.io unter Berucksichtigung¨ einer dazu ben¨otigten gemeinsamen Sprache und Datenschemas beschrieben. In Kapitel 4 wird der praktische Machbarkeitsnachweis der in Kapitel 3 theoretisch ausgearbeiteten Annahme umgesetzt und die durchgefuhrte¨ Sammlung von Informationen dargestellt. Weiter werden in diesem Kapitel die gesammelten Ergebnisse einer Bewertung unterzogen. Zum Schluss wird ein Fazit uber¨ die Arbeit gezogen und ein Ausblick fur¨ die Zukunft gestellt.

2 Stand der Wissenschaft (State of Social Media)

In diesem Kapitel wird der Stand der Wissenschaft im Hinblick auf Soziale Netzwerke erl¨autert. Die unterschiedlichen Typen der Netzwerke werden beschrieben und typische Funktionen innerhalb der etablierten Sozialen Netzwerke dargestellt. Weiterhin wird das dezentrale Soziale Netzwerk pump.io, auf dem die sp¨atere Konzeption aufbaut, vorgestellt

Seite 12 Kapitel 2 Stand der Wissenschaft (State of Social Media) und interne Abl¨aufe geschildert und veranschaulicht. In dem letzten Teil des Kapitels werden rechtliche Fragen gekl¨art und die Probleme beim Kopieren von Inhalten anderer Nutzer uber¨ Netzwerkgrenzen hinweg untersucht.

2.1 Typen Sozialer Netzwerke

Ellison, Nicole B. et al. definieren Social Network Sites als:

web-based services that allow individuals to (1) construct a public or semi- ” public profile within a bounded system, (2) articulate a list of other users with whom they share a connection, and (3) view and traverse their list of connecti- ons and those made by others within the system. The nature and nomenclature of these connections may vary from site to site.“ [E+07]

Interessant ist die Aussage, dass es sich um begrenzte (engl. bounded), in sich geschlossene Systeme handelt. Viele Anbieter etablierter Sozialer Netzwerke sehen in den Nutzungsbe- dingungen nicht vor, dass Nutzer parallel neue zusammengefasste Streams aufbauen und beschr¨anken die eigenen Schnittstellen stark. Die durch Werbung finanzierten Anbieter haben kein Interesse daran, dass Nutzer wom¨oglich gefilterte (von Werbung befreite) In- halte auf externen Plattformen konsumieren. Daruber¨ hinaus wird durch Nutzung von Automatismen (wie zum Beispiel durch einen Web-Crawler oder Webseiten-Roboter) die Auswertungen und Analysen welche durch den Anbieter durchgefuhrt¨ werden, verf¨alscht.

Paul Baran (Senior Memeber der IEEE) unterschied schon 1964 drei verschiedene Arten von Netzwerken [Bar64] vgl. Abbildung4 auf Seite 14.

2.1.1 Zentrale Netzwerke

In einem zentralen Netzwerk ist jeder Knoten mit genau einem zentralen Knoten verbun- den. Die ¨außeren Knoten stellen die einzelnen Benutzer bzw. Benutzerprofile dar. Bei dem zentralen Knoten, mit dem alle anderen Knoten verbunden sind, handelt es sich um den zentralen Server. Jegliche Kommunikation zwischen ¨außeren Knoten findet uber¨ diesen zentralen Vermittler statt. Der Server h¨alt alle Informationen und Daten der Benutzer und Verbindungen vor. F¨allt der zentrale Knoten aus, kann kein Knoten mehr mit ei- nem anderen Knoten kommunizieren (vgl. Abbildung4 (a)). Zu den zentralen Sozialen Netzwerken z¨ahlen alle großen kommerziellen Anbieter und die Top 20 der popul¨arsten Sozialen Netzwerke in Deutschland [Sch14]. Technisch gesehen werden diese Netzwerke in der Regel ebenfalls dezentral aufgebaut. Es gibt nicht nur einen einzigen Facebook-Server

Seite 13 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Abbildung 4: (a) Zentrale (b) Dezentrale und (c) Verteilte Peer to Peer (P2P) Netzwerke [Bar64] in Kalifornien, sondern viele miteinander vernetzte, die uber¨ den ganzen Globus verteilt sind. Dennoch pr¨asentiert sich das Netzwerk nach außen wie ein zentrales Netzwerk. Es laufen alle Daten bei einem Anbieter zusammen und der Dienst ist nur unter einigen wenigen Domain-Namen wie z.B. facebook.com und facebook.de erreichbar.

2.1.2 Dezentrale Netzwerke

Ein dezentrales Netzwerk besteht aus vielen einzelnen untereinander verbundenen zen- tralen Netzwerken (vgl. Abbildung4 (b)). Die Struktur hat den Vorteil, dass die Daten eines End-Knotenpunktes jederzeit von einem einzelnen zentralen Knoten bereitgestellt werden kann, auch wenn der End-Knotenpunkt selbst offline ist. In dezentralen Netzwer- ken k¨onnen alle Knoten untereinander kommunizieren. Es gibt aber keinen allwissenden Knoten, der alle Informationen aus dem Netzwerk vorh¨alt. Es k¨onnen Knoten abgeschal- tet und hinzugefugt¨ werden, ohne den Informationsfluss des gesamten Netzwerkes zu beeintr¨achtigen. Bei klassischer E-Mail handelt es sich ebenfalls um eine Art dezentra- les Netz. Ein Benutzer mit einem @web.de-Konto kann mit einem Benutzer auf einem @gmail.com-Konto kommunizieren. Selbst wenn alle @web.de-Server nicht mehr erreich- bar sind, kann ein @gmail.com-Konto weiterhin mit einem @gmx.de-Konto interagieren.

Seite 14 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Sollten alle anderen Mailserver bzw. E-Mail-Anbieter ausfallen oder abgeschaltet werden, k¨onnen dennoch alle Benutzer eines einzelnen E-Mail-Providers intern untereinander Da- ten austauschen. Durch die einzelnen zentralen Strukturen kann ein Benutzer, selbst wenn er offline ist, E-Mails anderer Benutzer empfangen. Fur¨ den einzelnen Nutzer besteht bei einem dezentralen Netzwerk weiter die klassische Client-Server-Architektur. Um Daten schnell und dauerhaft vorzuhalten, auch wenn ein Knoten kurzzeitig ausf¨allt oder nicht erreichbar ist, werden bestimmte Daten h¨aufig in einem lokalen Cache vorgehalten und beispielsweise sp¨ater zugestellt.

2.1.3 Vollst¨andig verteilte Netzwerke

In einem vollst¨andig verteilten Netzwerk sind keine zentralen Knoten vorhanden. Jeder einzelne Knoten ist Server und Client gleichzeitig. Die Knoten k¨onnen also gleichzeitig Dienste anbieten und konsumieren. Sie sind untereinander v¨ollig gleichberechtigt. Ist ein Knoten nicht direkt mit einem anderen verbunden, kann uber¨ andere kommuniziert wer- den (vgl. Abbildung4 (c)). Wenn ein Knoten ausf ¨allt (egal welcher), k¨onnen alle anderen weiterhin untereinander kommunizieren. Jeder Knoten h¨alt eigenen Daten vor oder kann andere nach Daten fragen. Ein vollst¨andiges verteiltes Netzwerk unzug¨anglich zu machen ist theoretisch unm¨oglich, es sei denn komplette Protokolle oder Ports werden blockiert. Ein Beispiel fur¨ verteilte Netzwerke sind zum Beispiel die Kryptow¨ahrung Bitcoin oder das soziale Netzwerk Twister (twister.net.co). Ist ein Knoten offline, k¨onnen ande- re Knoten keine Informationen mehr von ihm abrufen, was einen großen Nachteil der Architektur darstellt. Dies k¨onnte sich dahin gehend ¨außern, dass eine Profilseite oder Nachricht eines Nutzer nur dann zur Verfugung¨ steht, wenn der Verfasser online und am Netzwerk angemeldet ist. Um dieses Problem zu l¨osen nutzen Plattformen wie Bitcoin und Twister verteilte Hashtabellen um Informationen und Daten zu hashen und auf alle Knoten (verschlusselt)¨ zu verteilen. Der Abruf der Daten kann allerdings wesentlich mehr Zeit in Anspruch nehmen als bei einer klassischen Client-Server-Architektur.

2.2 Etablierte Soziale Netzwerke

Der Duden gibt dem Wort etablieren die Bedeutung:

einen sicheren Platz innerhalb einer Ordnung oder Gesellschaft gewinnen, ” festen Bestand erlangen, sich festsetzen und breitmachen“ [Ins14]

Die Aussage einen sicheren Platz innerhalb einer Ordnung oder Gesellschaft gewinnen“ ” beschreibt die Positionierung der etablieren Sozialen Netzwerke gut. Diesen Platz sichern

Seite 15 Kapitel 2 Stand der Wissenschaft (State of Social Media) sich die Netzwerke, die weit uber¨ 1 Millionen aktive Nutzer (engl. active users) ver- zeichnen. Im Vergleich dazu sind die Zahlen der Nutzer in alternativen Sozialen Netzen, selbst inaktive mit eingeschlossen, minimal. Die Digramme in Abbildung5 auf Seite 17 und Abbildung6 auf Seite 17 zeigen aktuelle Zahlen im Uberblick.¨ Leider sind h¨aufig konkrete Nutzerzahlen nicht in Erfahrung zu bringen, da sie von den Unternehmen un- ter Verschluss gehalten werden. Daher variieren die Zahlen in verschiedenen Statistiken stark. In verteilten Netzwerken sind die genauen Nutzerzahlen ebenfalls schwierig zu er- mitteln, da nicht zwangsl¨aufig jeder Server mit jedem Server verbunden ist und keine zentrale Erfassung stattfindet. Die in dem Diagramm aufgefuhrten¨ Netzwerke spiegeln einen kleinen Teil der etablierten Sozialen Netzwerke wieder. Zus¨atzlich zu den weltweit etablierten Netzwerken kommen lokale, regionale und landesspezifische Soziale Netzwerke hinzu. Das Business-Netzwerk Xing hat seine Zielgruppe beispielsweise fast ausschließ- lich in den D-A-CH-L¨andern. Alle der im Diagramm aufgefuhrten¨ etablierten Sozialen Netzwerke basieren auf propriet¨are Software und fast alle etablierten Netzwerke verdie- nen entweder durch Werbung, Verkauf von personenbezogenen Daten oder das Anbieten von Premium-Diensten ihr Geld. Facebook bezieht bei den etablierten Sozialen Netzwer- ken quasi eine Monopolstellung. Es werden zahlreiche Dienste innerhalb von Facebook angeboten. Daruber¨ hinaus geh¨oren die anderen großen etablierten Sozialen Netzwerke Instagram und WhatsApp ebenfalls zu Facebook. Durch die Einbindung vieler Dienste und Anwendungen wird, ¨ahnlich wie durch Google, das erw¨ahnte Netz-im-Netz-Prinzip betrieben wodurch es sich mehr und mehr von dem klassischen Internet abkapselt.

Um einem etablierten Sozialen Netzwerk beizutreten, mussen¨ die Benutzer zuerst die allgemeine Gesch¨aftsbedingungen der Unternehmen akzeptieren. Am Beispiel von Face- book bedeutet das relative Willkur.¨ So beh¨alt sich Facebook als Beispiel das Recht vor, Accounts zu sperren, ohne dass Betroffene weitere rechtliche Handhabe dagegen h¨atten [Ber14].

Trotz der hohen Bekanntheit und weiten Verbreitung etablierter Sozialer Netzwerke kommt es immer wieder zu den in Tabelle1 auf Seite 18 aufgef uhrten¨ Ph¨anomenen, die zu einer Abwanderung und Fernbleiben von Nutzern fuhren.¨

Seite 16 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Abbildung 5: Nutzerzahlen in etablierten und dezentralen Sozialen Netzwerken weltweit [Jun14][rob14][jpo14]

Abbildung 6: Social Media und soziale Netzwerke – Nutzerzahlen in Deutschland 2014 [Bug14]

Seite 17 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Ursachen die zur Nichtnutzung eines Sozialen Netzwerks fuhren¨ k¨onnen Ursache Beschreibung Abschaltung Das Soziale Netzwerk wird abgeschaltet und ist nicht mehr erreichbar. Das Soziale Netzwerk wer-kennt-wen wurde beispielsweise am 02.06.2014 vollst¨andig abge- schaltet. Anderung¨ der AGB Eine Anderung¨ der Allgemeine Gesch¨aftsbedingungen die z.B. die Datenschutzbestimmungen betreffen sorgen in der Vergangenheit immer wieder zu Protesten und einem Ruckgang¨ der Benutzerzahlen [Ulb14]. Sperrung (z.B. durch Soziale Netzwerke werden beispielsweise zur Koordi- Regierungen und Ge- nation von Protesten genutzt. Aufgrund der jungsten¨ setze) Unruhen (15.06.2014) ließ die irakische Regierung zum Beispiel Facebook, Twitter und andere Social-Media- Dienste sperren [Obe14]. Hackerangriffe, DDOS Zentrale Netzwerke sind h¨aufig Opfer digitaler Angrif- oder Ahnliches¨ fe. Die Dienste stehen w¨ahrend des Angriffs zeitweise nicht zur Verfugung.¨ Ein l¨angerer oder dauerhafter Aus- fall kann dazu fuhren,¨ dass Nutzer auf andere Plattfor- men ausweichen (siehe ebenfalls MySpace in Wechsel zu anderen Plattformen). Wechsel im sozialen Die Entscheidung zur Nutzung eines Netzwerks h¨angt Umfeld h¨aufig von dem sozialen Umfeld ab. Nutzt der Freundes- kreis eine spezielle Plattform, ist die Wahrscheinlichkeit hoch, dass ein Nutzer sich ebenfalls fur¨ das Netzwerk des Freundeskreises entscheidet oder sogar dorthin wechselt. Politisches oder Besondere Ereignisse die durch die Medien aufgegrif- gesch¨aftliches Ereignis fen werden, bewegen Menschen dazu ein Soziales Netz- werk vollst¨andig zu verlassen. Im Juni 2014 wurde be- kannt, dass Facebook gezielt den Newsfeed von fast 700.000 Mitglieder manipulierte um Verhaltensexperi- mente durchzufuhren¨ [Saw14]. Die Presse schrieb dazu: Facebook betreibt Nutzerforschung wie mit Laborratten. Negative Schlagzeilen und Enthullungen¨ betreffen in vie- len F¨allen den Datenschutz und die Privatsph¨are der Anwender. Wechsel zu anderen Ein Paradebeispiel ist das Soziale Netzwerk MySpace. Plattformen Z¨ahlte es im September 2009 mit 267.794.915 Mitglie- dern noch zu den gr¨oßten Netzwerken weltweit be- gann im Jahr 2011 ein extremer Ruckgang¨ der Nutzer. Haupts¨achlich verliert MySpace Nutzer an damals neue Netzwerke wie Facebook. Es fehlten neue Innovationen – dazu kamen lange Ladezeiten und Sicherheitslucken¨ in der Anwendung [Dat14]. 2011 verliert das Netzwerk monatlich bis zu zehn Millionen Nutzer [Red14].

Tabelle 1: Ursachen die zur Nichtnutzung oder L¨oschung des Accounts in einem Sozialen Netzwerks fuhren¨ k¨onnen

Seite 18 Kapitel 2 Stand der Wissenschaft (State of Social Media)

2.3 Funktionen in Sozialen Netzwerken

Die unz¨ahligen Sozialen Netzwerke bieten unterschiedliche Funktionalit¨aten und stellen jeweils verschiedene oder mehrere davon in den Vordergrund. Am h¨aufigsten wird inner- halb von Sozialen Netzwerken die Funktion Nachrichten verschicken/chatten verwendet – sowohl station¨ar als auch mobil [Gmb13]. Alexander Richter und Michael Koch schla- gen in ihrem Artikel Funktionen von Social-Networking-Diensten fur¨ die Multikonferenz Wirtschaftsinformatik. Vol. 26. 2008 vor, die Funktionen von Sozialen Netzwerken in die sechs Gruppen zu unterteilen [RK08]: Siehe dazu ebenfalls Abbildung7 auf Seite 22, die den Prozess der einzelnen Schritte grafisch darstellt und veranschaulicht. Die einzelnen Schritte mussen¨ nicht zwangsl¨aufig nacheinander ablaufen und sind alle untereinander ver- bunden. Der Prozess kann zu einem beliebigen Zeitpunkt starten und muss nicht immer mit dem Identit¨atsmanagement beginnen.

Identit¨atsmanagement: Beschreibt die M¨oglichkeit sich selbst (z.B. durch ein Profil) darzustellen. Die Identit¨at enth¨alt bewusst ¨offentliche Informationen (z.B. ein Fo- to, einen Namen oder detailierte personenbezogene Informationen wie das Alter oder Geschlecht) die fur¨ andere Nutzer zug¨anglich gemacht werden. Diese Selbst- pr¨asentation stillt mehrere soziale Bedurfnisse¨ eines Nutzers (vgl. [RK08, S.6ff]). Benutzer-Profile mit Namen und Bild (oder Avatar) stellen eine Grundfunktion in Sozialen Netzwerken dar. Die Umsetzungen in den verschiedenen Plattformen ¨ahneln sich h¨aufig. Einige Soziale Netzwerke, wie Facebook verlangt fur¨ die Profile eine Klarnamenpflicht in den Nutzungsbedingungen. Das bedeutet, dass sich jeder Benutzer mit seinem echten Namen anmelden muss um teilzunehmen. In der Pra- xis werden allerdings h¨aufig Pseudonyme verwendet. Benutzer wollen bewusst nicht von anderen Benutzern gefunden werden (zum Beispiel von einem Vorgesetzten). Facebook beh¨alt sich vor, Profile mit Pseudonymen zu sperren und erst unter Zu- sendung einer Ausweiskopie und Anderungen¨ des Benutzernamen wieder freizugeben [Wie14].

(Experten)-Suche: Die Suche beschreibt die M¨oglichkeit, ein Soziales Netzwerk nach Inhalten und Personen zu durchsuchen und zu filtern. Eine Suche bzw. Filterung reicht von einfacher Benutzersuche uber¨ Namen oder Kriterien wie Geschlecht oder Alter, uber¨ Filterung durch sog. tags (z.B. Twitter-Hashtag) bis hin zu einer er- weiterten Suchen mit der Unterstutzung¨ von regul¨aren Ausdrucken.¨ Die erweiterte Suche als bezahlter Premium-Dienst bei Xing erlaubt beispielsweise eine genaue Ermittlung von Personen, die auf ein bestimmtes F¨ahigkeiten-Profil passen, und schließt ebenfalls Treffer mit ein, die das System automatisch vorschl¨agt. Bei den

Seite 19 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Sozialen Netzwerken werden h¨aufig andere Benutzer oder Inhalte mit Worten wie Kennen Sie schon ...? vorgeschlagen [RK08, S.7ff] und ¨ahnliche Inhalte quer ver- linkt. Bei YouTube werden Beispielsweise Videos angezeigt, die einen ¨ahnlichen Titel haben oder von anderen Benutzern ebenfalls in Verbindung mit dem aktuellen Video angesehen wurden. Eine Personensuche setzt voraus, dass andere Nutzer Informa- tionen uber¨ ihre Identit¨at ¨offentlich preisgeben. In Business-Netzwerken wie Xing und LinkedIn ist dies ublicher¨ als in privat genutzten Netzwerken.

Kontextawareness (Kontext/Vertrauensaufbau): Beschreibt den Verbindungsauf- bau zu anderen Nutzern im Sozialen Netzwerk. Der Beziehungsaufbau kann dabei entweder uber¨ gemeinsame Bekannte, Inhalte und Kontext oder die Suche statt- finden. In vielen Sozialen Netzwerken kann ein Nutzer die Beziehung zu anderen Nutzern uber¨ ein bereits verbundenes Profil nachvollziehen und einsehen. Die Ver- bindung uber¨ gemeinsamen Kontext ist zum Beispiel in Foren, Gruppen oder Kom- mentaren zu beobachten. Durch gemeinsame Interessen wie zum Beispiel der gleiche Musikgeschmack, k¨onnen Beziehungen zu anderen Nutzern aufgebaut werden. Die Vernetzung uber¨ gemeinsame Bekannte ist durch den sozialpsychologischen Begriff Kleine-Welt-Ph¨anomen (vgl. [Mil67, S.60-67]) gestutzt.¨ Das umstrittene Kleine- Welt-Ph¨anomen beschreibt die enge soziale Vernetzung von Personen in unser mo- dernen Gesellschaft. Milgram, Stanley stellt 1964 die These auf, dass jeder Mensch mit einem anderen uber¨ eine sehr kurze Kette von Personen bzw. Bekannten ver- bunden ist. In Experimenten stellt sich eine Kette von der maximalen L¨ange sechs heraus. Das Ph¨anomen wird daher auch als Six Degrees of Separation bezeichnet. Im Jahr 2008 haben Wissenschaftler von Microsoft die These des Kleine-Welt- Ph¨anomen fur¨ den Microsoft Instant-Messenger mit 240 Millionen Menschen und einem Graphen mit 180 Millionen Knoten und 1,3 Milliarden ungerichteten Kanten empirisch best¨atigen k¨onnen [LH08]. Einige Soziale Netzwerke zeigen die kurzeste¨ Verbindungen zu einer Personen uber¨ Freunde grafisch an [RK08, S.8ff]. Eine fur¨ die Kontextawareness verbreitete Funktion ist das automatische Vorschlagens von Freunden nach dem Format: Eine große Anzahl deiner Kontakte ist mit Person Y befreundet. Kennst du Y?

Netzwerkawareness: Die Netzwerkawareness beschreibt die Aktivit¨at oder Ereignisse von Nutzern innerhalb eines Sozialen Netzwerks. Nach der Anmeldung bekommt der Nutzer zum Beispiel die Geburtstage seiner Kontakte oder Status¨anderungen (Person X ist jetzt mit Person Y befreundet) angezeigt. Diese Funktionen animieren den Nutzer mit seinen Kontakten in Verbindung zu treten. In diesem Fall k¨onnte der Nutzer beispielsweise Geburtstagsgruße¨ und einen Kommentar hinterlassen, was

Seite 20 Kapitel 2 Stand der Wissenschaft (State of Social Media)

wiederum eine Gegenreaktion ausl¨osen kann. Funktionen der Netzwerkawareness haben sich als Erfolgsfaktor fur¨ die sogenannte stickiness (wie lange sich ein Nutzer auf einer Plattform aufh¨alt) erwiesen (vgl. [RK08, S.9ff]). Spezifikationen wie http: //activitystrea.ms (serialization of a stream of social activities) versuchen diese Str¨ome von Aktivit¨aten zu vereinheitlichen.

Kontaktmanagement: Das Kontaktmanagement umfasst alle Funktionen die sich mit der Pflege und Verwaltung des pers¨onlichen Beziehungsnetzwerkes befassen. Die Grundfunktionalit¨aten sind in der Regel das Hinzufugen¨ und Entfernen von Per- sonen. Die Sozialen Netzwerke bieten verschiedene Auspr¨agungen und Umsetzun- gen des Kontaktmanagements. In Facebook werden direkte Freundschaftsanfragen gestellt, der beide Teilnehmer (1:1) zustimmen mussen.¨ Der Nutzer kann seine be- stehenden Beziehungen innerhalb seines Facebook-Accounts in Listen verwalten. In dem Microblogging-Dienst Twitter werden zwei Arten von Kontakten unterschie- den: Follower sind Personen die Beitr¨age des Nutzers abonniert haben; Following (dt. Folge ich) sind die Personen die der Nutzer selbst abonniert hat. Eine Bezie- hung in Twitter muss sich nicht zwangsl¨aufig gegenseitig folgen. Die Beziehung ist also, anders als bei Facebook, asymmetrisch [EGH11, S.88ff]. In Googleplus lassen sich Personen in verschiedene Kreise einordnen. Eine Person kann sich gleichzeitig in mehreren Kreisen des Nutzers befinden. Nachrichten und Statusmeldungen lassen sich an diese Personenkreise (z.B. Sportverein oder Kollegen) oder die Offentlichkeit¨ adressieren. Die Beziehungen in Googleplus sind ebenfalls asymmetrisch. Das Kon- taktmanagement in Sozialen Netzwerken l¨asst sich mit einem Adressbuch verglei- chen, dass die Kontaktinformationen selbstst¨andig aktualisiert, sobald eine Person Informationen zu seiner Identit¨at (z.B. eine E-Mail-Adresse) ¨andert. In Xing k¨onnen daruber¨ hinaus nicht ¨offentlich zug¨angliche Notizen und Tags mit Personen ver- knupft¨ werden.

Gemeinsamer Austausch (Kommunikation): Die wichtigste und in fast jedem So- zialen Netzwerk umgesetzte Funktionalit¨at ist Austausch, Erg¨anzung, Verteilung und Erzeugung von Inhalten (engl. Content). Benutzer k¨onnen sich gegenseitig di- rekt, in Gruppen oder (quasi-)¨offentlichen Nachrichten, Bilder, Videos, Musik, Da- teien etc. schicken. Personen mit denen eine Beziehung besteht oder fremde Nutzer haben dann, je nach konfigurierter Sichtbarkeit (z.B. nur fur¨ Freunde oder Freunde von Freunden) und Berechtigung, die M¨oglichkeit den Inhalt beispielsweise zu kom- mentieren, zu favorisieren (engl. liken) und zu verteilen. Der gemeinsame Austausch schließt ebenfalls kollaboratives Arbeiten an Daten jeglicher Art und Wissensma- nagement mit ein. Die Kommunikation hat sowohl Schnittpunkte zu der Kontexta-

Seite 21 Kapitel 2 Stand der Wissenschaft (State of Social Media)

wareness als auch zu der Netzwerkawareness, da durch den Austausch von Inhalten neue Aktivit¨aten erzeugt werden (z.B. Person X hat ein Foto kommentiert) und neue Beziehungen entstehen k¨onnen. Je nach Art des Sozialen Netzwerks h¨angt das Identit¨atsmanagement mehr oder weniger mit dem Inhalt zusammen. In einigen Netzwerken wie zum Beispiel 4Chan findet der Austausch von Inhalten bewusst an- onym statt. Ebenso unterscheidet sich die Reichweite der Kommunikation stark. Bei Twitter ist es, abgesehen von Direktnachrichten, meistens gewunscht¨ einen m¨oglichst großen Personenkreis zu erreichen. Anders bei Facebook, wo der eigenen Facebook- Messenger zus¨atzlich zur ¨offentlichen Kommunikation als E-Mail- und SMS-Ersatz dienen soll. Der Inhalt spielt aber nicht bei jedem gemeinsamen Austausch eine Rolle. Bei Facebook lassen sich beispielsweise Profile anstupsen (engl. poke) um Personen zu zeigen, dass man an sie gedacht hat (vgl. [RK08, S.10ff]). In den VZ- Netzwerken wird diese Funktion als Beispiel gruscheln (inoffiziell fur¨ grußen¨ und kuscheln) genannt.

Abbildung 7: Die Funktionen des IT-gestutzten¨ Social Networking nach Richter et. al.[RK08]

Alexander Richter und Michael Koch schreiben in ihrem Fazit und Ausblick weiter (vgl. [RK08, S.11]):

Ein Vorteil dieser Einteilung ist, dass damit die aktuell laufenden Bestrebun- ”

Seite 22 Kapitel 2 Stand der Wissenschaft (State of Social Media)

gen zu Modularisierung und Integration von Social-Networking-Diensten ge- ordnet und strukturiert werden k¨onnen. So kann die Einteilung Anhaltspunkte fur¨ die Aufteilung von Diensten, fur¨ die Definition von APIs oder die Stan- dardisierung von Schnittstellen und Austauschformaten liefern. Hintergrund dieser Notwendigkeit ist vor allem, dass aufgrund der Mehrfachmitgliedschaft von Nutzern in verschiedenen Diensten der Austausch untereinander und die Nutzung von gemeinsamen Basisdiensten zwischen SNS immer wichtiger wer- den.“

Die Aussage unterstutzt¨ die Annahme, dass es fur¨ Nutzer wichtig ist, verschiedene Soziale Netzwerke mit einer gemeinsamen Basis zu steuern. Viele Nutzer sind bereits fur¨ die Nut- zung verschiedener Funktionen oder auf Grund verschiedener Zielgruppen in mehreren unterschiedlichen Netzwerken registriert. Die Tabelle2 auf Seite 25 zeigt den Fokus und Schwerpunkt einer kleinen Auswahl der weltweit agierenden etablierten Sozialen Netzwer- ke. Die Tabelle soll veranschaulichen, wie unterschiedlich die Ausrichtungen der Netzwerke sind. Einige dieser etablierten Netzwerke sprechen bestimmte M¨arkte und Personengrup- pen an oder haben eine Kontinentale- oder L¨anderspezifische Zielgruppe.

Netzwerk Kern-Feature Facebook Generelles Netzwerk: Nachrichten inkl. Messenger, Beziehun- facebook.com gen, Veranstaltungen, Gruppen, Fotos, Videos, Blogs, Apps. Googleplus Generelles Netzwerk: Nachrichten inkl. Messenger, Beziehun- plus.google.com gen, Gruppen, Fotos, Videos, Blogs Twitter Microblogging, RSS-Feeds, Updates, alle Nachrichten mit twitter.com max. 140 Zeichen LinkedIn Business und Professionelles Networking, Gesch¨aftskontakte, linkedin.com Jobs, erweiterte Suchen Qzone Chinesisches Netzwerk, Blogs, Tagebucher,¨ Fotos, Musik, Vi- qzone.qq.com deos, kostenpflichtige Dienste Sina Weibo Gr¨oßter chinesischer Social Microblogging Dienst (entspricht weibo.com Twitter) VZ-Netzwerke Generelles Netzwerk: Nachrichten, Beziehungen, Gruppen, meinvz.net Fotos, G¨astebuch YouTube Video Sharing, kommentieren und abonnieren, Kan¨ale youtube.com Pinterest Online Pinnwand fur¨ Bilder-Kollektionen, kommentieren, li- pinterest.com ken weiter auf der n¨achsten Seite

Seite 23 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Tabelle 2 – Fortfuhrung¨ der vorherigen Seite Netzwerk Kern-Feature Tumblr Blogging-Plattform fur¨ Texte, Bilder, Zitate, Chatlogs, Links tumblr.com und Video- sowie Audiodateien WhatsApp Ausschließlich mobil genutzter Messenger whatsapp.com Vkontakte Generelles Netzwerk (¨ahnelt Facebook), Beziehungen, Fotos, vk.com Videos, Musik, Suche. Beliebt in Russland und der ehemaligen Sowjetunion Instagram Vorrangig mobil genutzter Foto- und Video-Sharing-Dienst instagram.com Flickr Foto-Sharing, kurze Videos, Kommentare, Notzien, stark auf flickr.com Fotografie ausgerichtet 4Chan Anonyme Bilder-Pinnwand (engl. Imageboard) fur¨ Foto- 4chan.org Sharing mit Kommentaren Odnoklassniki Generelles Netzwerk fur¨ Kontakte zu alten Klassenkamera- odnoklassniki.ru den, Kommilitonen und Arbeitskollegen. Beliebt in Russland und der ehmaligen Sowjetunion Renren Generelles Netzwerk in China. Profitiert von der Sperrung renren.com Facebooks durch die chinesische Regierung douban Chinesische Webseite fur¨ Reviews und Empfehlungen von Fil- douban.com men, Buchern¨ und Musik LiveJournal Besonders im russischsprachigen Raum beliebte Online- livejournal.com Blogging Plattform. Der Quellcode der Server-Software ist einsehbar. Das Repository http://code.livejournal.org ist allerdings zum Zeitpunkt der Erstellung der Arbeit nicht erreichbar gewesen. deviantART Kunst-Community, kommentieren, anbieten und kaufen von deviantart.com digitalen Medien StumbleUpon Social-Bookmarking-Dienst der nach Interesse des Nutzers stumbleupon.com Webinhalte empfiehlt. Die Empfehlungen k¨onnen, fur¨ alle ein- sehbar, kommentiert und bewertet werden Yelp, Inc. Empfehlungs- und Bewertungsportal fur¨ Gesch¨afte und Ga- yelp.com stronomie. Das Protal wird vorrangig in den USA genutzt weiter auf der n¨achsten Seite

Seite 24 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Tabelle 2 – Fortfuhrung¨ der vorherigen Seite Netzwerk Kern-Feature mixi Japans gr¨oßtes soziales Netzwerk mixi.jp XING Business Netzwerk fur¨ die D-A-CH-L¨ander, xing.com Gesch¨aftskontakte, Jobs, Events, erweiterte Suchen SoundCloud Online-Dienst fur¨ Musiker um kostenlos Musik anzubieten. soundcloud.com Der Dienst dient haupts¨achlich als Werbeplattform. Die Mu- sikstucke¨ lassen sich in externe Webseiten einbetten, kommen- tieren und liken. Goodreads Plattform fur¨ Bewertung, Rezensionen und Empfehlungen goodreads.com von Buchern¨ die durch Freunde kommentiert werden k¨onnen Ning Kostenpflichtiger Dienst in dem Benutzer ein eigenes Sozia- ning.com les Netzwerk anlegen und gestalten k¨onnen. Es werden Fotos, Videos, Musik, Chats, Veranstaltungen, Gruppen, RSS-Feed etc. unterstutzt.¨ Nachrichten k¨onnen auf Google, Facebook, Yahoo und Twitter synchron ver¨offentlicht werden Viadeo Business Netzwerk und gr¨oßter Konkurrent von LinkedIn und viadeo.com XING. Gesch¨aftskontakte, Jobs, Suche delicious Social-Bookmarking-Dienst in der Nutzer Online-Lesezeichen delicious.com verwalten und verschlagworten (engl. taggen) k¨onnen. Anwen- der k¨onnen einsehen, welche Nutzer die selben Lesezeichen verwenden und deren Lesezeichen erkunden Meetup Soziales Netzwerk um Offline-Treffen und Aktivit¨aten mit meetup.com vornehmlich fremden Menschen zu planen

Tabelle 2: Fokus und Schwerpunkt einer Auswahl etablierter Sozialer Netzwerke

Um ein Netzwerk anbieten zu k¨onnen, dass Informationen aus verschiedenen Sozialen Netzwerken konsolidiert, mussen¨ die vielen verschiedenen Funktionalit¨aten normiert und auf die wichtigsten Kern-Features beschr¨ankt werden. Das bedeutet, dass beispielswei- se ein Tweet in Twitter inhaltlich einem Post in Facebook entspricht. Beide lassen sich als eine Art von Nachricht beschreiben, die einen Inhalt (engl. Content) (z.B. Text oder Bild) fur¨ eine Zielgruppe bereitstellt. Hierzu wurde eine Detailbetrachtung der Funktio- nen innerhalb einer Auswahl von Sozialen Netzen erstellt (vgl. Abbildung8 auf Seite 27). In der Betrachtung sind die Netze untersucht worden, die aus Sicht eines in Deutsch-

Seite 25 Kapitel 2 Stand der Wissenschaft (State of Social Media) land ans¨assigen Unternehmen als besonders relevant angenommen und eingestuft wurden. Zus¨atzlich ist das sp¨atere Zielsystem pump.io des synthetisierten Informationsstroms in die Betrachtung mit einbezogen worden. Die meisten Sozialen Netzwerke bieten spezielle Programmierschnittstellen APIs an, die besonders fur¨ die Implementierung der Konzep- tion relevant sind. Es werden zur Zeit keine Webseiten-Robots oder Site-Wrapper genutzt und nur die ¨offentlich zug¨anglichen Schnittstellen der etablierten Sozialen Netzwerke ver- wendet. Die Untersuchung zeigt, dass sich die allgemeinen Netze in ihrer Grundfunktion nicht elementar voneinander unterscheiden und die Funktionen in dem Zielsystem abge- bildet werden k¨onnen. Pump.io ist in der Lage diese Funktionen zusammenzufassen. Das unterstutzt¨ die Annahme und Aussicht auf ein Konzept, das erfolgreich mehrere Soziale Netzwerke verbindet und konsolidiert.

Seite 26 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Abbildung 8: Detailierte Funktionen in einer Auswahl von Sozialen Netzwerken als Grund- lage fur¨ eine gemeinsame Basis Seite 27 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Durch Nutzung und Zusammenspiel von verschiedenen Funktionalit¨aten innerhalb Sozia- ler Netzwerke entstehen sogenannte Soziale Graphen (engl. social graph). Mit dem sozialen Graphen, abgleitet aus der Graphentheorie, lassen sich Inhalte, Zusammenh¨ange und Be- ziehungen abbilden, untersuchen und unter anderem grafisch darstellen. Diese Graphen k¨onnen als Informationsquelle fur¨ einen Strom von Neuigkeiten genutzt werden (Benutzer gef¨allt ein Video; Benutzer ist in einer Beziehung mit Benutzer usw.), sind aber vor allem fur¨ Anbieter von personalisierter Werbung besonders wertvoll. Durch den Graphen lassen sich sehr komplexe Zusammenh¨ange untersuchen und berechnen. Die Graphen dienen als Datenbasis fur¨ den kommerziellen Verkauf von personenbezogene Daten. Die Abbildung9 auf Seite 28 zeigt einen fiktiven Graphen, so wie er in einem Sozialen Netzwerk entsteht: Der Nutzer Maili ist mit Klaus und Peter befreundet und nimmt an der Veranstaltung Tims Geburstag teil. Maili gef¨allt Ralphs Foto und sie hat ein bestimmtes YouTube-Video angeschaut. Die Nutzer Klaus und Peter sind nicht untereinander befreundet. Peter kennt allerdings uber¨ 3 Kanten jemanden, der das gleiche Video wie Maili angesehen hat... Die- ser Graph l¨asst sich uber¨ die Beziehungen und Kanten in großen Sozialen Netzwerken fast beliebig fortfuhren.¨

Abbildung 9: Ein beispielhafter Sozialer Graph des fiktiven Nutzers Maili, wie er in So- zialen Netzwerken entsteht

Seite 28 Kapitel 2 Stand der Wissenschaft (State of Social Media)

2.4 Das dezentrale Soziale Netzwerk pump.io

Pump.io (ausgesprochen pump eye-oh) ist eine Freie Software und Stream-Server, der ein dezentrales Soziales Netzwerk mit sog. Aktivit¨atsstr¨omen (engl. Activity Steams) bereit- stellt [CC11]. Bei pump.io handelt es sich um eine API-Driven-Development Software. Alle Funktionen innerhalb der Software lassen sich uber¨ eine klar definierte Schnittstelle steu- ern. Der Server stellt eine einfach anzusteuernde REST-Schnittstelle bereit, die zus¨atzlich mit einer optionalen Web-Oberfl¨ache ausgeliefert wird. Grunds¨atzlich sind in pump.io das Front- und Back-End strikt getrennt. Pump.io ist die Software hinter dem am 01.07.2008 erschienen Mikro-Blogging-Dienst identi.ca und der Nachfolger der Software StatusNet, die im Juni 2013 durch pump.io abgel¨ost wurde. Die Software befindet sich zur Zeit noch im Alpha-Status und ist vor allem im offiziellen Web-Frontend an vielen Stellen unvoll- st¨andig oder fehlerhaft. REST bedeutet, dass jede Nachricht alle Informationen enth¨alt, die der Server bzw. Client ben¨otigt, um sie zu verstehen. Eine REST-Nachricht l¨asst sich zum Beispiel durch eine bestimmte URL wie example.com/user/feed aufrufen. REST schließt ebenfalls ein, dass sich unterschiedliche Repr¨asentationen hinter demselben Auf- bzw. Abruf verbergen. Damit kann realisiert werden, dass verschiedene Benutzer hinter derselben URL verschiedene Inhalte angezeigt bekommen. Zus¨atzlich zur URL, benutzt REST auch URI, um einzigartige Ressourcen im System zu benennen. Weiterhin mussen¨ REST-konforme Dienste Operationen auf Ressourcen im System erlauben. Bei HTTP sind die Operationen GET, POST, PUT und DELETE vorgesehen [Fen13]. Alle GET- Anfragen durfen¨ nur lesend auf das System zugreifen und dabei keine Daten ver¨andern. GET, HEAD, PUT mussen¨ zus¨atzlich idempotent sein. Idempotenz bedeutet, dass ein einzelner Abruf den gleichen unver¨anderten Inhalt zuruckliefert¨ wie ein mehrfacher Abruf der gleiche Ressource.

Jeder pump.io-Server, im Folgenden Instanz genannt, in dem verteilten pump.io-Netzwerk kann vollst¨andig autark arbeiten und betrieben werden. Uber¨ einen auf OAuth basierten Remote-Login haben Nutzer fremder Instanzen die M¨oglichkeit, sich an einem entfern- ten, im Netzwerk (z.B. Internet) erreichbaren, Server anzumelden. Benutzer k¨onnen sich, wie bei Twitter, gegenseitig abonnieren und Inhalte austauschen. Wenn ein oder mehrere Instanz-Knoten offline gehen oder nicht mehr erreichbar sind, bleibt der Rest der Netz- Infrastruktur intakt. Selbst entfernte Nachrichten bzw. Aktivit¨aten bleiben erhalten, da jeder Server lokale Kopien der fur¨ ihn relevanter Inhalte vorh¨alt (nicht alle). Werden Daten an der Quelle ge¨andert oder von der Quelle verschickt werden alle Instanzen der Empf¨anger der Aktivit¨at uber¨ eine Fernubermittlungs-Funktion¨ (engl. remote delivery) informiert. Pump.io arbeitet nach dem Motto: Don’t Call Us, We’ll Call You. Sind neue Informationen generiert, werden die Empf¨anger-Instanzen informiert und nicht wie ublich¨

Seite 29 Kapitel 2 Stand der Wissenschaft (State of Social Media) die Informationen vom Empf¨anger am Sender abgefragt (vorstellbar w¨are eine st¨andige Abfrage aller Aktivit¨aten von Following-Benutzern). Bin¨ardaten werden grunds¨atzlich nur als Referenz gespeichert. Die Referenzen zeigen auf uber¨ HTTP(S) abrufbare Objek- te. Nutzer k¨onnen Aktivit¨aten erstellen und an Ziele adressieren und mit ihnen agieren (z.B. kommentieren). Aktivit¨aten sind Ereignisse jeglicher Art, die im Online- und Off- lineleben stattfinden k¨onnen und nicht zwangsl¨aufig an existierende Objekte wie eine Nachricht gebunden. Beispiele dafur¨ sind: aufwachen, Fahrrad fahren, Foto hochladen, Freund hinzufugen,¨ Mittagessen, Beitrag favorisieren etc. Die Aktivit¨at beinhaltet neben einer Vielzahl von Metadaten wie Ort, Datum, Uhrzeit usw., sofern vorhanden, eine Re- ferenz auf die Information selbst – z.B. das neue Bild, den Nachrichtentext oder die mit dem Fahrrad zuruckgelegte¨ Strecke. Pump.io verwendet das JavaScript Object Notati- on (JSON)-Format um alle Arten von Aktivit¨aten zu repr¨asentieren. Diese Aktivit¨aten werden zu chronologisch angeordneten Informationsstr¨omen (neuste Aktivit¨at zuerst nach dem Last In – First Out (dt. zuletzt rein, zuerst raus) (LIFO)-Prinzip) zusammengefasst. Diese sogenannten Streams werden thematisch sortiert. Thematisch bedeutet beispielswei- se die Sortierung nach Aktivit¨aten an einen Nutzer, von abonnierten Nutzern, zu einem Objekt oder Aktivit¨aten eines bestimmten Typs. Die Streams werden an fest definierten Endpunkten der Instanz bereitgestellt, die von autorisierten Clients oder anderen Sozia- len Netzwerken abfragt oder mit neuen Aktivit¨aten befullen¨ werden k¨onnen. Die Software kummert¨ sich um die weitere Organisation, Berechtigungen und Sichtbarkeit der Akti- vit¨aten und stellt die Zustellung an alle relevanten lokalen und entfernten Ziele sicher [Beh14]. Jeder Benutzer ist durch eine Webfinger-ID (z.B. acct:[email protected]), ¨ahnlich dem E-Mail-Adressformat, eindeutig und einmalig im Netzwerk existent. Akti- vit¨aten k¨onnen an folgende Ziele adressiert werden:

Offentlich:¨ Aktivit¨at wird an alle Follower zugestellt. Follower haben im vorhinein den Ersteller der Aktivit¨at abonniert. Zus¨atzlich k¨onnen die Objekte von jedem, auch nicht autorisierten Benutzern, ¨offentlich eingesehen werden.

Follower: Aktivit¨at wird an alle Follower zugestellt.

Benutzer: Die Aktivit¨at, in diesem Fall eine Direktnachricht, wird an eine oder mehrere Personen zugestellt. Direktnachrichten werden in der Regel vom Client anders in- terpretiert als Aktivit¨aten an Offentlich,¨ Listen oder Follower und werden zus¨atzlich in einen separaten Postkorb mit zus¨atzlicher Notifikation geladen.

Listen: Benutzer k¨onnen Listen von Nutzern oder anderen Objekten anlegen und verwal- ten. Mit Listen k¨onnen Personenkreise (z.B. alle Arbeitskollegen) adressiert werden. Die Zustellung verh¨alt sich ¨aquivalent zu der direkten Zustellung, ist aber durch den

Seite 30 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Adressaten besonders gekennzeichnet.

2.4.1 Endpunkte

Um ein dezentrales Netzwerk aus vielen Knoten aufzubauen, mussen¨ die einzelnen Server untereinander kommunizieren k¨onnen und Benutzer sowie Objekte definierte eindeuti- ge Endpunkte besitzen. Pump.io unterstutzt¨ die Protokolle Web Host Metadata tools. ietf.org/html/rfc6415 und Webfinger der Internet Engineering Task Force (IETF) um Information bereitzustellen und zu empfangen. Das Listing1 zeigt die Endpunkte eines pump.io-Nutzers. Die Inbox (activity-inbox) entspricht dem Posteingang der Feed (activity-outbox) entspricht dem Postausgang. Einige Aktivit¨aten sind fur¨ den Benutzer relevanter als andere. Pump.io bietet daher Sub-Feeds fur¨ die In- und Outbox an, in dem unbedeutende (minor) bzw. bedeutende (major) Aktivit¨aten bereitgestellt werden. Wichtige Aktivit¨aten sind beispielsweise neue Nachrichten – unwichtige Anderungen¨ sind Aktivit¨aten die den Sozialen Graphen betreffen wie zum Beispiel Person X gef¨allt ein Fo- to. Uber¨ die Web Host Metadata werden die Endpunkte fur¨ den OAuth-Anmeldeprozess kommuniziert.

1 { 2 ” l i n k s ” : [ 3 { 4 ”rel”: ”http://webfinger.net/rel/profile −page ” , 5 ”type”: ”text/html”, 6 ”href”: ”https://io.intevation.de/mgebbe” 7 } , 8 { 9 ”rel”: ”dialback”, 10 ”href”: ”https://io.intevation.de/api/dialback” 11 } , 12 { 13 ” r e l ” : ” s e l f ” , 14 ”href”: ”https://io.intevation.de/api/user/mgebbe/profile” 15 } , 16 { 17 ” r e l ” : ” a c t i v i t y −inbox ” , 18 ”href”: ”https://io.intevation.de/api/user/mgebbe/inbox” 19 } , 20 { 21 ” r e l ” : ” a c t i v i t y −outbox ” , 22 ”href”: ”https://io.intevation.de/api/user/mgebbe/feed” 23 } , 24 { 25 ” r e l ” : ” f o l l o w e r s ” , 26 ”href”: ”https://io.intevation.de/api/user/mgebbe/followers” 27 } , 28 { 29 ” r e l ” : ” f o l l o w i n g ” , 30 ”href”: ”https://io.intevation.de/api/user/mgebbe/following” 31 } , 32 { 33 ” r e l ” : ” f a v o r i t e s ” , 34 ”href”: ”https://io.intevation.de/api/user/mgebbe/favorites” 35 } , 36 { 37 ” r e l ” : ” l i s t s ” , 38 ”href”: ”https://io.intevation.de/api/user/mgebbe/lists/person”

Seite 31 Kapitel 2 Stand der Wissenschaft (State of Social Media)

39 } 40 ] 41 }

Listing 1: Webfinger Aufruf eines pump.io-Accounts

2.4.2 Zustellen von Aktivit¨aten

Im Folgenden ist der Prozess der Zustellung von Aktivit¨aten innerhalb des dezentralisier- ten Netzwerkes pump.io erl¨autert.

Benutzer Bill versendet eine neue Aktivit¨at. Pump.io vermittelt die Nachricht zu dem Endpunkt OUTBOX von Bill. Pump.io verteilt die neue Aktivit¨at an die Posteing¨ange der Adressaten (Benutzer, Gruppen, Listen und Follower). Die Aktivit¨aten werden dem Inbox-Stream des jeweiligen Empf¨angers hinzugefugt.¨ Handelt es sich um eine Remote- Instanz, wird dort eine Kopie des Objektes angelegt. Die Kopie wird auf dem Ziel-Server vorgehalten, sodass fur¨ weitere Benutzer, die dieselbe Aktivit¨at erhalten, keine weitere Kopie angelegt werden muss und somit auf der gleichen Ressource gearbeitet wird. Ne- ben der Kopie des Objektes werden Datens¨atze fur¨ Informationen zu der Anzahl von Likes und Shares usw. angelegt. Unter Umst¨anden mussen¨ sich die Server untereinander autorisieren, um Daten austauschen zu k¨onnen. Ist die Zustellung nicht erfolgreich, wird nochmals versucht eine neue Autorisierung durchzufuhren.¨ Wird die Remote-Instanz dann immer noch nicht erreicht, wird die Aktivit¨at nicht zugestellt, bleibt aber an der Quelle selbst erhalten. Dies unterscheidet pump.io von anderen L¨osungen. Die abonnierten Quel- len werden nicht jedes mal aktiv abgefragt (hat Person X Neuigkeiten? Dann Aktivit¨at laden), sondern der Sender verteilt Aktivit¨aten direkt an die Posteing¨ange der Ziele. Um eine Nachricht an alle Follower zu verteilen, wird jedem Teilnehmer dieser dynamischen Liste, der sich Benutzer selbstst¨andig hinzufugen¨ k¨onnen, nacheinander die Aktivit¨at ge- schickt. Die Konstruktion hat verschiedene Vor- und Nachteile. Zum einen ist der Strom von Neuigkeiten unmittelbar verfugbar,¨ selbst wenn viele verschiedene Remote-Instanz in- volviert sind. Zum anderen fuhrt¨ es allerdings dazu, dass Server stark frequentierte Nutzer unter einem hohen Kommunikations-Overhead stehen. Stehen Ziele zu dem Zeitpunkt der Verteilung nicht zur Verfugung,¨ werden die Information und Notifikation nicht zugestellt. Nichtsdestotrotz k¨onnen die jeweiligen Feeds von Nutzern direkt vom Remote-Server ab- gefragt werden. Nach einem Remote-Login und Berechtigungsprufung¨ des Ziel-Servers sind dort auch die nicht ¨offentlichen Aktivit¨aten einsehbar, die unter Umst¨anden bei ei- nem fehlerhaften Zustellungsversuch verloren gegangen sind. Die Abbildung 10 auf Seite 33 veranschaulicht die Zustellung einer Aktivit¨at anhand eines Ablaufplans.

Seite 32 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Abbildung 10: Vereinfachtes Flussdiagramm zur Auslieferung einer Aktivit¨at

Wird eine Aktivit¨at direkt uber¨ eine URL von einem Benutzer aufgerufen, wird gepruft,¨ ob dieser autorisiert ist die Nachricht anzuzeigen. Im eigenen Feed befinden sich aus- schließlich Aktivit¨aten die durch lokale oder entfernte Instanzen zugestellt wurden. Die lokalen Kopien der Nachrichten enthalten nur Text. Bilder und andere Bin¨ardaten wer- den von externen bzw. internen (Speicherort auf eigener Instanz) Quellen nachgeladen.

Seite 33 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Durch diese Konzeption ist gew¨ahrleistet, dass Nachrichten erhalten bleiben, wenn der Absender-Knoten nicht erreichbar ist. Zus¨atzlich wird Speicherplatz fur¨ den Kontext re- lativ irrelevante Dinge wie ein Profilbild gespart. Werden Anderungen¨ an Aktivit¨aten vor- genommen (wie z.B. l¨oschen, like oder share usw.), findet der Zustellungsprozess erneut statt und die jeweilige Aktion wird vom Server durchgefuhrt.¨ Die Konzeption fuhrt¨ aller- dings zu dem Problem, dass beispielsweise gel¨oschte Beitr¨age am Empf¨anger-Server nicht entfernt werden, wenn dieser w¨ahrend des Zustellung nicht erreichbar ist. Die folgenden zur Zeit implementierten Aktionen bewirken Anderungen¨ an Objekten (z.B. Nachrichten) und k¨onnen auf diese angewandt werden [Pro14]. Diese Aktionen k¨onnen leicht erweitert werden, da die Objekt-Typen (verbs) der activitystrea.ms bereits implementiert sind. Be- vor die Aktionen mit den jeweiligen Effekten angewandt werden, findet eine Autorisierung und Berechtigungsprufung¨ statt.

• post: Ein neues Objekt anlegen.

• update: Ein bestehendes Objekt modifizieren.

• delete: Ein Objekt l¨oschen. Die Aktivit¨at bleibt als Endpunkt vorhanden, der Inhalt wird vollst¨andig gel¨oscht.

• follow: Ein Akteur folgt diesem Objekt (meistens einer Person). Neue Aktivit¨aten dieses Objekts werden an die Inbox des Akteurs ubertragen.¨ Der Akteur wird der Followers-Liste des Objekts hinzugefugt.¨ Das Objekt wird der Following-Liste des Akteurs hinzugefugt.¨

• stop-following: Die Verbindung zwischen Akteur und Objekt wird aufgehoben. Die Benutzer werden aus den jeweiligen Liste entfernt und bei zukunftigen¨ neuen Aktivit¨aten nicht mehr informiert.

• favorite / like: Das Objekt wird der Liste der Favorisierungen des Akteurs hinzu- gefugt.¨

• unfavorite / unlike: Das Objekt wird aus der Liste der Favorisierungen des Ak- teurs entfernt.

• add: Ein Akteur kann eigene Listen pflegen. Diese Funktion fugt¨ ein Objekt einer Liste hinzu.

• remove: Ein Objekt wird von einer Liste des Akteurs entfernt.

Seite 34 Kapitel 2 Stand der Wissenschaft (State of Social Media)

2.4.3 Probleme und Risiken

Pump.io befindet sich im Alpha-Status. Einige ben¨otigten Funktionalit¨aten sind noch nicht vollst¨andig oder sehr rudiment¨ar implementiert – von der Implementierung der Web-UI abgesehen. Die grafische Oberfl¨ache interpretiert in der Standardinstallation bei- spielsweise geteilte Nachrichten anderer Nutzer schlecht und stellt diese in einem un- gew¨ohnlichen Format dar. Ebenso kommt es h¨aufig zu Problemen mit gespeicherten Coo- kies, Daten in dem Cache oder vom Template erwartete Ressourcen die nicht gesetzt sind. Einige (wichtige) Funktionen, die bereits vom pump.io-Server im Back-End umgesetzt und bereitgestellt werden, sind in dem mitgelieferten Web-Client nicht implementiert. Das fuhrt¨ zu der Vermutung, dass der fruhe¨ Entwicklungsstand des Front-End bei vielen Nutzern das Gefuhl¨ ausl¨ost, pump.io selbst sei noch v¨ollig unvollst¨andig oder defekt und das System ein Ruckschritt¨ gegenuber¨ des Vorg¨angers StatusNet. Viele der vermissten Funktionen wie z.B. eine Suche und Filterung sowie Darstellungsproblemen lassen sich clientseitig implementieren und sind kein Problem des Konzeptes hinter pump.io. Der pump.io Benutzer JanKusanagi schreibt in einem Artikel Some tips for a better experi- ence using the pump.io network als Hinweis zu diesem Ph¨anomen [(ja14]:

There is life beyond the web interface. Many people see Pump.io’s web inter- ” face, and think the system is very basic and limited. Nothing further from the truth! The thing is that, as we explain in our static page about Pump, the power of this system is based on having lots of different applications built around it, interacting with the “core” of the system: Pumpa, Dianara and Choqok on the desktop, Impeller, Puma and AndStatus in smartphones and tablets, etc.“

Pump.io setzt großen Wert auf die Privatsph¨are der Nutzer und Funktionen zur Sicht- barkeit von Nachrichten. Diese Konsequenz sorgt in einigen Teilen der Software fur¨ ein atypisches bzw. vom Nutzer unerwartetes verhalten. Ein Beispiel: Kommentare auf Nach- richten die an alle Follower gerichtet sind, sind nur fur¨ den Absender und Empf¨anger sichtbar. Ein anders Beispiel: Neue Nachrichten an alle Follower (bei vielen Clients der default) sind nicht ¨offentlich einsehbar, obwohl jeder Benutzer mit einem Account Follower werden kann. Diese und ¨ahnliche Verhaltensmuster halten sich konsequent an die eigene Konzeption von pump.io, werden aber aus Erfahrungen des Betriebs in einem Unterneh- men von einigen Benutzern anders erwartet. Die Community ist dabei in die Entwicklung involviert und das Verhalten von pump.io noch nicht gesetzt und in Stein gemeißelt. Eini- ge der jetzigen Verhaltensweisen sind mit dem Hinweis des Entwicklers Das kann sich in Zukunft noch ¨andern ( Some of this may change a little in the future...“) gekennzeichnet. ”

Seite 35 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Bei der Umsetzung der Arbeit sind Probleme der Konzeption der aktuellen Implemen- tierung von pump.io festgestellt und getestet worden. Im Folgenden werden ausgew¨ahlte Probleme beschrieben.

• Sicherheitsprobleme: Zur Zeit sind keine Berechtigungsgruppen konfiguriert. Mel- det sich ein Benutzer an einer Remote-Instanz oder Anwendung fur¨ den Datenaus- tausch an, werden alle und nicht nur bestimmte Berechtigungen gefordert. Derzeit sind das die Funktionen: neue Aktivit¨aten posten, Aktivit¨aten und den Sozialen Graphen lesen, Profilinformationen ¨andern. Durch diese Struktur der Berechtigung (alles oder nichts) ist es fur¨ Administratoren von Remote-Instanzen m¨oglich, die Berechtigungsnachweise von Benutzern aus der Datenbank der Remote-Servers aus- zulesen und von diesem Server aus Anfragen zu stellen um beispielsweise den Po- steingang zu lesen oder Nachrichten zu ver¨offentlichen. Das fuhrt¨ zu dem Problem, dass auch private Nachrichten innerhalb einer Instanz nicht sicher sind, wenn sich ein Benutzer auf einer unbekannten Remote-Instanz eingeloggt hat.

• Geteilte Inhalte: Weiter geteilte Inhalte haben als Quelle die ursprungliche¨ Nach- richt. Teilt ein Benutzer eine Nachricht an seine Follower, k¨onnen die Follower diese Nachricht aufgreifen und weiter verteilen (sharen). Die Follower des Teilen- den k¨onnen den Inhalt der Nachricht sehen, da uber¨ die (Remote-)Zustellungs- Funktion von pump.io der Inhalt der Nachricht beim teilen kopiert wird. Aufgrund der Sichtbarkeit der Original-Nachricht haben die Empf¨anger des Shares aber keine M¨oglichkeit die ursprungliche¨ Nachricht aufzurufen oder zu prufen.¨ Grunds¨atzlich macht das Sinn, ist aber inkonsequent durchgesetzt, da der sichtbare kopierte Inhalt auf die nicht sichtbare Quelle verweist.

• Prufungen¨ in der dezentralen Struktur: Uber¨ die Grenzen einer Instanz hinweg k¨onnen sich Benutzer im dezentralen Netzwerk gegenseitig folgen bzw. abonnieren. Neue Aktivit¨aten werden an diese Benutzer (Follower) verteilt und in einer Liste des lokalen Benutzers angezeigt. Durch nicht ausreichende Prufung¨ im Server kann ein Administrator einer pump.io-Instanz durch Manipulation in der Datenbank einem lokalen Benutzer beliebige Follower (auch von Remote-Instanzen!) hinzufugen.¨ Die- se manipulierten, selbst hinzugefugten,¨ Follower erhalten, wie echte Follower neue Aktivit¨aten des Benutzers. In der Following-Liste (Folge ich) des angegriffenen Be- nutzers auf der Remote-Instanz taucht dieser manipulierte Follower nicht auf.

• L¨oschen und Updates von Objekten: Werden Objekte ver¨andert oder gel¨oscht, werden alle Empf¨anger daruber¨ informiert und die jeweilige Aktion auf der Remote- Kopie angewandt. Stehen Remote-Instanzen zu diesem Zeitpunkt der Verteilung

Seite 36 Kapitel 2 Stand der Wissenschaft (State of Social Media)

nicht zur Verfugung,¨ werden die Aktionen auf den Objekten nicht angewandt. Das kann dazu fuhren,¨ dass bereits ge¨anderte oder gel¨oschte Informationen noch im ursprunglichen¨ Zustand auf einer Remote-Instanz verbleiben.

• Speicherproblematik: Dieses Problem kann vor allem bei der Nutzung einer vollst¨andigen In-Memory Datenbank (alle Informationen im Arbeitsspeicher) zu Schwierigkeiten fuhren.¨ Jede Aktion, wie zum Beispiel der bloße Versuch eines Remote-Logins fuhren¨ zu einem, bei anderen Aktionen in der Regel sogar zu meh- reren, neuen Eintr¨agen in die Datenbank des jeweiligen Servers. Weiter werden alle Empfangenen und angezeigten Aktivit¨aten und Nachrichten lokal kopiert. Das fuhrt¨ selbst bei der Speicherung von Text schnell zu einem hohen Platzbedarf. Aktuell wer- den zu keinem Zeitpunkt unwichtige oder ungenutzte Datenbankeintr¨age gel¨oscht, wegger¨aumt oder ausgelagert. Das macht einzelne pump.io-Server sehr anf¨allig fur¨ Denial of Service-Attacken. Diese Attacken sind allerdings generell ein Problem von interaktiven Web-Services die Daten lokal persistieren.

2.5 Rechtliches

Das Konzept fremde Inhalte auf andere Server zu kopieren, Inhalte anderer weiter zu ver- teilen oder Kommentare automatisch im Namen anderer zu ver¨offentlichen birgt rechtliche Aspekte und Risiken, die untersucht und betrachtet werden mussen.¨ Ebenso versuchen die etablierten Sozialen Netzwerke sich in ihren Terms of Service (TOS) bzw. Allgemeine Gesch¨aftsbedingungen (AGB) vor der Untergrabung des eigenen Dienstes zu schutzen.¨

M¨ogliche Haftungsrisiken sind dem Urheberrecht zu entnehmen. Es stellt sich die Frage, ob der jeweils weiter geteilte bzw. kopierte und in ein anders System ubernommene¨ Inhalt – vor allem bei Musik, Bildern und Videos – uberhaupt¨ ver¨offentlicht werden darf. Dienste wie Facebook, Twitter und Googleplus bieten im eigenen System Teilen-Funktionen an und ubernehmen¨ in der Nachricht automatisch kleine Vorschaubilder in einer Miniaturan- sicht, die unter dem Namen des Benutzers ver¨offentlicht werden [Ulb11]. Das Urheberrecht schutzt¨ Fotos, Videos und individuelle Texte. Kurze oder banale Texte, wie es bei Twitter- Postings (tweets) der Fall ist, sind in der Regel nicht geschutzt.¨ Fotos und Videos sind per se immer durch das Urheberrecht geschutzt.¨ Das weiter teilen und einfache kopieren in andere Netzwerke kann auch mit Quellenangabe, unabh¨angig vom Anbieter, nach deut- schem Recht rechtliche Konsequenzen nach sich ziehen [Sch13]. Das bedeutet, dass dem Urheber allein die wesentlichen Verwertungsrechte zustehen und bei einer Ver¨offentlichung im Internet jedes mal dessen Zustimmung eingeholt werden muss [Ulb11]. Naturlich¨ gibt es Bilder, Videos und Musik, die unter die Gemeinfreiheit oder besonderen Verwertungs-

Seite 37 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Lizenzen wie die Creative Commons (de.creativecommons.org) fallen. Letzteres erlaubt die Weitergabe unter Namensnennung ausdrucklich.¨ In dem Beschluss des Landgerichts Berlin vom 15.03.2011 (Az. 15 O 103/11) heißt es:

Urheberrechtliche Haftung bei Einbindung fremder RSS-Feeds - Das Einbin- ” den urheberrechtlich geschutzter,¨ fremder Inhalte und Lichtbilder in eine In- ternetseite mittels RSS-Feed ohne entsprechende Rechtseinr¨aumung ist rechts- widrig. “ [rec11]

Durch den Beschluss ist davon auszugehen, dass sich weiter geteilte Inhalte ¨ahnlich wie ein RSS-Feed verhalten und der Teilende als Anbieter und Seitenbetreiber des Inhalts auftritt. In dem Beschluss hat das LG-Berlin geurteilt, dass der Einbindende das Exklusivrecht des Urhebers auf ¨offentliche Zug¨anglichmachung (§19a UrhG) verletze [Ulb11]. Die folgenden Leits¨atze sind dem Urteil zu entnehmen:

1. Durch das Einbinden eines fremden RSS-Feeds in eine Internetseite wer- ” den dort enthaltene urheberrechtlich geschutzte¨ Inhalte und Lichtbilder (§72 UrhG) ¨offentlich zug¨anglich gemacht (§19a UrhG). Fehlt es an einer (insoweit erforderlichen) Rechtseinr¨aumung ist eine solche Nutzung rechtswidrig und der Betreiber der Internetseite hierfur¨ verantwortlich.“

2. Werden fremde Inhalte mittels RSS-Feed in eine Internetseite eingebun- ” den, macht sich der Seitenbetreiber diese Inhalte einschließlich dazu geh¨orender Fotos bzw. Lichtbilder zu eigen. Dies gilt auch dann, wenn der Nutzer der be- treffenden Internetseite durch die Nennung des Anbieters des RSS-Feeds bzw. der daruber¨ eingebundenen Nachrichten erkennt, dass die Beitr¨age von die- sem Anbieter stammen und im Impressum der Internetseite ein Haftungsaus- schluss enthalten ist (mit Verweis auf LG Berlin, Urteil vom 27.04.2010 - 27 O 190/10, MIR 2010, Dok. 081).“ [rec11]

Auch wenn es in der Praxis nicht zu st¨andiger Verurteilung und Anzeige aufgrund von geteilten Inhalte kommt und die vollst¨andige rechtliche Grundlage innerhalb von Sozialen Netzwerken nicht gekl¨art ist, sind die Risiken einer urheberrechtlichen Inanspruchnahme beim Teilen von geschutzten¨ Inhalten (das gilt im besonderen fur¨ Bilder, Musik und Videos) nicht ausgeschlossen [Ulb11]. Dennoch wird in der Zukunft von den Gerichten genau zu kl¨aren sein, ob das Sharing von Inhalten uberhaupt¨ eine fur¨ das Urheberrecht relevante Nutzung darstellt. Eine Kopie erfullt¨ diese Voraussetzung in der Regel aber schon. Um sich im Falle einer Anzeige im Zweifel auf das Haftungsprivileg oder Zitierrecht berufen zu k¨onnen, ist eine genaue Kennzeichnung der ubernommenen¨ Inhalte n¨otig.

Seite 38 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Es gilt eine deutliche optische Unterscheidung zu eigenen Beitr¨agen und Verlinkung der originalen Quellen vorzunehmen. Ebenso wichtig ist es, einen geteilten Inhalt zeitnah zu l¨oschen, sollte die Quelle durch den Urheber entfernt werden. Ebenso sollte in der Schnittstelle durch ein Impressum oder Kontakt Benutzern die M¨oglichkeit einger¨aumt werden Beschwerde einzureichen um ggf. Inhalte manuell zu entfernen. Die im folgenden aufgefuhrten¨ Richtlinien aus [Ulb13] von Dr. Carsten Ulbricht in Bezug auf die Software- Brucke¨ geben einen Uberblick¨ daruber,¨ welche Inhalte ein besonderes hohes Abmahnrisiko darstellen und welche Maßnahmen den teilenden Benutzer schutzen.¨

• Hohes Risiko einer Abmahnung

– Ver¨offentlichung fremder Fotos ohne Zustimmung des Rechteinhabers (auch Vorschaubilder).

– Ver¨offentlichung anderer urheberrechtlich geschutzter¨ Werke ohne Zustimmung.

– Ver¨offentlichung eigener Fotos mit Personen ohne deren Zustimmung.

– Außerung¨ oder Verbreitung rechtswidriger Aussagen – schwierig bei der auto- matischen Ubernahme¨ von Text; eine Filterung auf Schlagworte ist auf keinen Fall gewunscht.¨

• Geringes Risiko einer Abmahnung

– Inhalte von Seiten mit Empfehlungsbuttons teilen – Das explizite Angebot der Funktion kommt einer Zustimmung des Rechteinhabers gleich. Dies gilt nicht grunds¨atzlich fur¨ den Sharing-Knopf in dem Sozialen Netzwerk selbst. Zumal diese Funktion durch die Software-Brucke¨ weiter interpretiert und in einer anderen Darstellung in andere Netze ubertragen¨ wird.

– Beschr¨ankung der Zielgruppe – Die geteilten Nachrichten auf den eigenen Bekannten-, Freundes- und Followerkreis zu beschr¨anken, verhindert zwar keine Urheberrechtsverletzungen, mindert aber rein faktisch das Entdeckungsrisiko erheblich.

• Kein Risiko

– Beachtung des Zitatrechts (§51 Urheberrechtsgesetz) – Das Zitatrecht hat bei der automatischen Verteilung von Kommentaren und Inhalten in und aus ande- ren Netzen keine besondere Relevanz, da die Bedingungen hierfur¨ in der Regel nicht erfullt¨ werden.

– L¨oschen fremder Inhalte nach Kenntnisnahme von einem Verst¨oßen – Nach eindeutiger Rechtsprechung k¨onnen Betreiber von Social-Media-Pr¨asenzen fur¨

Seite 39 Kapitel 2 Stand der Wissenschaft (State of Social Media)

Rechtsverletzungen durch fremde Inhalte nur verantwortlich gemacht werden, wenn sie nach nachweislicher Kenntnisnahme diesen nicht unverzuglich¨ entfer- nen. Eine Konfiguration in einer Brucke¨ w¨are sinnvoll, die es erlaubt, Aktionen bestimmter Benutzer nicht zu synchronisieren.

Neben der Urheberrecht und Sharing-Problematik wollen die Betreiber die Kontrolle daruber¨ behalten, wer woruber¨ welche Informationen erh¨alt. Einer Nutzung von Webseiten- Robotern, die sich verhalten wie Anwender und Inhalte kopieren bzw. aufbereiten, ist in vielen etablierten Netzwerken untersagt. Die Betreiber wollen, dass die Anwendungen die kontrollierten und protokollierenden h¨aufig beschr¨ankten Schnittstellen nutzen. Twitter schreibt dazu in den AGBs [Twi14a]:

Sofern uber¨ die Dienste, gem¨aß den vorliegenden oder den unter dev.twitter.com ” festgelegten Bedingungen nicht etwas anderes zul¨assig ist, sind Sie verpflich- tet, die Twitter-API zu verwenden, wenn Sie die Inhalte oder Dienste reprodu- zieren, modifizieren, verbreiten, verkaufen, ubertragen,¨ weiterleiten, ¨offentlich anzeigen oder vorfuhren,¨ diese anderweitig verwenden oder hiervon abgeleitete Werke erstellen wollen.“

Weiter ist es nicht im Interesse der Anbieter Daten in andere Netze zu verteilen oder aufzubereiten um etwaige Dienste wie eine Brucken-Software¨ anbieten zu k¨onnen. Zum Beispiel aus den Twitter API-Richtlinien [Twi14b]:

You will not attempt or encourage others to ... redistribute, or syndicate ” access ... Twitter Content to any third party without prior written approval from Twitter.“ Exporting Twitter Content to a datastore as a service or other cloud based ” service ... is not permitted“

Facebook schreib in den Nutzungsbedingungen [Inc14a]:

Besondere Bestimmungen fur¨ Entwickler/Betreiber von Apps und Webseiten: ” ... 9. Wir k¨onnen deinen Zugriff auf Daten einschr¨anken...“

Festzuhalten bleibt, dass der Betrieb einer Software-Brucke,¨ die automatisch alle Inhalte ¨offentlich uber¨ Grenzen der Sozialen Netzwerke hinweg teilt, rechtlich ein hohes Risi- ko einer Urheberrechtsverletzung darstellt. Kein rechtliches Probleme stellt jedoch die Verbreitung und Synchronisation eigener Inhalte zu angebundenen Sozialen Netzwerken und die Konsolidierung von Inhalten externer Quellen zu einem eigenen, nicht ¨offentlich zug¨anglichen Neuigkeiten-Feed (Posteingang) dar. Dennoch impliziert diese Bereitstel- lung, Speicherung und Abfrage uber¨ Beschr¨ankungen von Schnittstellen hinweg h¨aufig

Seite 40 Kapitel 3 Konzeption eine Verletzung der AGBs bzw. TOS der Anbieter von etablierten Sozialen Netzwerken, die sich vorbehalten Accounts und Schnittstellen-Konten zu sperren oder sogar vollst¨andig zu l¨oschen.

3 Konzeption

Dieses Kapitel beschreibt die Konzeption eines Multiplexer, der mehrere etablierte So- ziale Netzwerke an die dezentralisierte Social-Software pump.io anbindet. Die Konzeption stellt die theoretische Implementierung und Architektur vor, die mit dem darauffolgenden Machbarkeitsnachweis (engl. Proof of Concept) praktisch untersucht wird. Die Verwen- dung eines offenen und einheitlichen Standards (einer Brucke)¨ zwischen mehreren Netz- werken bietet die M¨oglichkeit, je nach Bedarf, neue Dienste anzubinden oder bestehende Dienste zu entfernen. Die Steuerung der Software kann durch den gleichen Client auf dem selben Endger¨at erfolgen. Die zu entwickelnde Schnittstelle erfullt¨ zwei Hauptaufga- ben: Zum einen werden Nachrichten aus angebundenen etablierten Sozialen Netzwerken geladen, aufbereitet und zugestellt (FromESN). Zum anderen werden Nachrichten zu angebundenen etablierten Sozialen Netzwerken verteilt (ToESN). Hierfur¨ definiert und koordiniert die Schnittstelle den Austausch aller ben¨otigten Informationen, speichert rele- vante Identifizierer und h¨alt daruber¨ hinaus wiederverwendbare Daten uber¨ Benutzer und Beziehungen im Cache vor. Fur¨ die Konzeption wird die Annahme getroffen, dass die eta- blierten Sozialen Netzwerke Facebook, Twitter und Googleplus uber¨ die pump.io-Brucke¨ miteinander agieren. Die Funktionen dieser besonders aus europ¨aischer Sicht erfolgreichen Sozialen Netzwerke unterscheiden sich in Details (vgl. Abbildung8), bieten als allgemei- nes Soziales Netzwerk aber eine sehr ¨ahnliche Funktionspalette an. Die Brucke¨ ubernimmt¨ nicht nur die primitive Vermittlung von Aktivit¨aten, sondern steuert alle zukunftig¨ auf dem beinhalteten Objekt angewandten Aktionen und Ereignisse. Die Konzeption zeigt, wie beispielsweise eine Favorisierung oder ein Kommentar eines nach pump.io verteil- ten Beitrags wieder in dem ursprunglichen¨ Sozialen Netzwerk ubernommen¨ wird. Weiter tauchen Kommentare von Nutzern aus dem einen Sozialen Netzwerk in einem anderen angeschlossenen Netzwerk auf und sind dort fur¨ externe Sichtbar. Die Konzeption geht von unbeschr¨ankten Schnittstellen aus, die alle ben¨otigten Funktionen erlauben. Es aber keine als die vorhandenen Funktionen innerhalb der Netze selbst ben¨otigt.

3.1 Die Nachricht im Sozialen Netzwerk

Das zentrale Grundelement der Sozialen Netzwerke, das durch die Brucke¨ uber¨ Grenzen hinweg getauscht wird, ist die Nachricht, die an eine Person, Personen-Gruppe oder die

Seite 41 Kapitel 3 Konzeption

Offentlichkeit¨ gerichtet ist. Die Komponente bzw. zugeh¨orige Aktivit¨at selbst kann uber¨ konkreten Informationstext hinaus, digitalen Inhalt wie Bilder und Videos beinhalten. Eine typische Nachricht aus einem Sozialen Netzwerk besteht aus den im Folgenden auf- gefuhrten¨ Inhalten und Metainformationen, die fur¨ den gemeinsamen Austausch festgelegt sind (vgl. Abbildung 12 auf Seite 44). Die Abweichungen in Details der Sozialen Netze un- tereinander wird dabei nicht berucksichtigt¨ und spielt fur¨ die Synthese der Netze vorerst keine Rolle.

Empf¨anger: Der Empf¨anger an den eine Nachricht gerichtet ist. Das k¨onnen Person (als Direktnachricht), Gruppe (z.B. durch Community-Zugeh¨origkeit), Personen- kreise, abonnierte Tags (z.B. Hashtags) oder die Offentlich¨ sein. Nachrichten an die Offentlichkeit¨ k¨onnen in den meistens Sozialen Netzwerken von Personen ohne Anmeldung oder Personen zu denen eine Benutzer in keiner Beziehung steht ab- gerufen werden. Uber¨ eine bestimmte Seite k¨onnen ublicherweise¨ automatisch alle Nachrichten abgerufen werden, die an eine angemeldete Person innerhalb des Sozia- len Netzwerks gerichtet sind und diese betreffen. In vielen F¨allen ist es wichtig zu wissen, in welchem Kontext eine Nachricht zugestellt wurde. Eine Mitteilung kann einen Empf¨anger beispielsweise direkt (in einem Posteingang), in einen fur¨ andere einsehbaren Ort wie ein G¨astebuch bzw. Pinnwand oder uber¨ einen Neuigkeiten-Feed (Indirekte-Nachricht) erreichen. Eine Nachricht die direkt an eine Person gerichtet ist, wird anders wahrgenommen und hat in der Regel auch einen anderen Stellen- wert als eine Nachricht, die an eine Vielzahl von Personen gesendet wurde. Zudem verarbeiten viele Clients direkte Nachrichten anders als indirekte und verknupfen¨ beispielsweise eine Notifikation. Der Empf¨anger muss erkennen k¨onnen, ob andere Personen oder Gruppen an einer Konversation beteiligt sind. Ein Benutzer braucht diesen Zusammenhang um erkennen zu k¨onnen, wie die vier Seiten einer Nachricht zu deuten sind (nach dem Kommunikationsquadrat von Friedemann Schulz von Thun [Thu14] vgl. Abbildung 11 auf Seite 44). Jede Nachricht enth¨alt Botschaften auf vier verschiedenen Ebenen:

– Die Sachinformation: Woruber¨ wird Informiert. Der reine sachliche Inhalt der Nachricht.

– Die Selbstkundgabe: Was der Sender bzw. Absender von sich selbst preisgibt und von sich selbst zu erkennen gibt.

– Den Beziehungshinweis: Wie der Sender zu dem Empf¨anger steht.

– Der Apell: Was der Sender bei dem Empf¨anger erreichen will.

Weiter muss der Empf¨anger dadurch deuten k¨onnen, welche Auswirkungen und

Seite 42 Kapitel 3 Konzeption

Reichweite eine Antwort auf eine Mittelung hat. Dies betrifft beispielsweise die gew¨ahlte Ausdrucksweise, den Inhalt und Sorgfalt mit der die Antwort erstellt wird.

Absender/Sender: Die Instanz, die eine Nachricht mit einer beinhalteten Informatio- nen an den Empf¨anger ubermittelt,¨ welche nicht zwangsl¨aufig eine reale Person sein muss. Ein Absender kann ebenso durch ein Programm bzw. Roboter Bot re- pr¨asentiert werden, der beispielsweise Nachrichten aus anderen Quellen aufbereitet und weiter verteilt. H¨aufig ist der Absender der Nachricht gleichzeitig der Verfasser des Inhalts. Wird durch den Absender Inhalt anderer Nutzer weiter geteilt wird dies h¨aufig mit einer optionalen Bemerkung versehen und in besonderer Weise gekenn- zeichnet.

Metainformationen: Metainformationen sind Daten, die Informationen uber¨ andere Daten enthalten, aber nicht die Daten selbst sind. Vereinfacht gesagt sind Meta- Daten Daten uber¨ Daten. Uhrzeit, Datum, Ort, Server, verwendeter Client usw. sind Beispiele fur¨ solche Meta-Daten. Metainformationen sind fur¨ den Kontext und Ursprung des Inhalts wichtig und geben Aufschluss uber¨ die Situation unter der ein Inhalt verfasst wurde.

Inhalt (Content): Der eigentliche digitale Inhalt bzw. die enthaltene Information der Nachricht. In den meisten Sozialen Netzwerken besteht der Inhalt aus Text, Bild oder Video. Dieser Inhalt wird erfahrungsgem¨aß durch den Empf¨anger (z.B. einer mobilen Anwendung) je nach Datentyp speziell aufbereitet.

Zusatzfunktion Like: Ein Like (engl. gefallen) oder Favorisierung ist eine Zusatzfunk- tion die von vielen Sozialen Netzwerken unterstutzt¨ wird. Durch ein Like k¨onnen Empf¨anger zum Ausdruck bringen, dass ihnen eine Nachricht gef¨allt oder sie die Aussage der Nachricht unterstutzen.¨

Zusatzfunktion Share: Die Share-Funktionalit¨at (engl. teilen) wird in vielen Sozialen Netzwerken angeboten. Mit diesem sogenannte Social Sharing wird eine Nachricht oder Ressource des eigenen oder eines entfernten Benutzers aufgegriffen und an Freunde, Teilnehmer einer Gruppe oder Fremde weiter verteilt. H¨aufig besteht dabei die M¨oglichkeit einen Kommentar oder eine Bemerkung zu einem Share zu verfas- sen. Viele Webseiten bieten die M¨oglichkeit Inhalte direkt aufzugreifen und diese in etablierten Netzwerken zu verteilen. Durch ein Share eines Bekannten k¨onnen Nut- zer auf andere Nutzer oder Inhalte aufmerksam gemacht werden. Der Austausch kann dazu genutzt werden, die Bindung zwischen Personen zu erh¨ohen.

Zusatzfunktion Reply: Mit der Reply-Funktion (engl. antworten) bzw. Kommentar- Funktion k¨onnen Empf¨anger oder der Autor selbst neue Nachrichten in Bezug auf

Seite 43 Kapitel 3 Konzeption

eine vorangegangene Aktivit¨at erstellen. Die Kommentare auf Nachrichten umfas- sen meist nicht denselben Funktionsumfang wie vollst¨andig neue Nachrichten (vgl. Abbildung8 z.B. Kommentar mit Bild). Kommentare gleichen einem Diskussions- thread und sind eine hierarchische Abfolge von neuen Postings. Die Sichtbarkeiten von Kommentaren sind sehr unterschiedlich. In der Regel werden die Sichtbarkei- ten der originalen Nachricht auf ein Kommentar vererbt, wobei alle Empf¨anger alle Kommentare sehen k¨onnen.

Direkte Antwort: Im Unterschied zu Kommentaren k¨onnen Benutzer durch eine direk- te Antwort unter Ausschluss der Offentlichkeit¨ auf einen Beitrag eines Benutzers antworten. Diese pers¨onliche Nachricht (kurz PN) wir bei diskreteren Themen wie z.B. Handy verloren – bitte teilt mir eure Handynummer mit genutzt.

Abbildung 11: Das Kommunikationsquadrat von Friedemann Schulz von Thun. Jede Außerungen¨ enth¨alt vier Botschaften [Gem14][Thu14].

Abbildung 12: Schematischer Aufbau einer Nachricht aus Sozialen Netzwerken; eindeuti- ger Identifizierer, Zeit, Absender, Empf¨anger, Inhalt, Favorisierung, Kom- mentare und Verteilung

Fur¨ die saubere Aufbereitung und Verteilung von Nachrichten uber¨ die Grenzen der eta- blierten Netzwerke nach Konzept werden die folgenden Informationen ben¨otigt:

• Profilname: Der Benutzername bzw. vollst¨andige Name des Absenders in dem angebundenen Sozialen Netzwerk.

Seite 44 Kapitel 3 Konzeption

• Profilbild: HTTP-Link auf das Profilbild des Absenders (fur¨ die Anzeige mussen¨ die Bilder skaliert werden). Steht kein Profilbild zur Verfugung¨ wird ein Platzhalter (Default) gesetzt.

• Profil-Link: HTTP-Link auf das Profil des Absenders in dem angebundenen So- zialen Netzwerk.

• Zeitpunkt: Die Uhrzeit bzw. Zeitpunkt an dem die Quell-Nachricht erstellt wurde. Durch die Verarbeitung in der Brucke¨ k¨onnen sich die Zeitpunkte der Erstellung und tats¨achlichen Sichtbarkeit im entfernten Client unterscheiden. Dies ist unter anderem fur¨ Beitr¨age uber¨ Zeitzonen hinweg relevant.

• Inhalt: Kopie oder Referenz des Inhalts der Nachricht. Hier wird auf die Textstel- le 3.1 verwiesen, die sich auf der Seite 43 befindet.

• Empf¨anger: Empf¨anger (z.B. Gruppe Kegelclub) und Quellnetzwerk (z.B. Face- book) der Nachricht. Wie und woher wurde die Nachricht an den Benutzer her- angetragen? Hier wird auf die Textstelle 3.1 verwiesen, die sich auf der Seite 42 befindet.

• Link auf Beitrag im Etabliertes Soziales Netzwerk (ESN): Fur¨ sp¨atere Ak- tionen (L¨oschung, Anderung,¨ Favorisierung, Kommentare usw.) die auf die Nach- richt im etablierten Netzwerk oder in pump.io angewandt werden, ist der eindeutige Identifizierer und dessen Beziehung zu speichern. Der Link im Beitrag ist fur¨ Nut- zer wichtig, die den Ursprung der Nachricht nachvollziehen m¨ochten oder spezielle Funktionen innerhalb des etablierten Sozialen Netzwerks nutzen wollen, die nicht in der Brucke¨ abgebildet sind.

Fur¨ Kommentare, die zwischen etablierten Sozialen Netzwerken und pump.io ausgetauscht werden die folgende Informationen ben¨otigt:

• Zugeh¨orige Nachricht: Link auf den ESN-Beitrag zu dem der Kommentar erstellt wurde.

• Profilname: Der Benutzername bzw. vollst¨andige Name des Kommentar-Erstellers. Siehe Profilname oben.

• Profilbild: HTTP-Link auf das Profilbild des Kommentar-Erstellers. Gegebenen- falls muss das Bild skaliert werden. Siehe Profilbild oben.

• Profil-Link: HTTP-Link auf das ESN-Profil des Kommentar-Erstellers. Siehe Profil- Link oben.

Seite 45 Kapitel 3 Konzeption

• Zeitpunkt: Die Uhrzeit bzw. Zeitpunkt an dem das Quell-Kommentar erstellt wur- de. Siehe Zeitpunkt oben.

• Inhalt: Kopie oder Referenz des Inhalts des Kommentars.

Aus den ausgetauschten Nachrichten sind HTML-Encodings herauszufiltern. HTTP-Links bleiben erhalten. Fur¨ Favorisierungen von Nachrichten sind weniger Daten notwendig. Al- lerdings sind Favorisierungen externer Nutzer nicht problemlos in andere Netzwerke zu transferieren: Ein Like durch eine angebundene API kann nur einmalig fur¨ den angemel- deten Benutzer durchgefuhrt¨ werden. Stellvertretend fur¨ andere ist keine Favorisierung m¨oglich. Bei Kommentaren ist dies m¨oglich, indem der angemeldete Benutzer beispiels- weise einen Kommentar nach dem Format: Benutzer X aus Netzwerk Y schreibt (HTTP- Link): Hallo Welt!“ verfasst. Bei einem Kommentar, wenn auch etwas kryptisch und auf ” den ersten Blick unverst¨andlich, bleiben so alle ben¨otigten Informationen erhalten. Alter- nativ kann fur¨ ein Like eines externen Benutzers aus einem anderen Sozialen Netzwerks ein Kommentar verfasst werden, indem der angemeldete Brucken-Nutzer¨ beispielsweise schreibt: Benutzer X (HTTP-Link) aus Netzwerk Y gef¨allt das. Die folgenden Daten wer- den fur¨ einen Like des Brucken-Nutzer¨ aus einem ESN ben¨otigt:

• Zugeh¨oige Nachricht: Link auf den favorisierten ESN-Beitrag

• Profilname: Der Benutzername bzw. vollst¨andige Name des Anwenders, der den Beitrag im ESN favorisiert hat.

• Profil-Link: HTTP-Link auf das ESN-Profil des Anwenders, der den Beitrag im ESN favorisiert hat.

3.1.1 Facebook

Abbildung 13 auf Seite 47 zeigt einen typischen Facebook-Post. In dem Post ist ein Bild uber¨ einen Handy-Upload des Benutzers verteilt worden. Darunter befinden sich Kom- mentare inklusive Profilbild und Favorisierungen anderer Nutzer. Der Autor selbst hat ebenfalls die M¨oglichkeit diese Funktionen zu nutzen. Die Kommentare und Favorisierun- gen sind mit einem Zeitstempel versehen. Die Benutzerprofile sind jeweils per klickbaren Link verknupft.¨ Der Autor des Beitrags ist ebenfalls mit Profilbild, klickbaren Link und Datum gekennzeichnet. Die Grundfunktionen Kommentieren, Favorisieren und Teilen sind direkt unter dem Autor und zus¨atzlich im Bild selbst plaziert. An der rechten Seite sind weiter Funktionen und Informationen wie Orte, Sichtbarkeit und Markierungen, mit der Benutzer mit einem Bild verknupft¨ werden k¨onnen, eingebettet. In Facebook k¨onnen die Kommentare anderer Nutzer favorisiert werden.

Seite 46 Kapitel 3 Konzeption

Abbildung 13: Typischer Facebook-Post mit Bild (von einem Upload per Handy) mit Kommentaren

3.1.2 Googleplus

Abbildung 14 auf Seite 48 zeigt einen typischen Googleplus-Post. Der Post wurde in ei- ner gemeinsam genutzten Community Developing with Googleplus abgesetzt und erreicht alle, die dieser Gruppe folgen. Beitr¨age, die an die Community gerichtet werden, k¨onnen an spezielle Themen adressiert sein (in dem gezeigten Beispiel an Discussion (dt. Dis- kussion)). Weiter sind oben rechts im Beitrag Verschlagwortungen verknupft,¨ mit denen verwandte Beitr¨age geladen und angezeigt werden k¨onnen. Darunter befinden sich Kom- mentare inklusive Profilbilder anderer Nutzer. Die Favorisierungen werden direkt unter dem Post gez¨ahlt. In der unteren rechten Ecke des Beitrags werden weitere Profilbilder von Benutzern angezeigt, die Aktivit¨aten zu dem Post vorgenommen haben. Alle Bei- tr¨age sind mit einem Zeitstempel versehen. Der Benutzer hat direkten Zugriff auf die Funktionen: Favorisieren (+1), Kommentieren (Textfeld) und Teilen (Pfeil nach rechts).

Seite 47 Kapitel 3 Konzeption

Abbildung 14: Typischer Googleplus-Post an eine Community (Gruppe) mit Kommenta- ren uber¨ die Web-UI abgerufen

3.1.3 Twitter

Abbildung 15 auf Seite 49 zeigt einen typischen Twitter-Post (Tweet). Der klassische Tweet ist eine ungerichtete, ¨offentliche auf 140 Zeichen beschr¨ankte Kurznachricht. Links werden uber¨ einen Kurz-URL Dienst von Twitter verkurzt¨ oder wie im Beispiel direkt anklickbar im Text angezeigt. Dem angemeldeten Nutzer werden direkt unter dem Beitrag die Funktionen Kommentieren (Antworten), Teilen (Retweet) und Favorisieren angeboten. Die Benutzer sind mit vollst¨andigen Namen und ihren Twitter-Benutzernamen, an den Nachrichten adressierte werden, zu sehen. Unter dem Beitrag werden die Kommentare angezeigt. Alle Beitr¨age und Kommentare sind mit einem Zeitstempel versehen. Da die Mitteilungen an die Offentlichkeit¨ gerichtet sind, wird kein Empf¨anger angezeigt. Einige Benutzer die mit dem Beitrag agiert haben, werden mit einem kleinen Profilbild im unteren rechten Bereich angedeutet. Durch das @-Zeichen k¨onnen andere Benutzer erkennen an wen die Nachricht gerichtet ist. Das @-Zeichen wird im Netzjargon h¨aufig verwendet und findet auch in Sozialen Netzwerken Anwendung, die diese Funktion nicht unterstutzen.¨

Seite 48 Kapitel 3 Konzeption

Abbildung 15: Typischer Tweet einer Tageszeitung mit einem Kommentar der Hashtags enth¨alt

3.1.4 pump.io

Abbildung 16 auf Seite 50 zeigt einen pump.io-Post aus Sicht der beim Server mitgelie- ferten Web-Oberfl¨ache. Die Oberfl¨ache von pump.io ¨ahnelt denen der etablierten Sozialen Netzwerke. Im Fokus steht der Inhalt der Nachricht mit den darunter aufgefuhrten¨ Kom- mentaren anderer Nutzer. Uber¨ den Link im Benutzernamen erf¨ahrt die Person, auf wel- chem Server im pump.io-Netzwerk sich der Benutzer befindet. Ansonsten ist die Integra- tion anderer Server in dem dezentralen Netzwerk v¨ollig transparent. Neben anklickbaren vollst¨andigen Namen, Zeitstempel, Profilbild und Aufz¨ahlungen der Favorisierungen und Verteilungen k¨onnen Kommentare anderer Nutzer favorisiert und wiederum kommentiert werden. Falls die Aufz¨ahlungen fur¨ Kommentare, Favorisierungen und Verteilung einen Schwellwert uberschreiten,¨ werden in der Weboberfl¨ache die ¨alteren Eintr¨age als Zahl konsolidiert und nur die neusten Ereignisse angezeigt.

Seite 49 Kapitel 3 Konzeption

Abbildung 16: pump.io-Post mit Kommentaren von Benutzern auf anderen Instanzen

3.2 Bidirektionale Kommunikation zwischen mehreren Sozialen Netzwerken

Grunds¨atzlich gibt es zwei Szenarien, die bei einer bidirektionalen Kommunikation auf- treten. Nachrichten werden entweder aus pump.io zu etablierten Sozialen Netzwerken hin verteilt oder aus etablierten Sozialen Netzwerken geladen. Dem offiziellen Wiki von pump.io ist die folgende Aussage zur Kommunikation zwischen verschiedenen Sozialen Netzwerken zu entnehmen [al.14b]:

pump.io has to connect and interact with other social networks. Those can ” either provide activity streams or use their own format. When relevant, we have to convert incoming foreign streams into activities before importing them into pump.io, as we have to convert outgoing pump.io activies into relevant format before pushing into foreign network.“

Die Brucke¨ verh¨alt sich ¨ahnlich wie ein Dolmetscher, der verschiedene Soziale Netzwerke versteht und ubersetzten¨ kann. Fur¨ die bidirektionale Kommunikation ist es unumg¨anglich einen Benutzer-Account in dem Ziel-Netzwerk zu besitzen. Das gilt naturlich¨ nicht fur¨ ¨offentlich einsehbare Profile und Meldungen auf denen dann sp¨ater allerdings keine wei- teren Aktionen angewandt werden k¨onnen. Dadurch ist der Nutzer zwar gezwungen die Gesch¨aftsbedingungen der Anbieter zu akzeptieren, kann aber die Nutzung auf ein Mi-

Seite 50 Kapitel 3 Konzeption nimum, n¨amlich das erreichen anderer Menschen, beschr¨anken. Durch die Brucke¨ be- steht die M¨oglichkeit, mit dem etablierten Netzwerk zu agieren und weitestgehend die Sammlung von Daten durch die Betreiber der etablierten Netzwerke zu verhindern. Sit- zungsdaten werden durch die Brucke¨ anonymisiert bzw. verschleiert. Metadaten wie der triangulierter Standpunkt vom Handy, IP-Adressen oder spezielle Daten aus Browser- und Header-Informationen (HTTP-Cookie) der Quelle werden schlichtweg nicht mitgesendet oder stammen vom agierenden Brucken-Server.¨ Damit die Brucke¨ vollst¨andig mit dem an- gebundenen Sozialen Netzwerk arbeiten kann, mussen¨ die folgenden Berechtigungen fur¨ einen registrierten Benutzer zur Verfugung¨ stehen. Die Brucke¨ nutzt dazu entweder die vom Betreiber zur Verfugung¨ gestellten Schnittstellen oder arbeitet als automatisierter Web-Bot, der sich mit denen vom Benutzer hinterlegten Zugangsdaten anmeldet. Be- ziehungen zu anderen Nutzern im jeweiligen angeschlossenen Sozialen Netzwerk k¨onnen ebenfalls uber¨ die Brucke¨ hergestellt werden. Fur¨ besondere Suchen usw. sollten aller- dings die in den Netzwerken integrierten Funktionen uber¨ den zum pump.io-Account zugeh¨origen ESN-Account genutzt werden.

• Neuigkeiten-Feed (Newsfeed) lesen: Die Neuigkeiten- und Nachrichtenstr¨ome, die in der Regel alle (auch indirekte) an die Person gerichteten Nachrichten enthal- ten. H¨aufig werden die Direktnachrichten in diesem Strom nicht mitgesendet. Falls dieser Strom nicht zur Verfugung¨ steht, k¨onnen auch die einzelnen Neuigkeiten jedes Kontakts abgerufen werden, was allerdings wesentlich aufwendiger ist.

• Posteingang lesen: Im Posteingang befinden sich alle Direktnachrichten die an den Benutzer gerichtet sind. Direktnachrichten sind in der Regel nicht ¨offentlich und schließen h¨aufig die Messenger- bzw. Chat-Funktion der Sozialen Netzwerke mit ein. Zus¨atzlich werden bei Nachrichten die direkt an den Benutzer gerichtet sind Notifikationen ausgel¨ost.

• Kontakte und Gruppenzugeh¨origkeiten abfragen: Damit die Brucke¨ die Be- nutzer und Profile in pump.io korrekt anzeigen kann, ist es notwendig Profildetails aller Beziehungen abzufragen. Um Nachrichten aus dem Client gezielt an Empf¨anger in verschiedenen Sozialen Netzwerken verteilen zu k¨onnen, werden die Kontakt- Informationen in der Datenbank persistent gespeichert und dem pump.io-Client zur Verfugung¨ gestellt.

• Neue Nachrichten schreiben/versenden: Damit die Kommunikation zu den etablierten Sozialen Netzwerken hin funktionieren kann, muss die Brucke¨ im Namen des Brucken-Nutzers¨ Nachrichten im Ziel-Netzwerk verfassen und ver¨offentlichen durfen.¨

Seite 51 Kapitel 3 Konzeption

• Nachrichten l¨oschen: Falls Nachrichten oder Kommentare an der Quelle gel¨oscht werden, sollten diese auch in den angebundenen Sozialen Netzwerken gel¨oscht wer- den. Diese Funktion gibt dem Anwender die Sicherheit, f¨alschlicherweise verteilte Inhalte zuruckzunehmen.¨

• Nachricht kommentieren: Fur¨ die vollst¨andige bidirektionale Kommunikation zwischen den Ziel-Netzwerken und pump.io ist es notwendig, dass der Brucken-¨ Nutzer Nachrichten kommentieren kann. Die Kommentieren-Funktion wird daruber¨ hinaus genutzt, Inhalte von Nutzer aus anderen Sozialen Netzwerken in den eta- blierten Sozialen Netzwerk zu ver¨offentlichen (vgl. Abbildung 18 auf Seite 54).

• Nachricht favorisieren: Fur¨ die vollst¨andige bidirektionale Kommunikation zwi- schen den Ziel-Netzwerken und pump.io ist es notwendig, dass der Brucken-Nutzer¨ Nachrichten favorisieren kann.

• Nachricht teilen: Damit die Brucke¨ Inhalte innerhalb eines Sozialen Netzwerkes weiter verteilen kann, ist es notwendig, dass der Brucke-Nutzer¨ die Berechtigung besitzt Nachrichten teilen zu durfen.¨ Diese Funktion spielt fur¨ die Verteilung uber¨ die Grenzen der Netzwerke keine elementare Rolle, da fur¨ das Teilen uber¨ die Grenzen der Sozialen Netzwerke hinweg eigene Mechanismen genutzt werden. Die Nutzung von eingebetteten Nachrichten, die uber¨ HTML/CSS mit Javascript-Bibliotheken oder IFRAMES realisiert sind, wird durch die Berechtigung ebenfalls erm¨oglicht.

• Beziehung herstellen/aufl¨osen: Um beispielsweise Accounts auf Twitter zu fol- gen kann der Brucken-Benutzer¨ Beziehungen zu anderen Benutzern aufbauen und aufl¨osen. Sieht ein Brucken-Nutzer¨ eine interessante, aus einem angeschlossenen Netzwerk stammenden Nachricht von einem externen Konto, kann der Nutzer seinen zugeh¨origen ESN-Account verknupfen¨ um zukunftig¨ Neuigkeiten dieses Nutzers zu abonnieren. Ein Brucken-Nutzer¨ kann externe ESN-Accounts entfernen, zu denen er keine Beziehung mehr aufrecht erhalten will.

Die Brucke¨ selbst h¨alt alle ben¨otigten Daten zum Austausch in einer lokalen Datenbank vor. Die Details der gespeicherten Inhalte und das Datenbankschema werden in dem Kapitel Daten und Inhalt – Referenz oder Kopie auf Seite 81 genauer erl¨autert.

3.2.1 Zu etablierten Sozialen Netzwerken kommunizieren

Zum einen werden Nachrichten zu einem oder mehreren angebundenen etablierten Netz- werk verteilt. Die Quelle ist eine ¨offentliche in pump.io erstellte Aktivit¨at. Der Inhalt der Aktivit¨at selbst kann Informationsinhalte aus anderen angebundenen Sozialen Netz-

Seite 52 Kapitel 3 Konzeption werken oder pump.io-Instanzen beinhalten. Das ist beispielsweise bei geteilten Inhalten der Fall. Die Brucke¨ greift die Inhalte der Nachricht auf und erstellt fur¨ jedes angebun- dene Soziale Netzwerk zum Beispiel uber¨ die Schnittstellen-API eine neue Nachricht im Ziel. Die Software speichert die Identifizierer der Quell- und Ziel-Aktivit¨at, um sp¨ater auf die Ressource zugreifen zu k¨onnen. Wenn eine Aktivit¨at direkt von dem angemeldeten pump.io-Nutzer stammt und in andere Netzwerke verteilt wird, findet dies transparent fur¨ die Empf¨anger im Ziel-Netzwerk statt. Lediglich eine Information uber¨ die genutzte Software wird mitgesendet, die h¨aufig in der Ziel-Aktivit¨at mit angezeigt wird. Der An- wendungsfall, viele Soziale Netzwerke aus einer Quelle zu befullen,¨ ist weit verbreitet und es gibt bereits viele Werkzeuge (sog. Crossposter oder auch Multiposter) die diesen Zweck erfullen.¨ Die Tools werden h¨aufig von Unternehmen und Personen eingesetzt, die ein und dieselbe Nachricht m¨oglichst weit verbreiten wollen. In den verbreiteten L¨osungen wird die Diskussion allerdings auf verschiedene Orte aufgeteilt und dort simultan gefuhrt.¨ Eine Zusammenfuhrung¨ der Ruckmeldungen¨ in umgekehrter Richtung und erneute Verteilung auf die Empf¨anger ist in der Regel nicht umgesetzt. Die Brucke¨ sorgt im n¨achsten Ar- beitsschritt fur¨ einen Ruckfluss¨ der Kommentare aus den verschiedenen Netzwerken und synchronisiert diese zu den anderen Zielen. Da die Brucke¨ naturlich¨ nicht im Namen eines fremden und entfernten Twitter-Nutzer in Facebook kommentieren kann, muss eine alter- native L¨osungsm¨oglichkeit geschaffen werden. In diesem Fall kommentiert der angemeldete Nutzer der Brucke¨ im Namen eines anderen Nutzers mit zus¨atzlichen Metainformationen. Die Abbildung 17 auf Seite 54 zeigt eine in pump.io erstellte Nachricht Hallo Welt“ des ” Nutzers mgebbe. Die Abbildung 18 auf Seite 54 zeigt dieselbe, durch die Brucke¨ verteilte Nachricht in Facebook. Dort taucht der Kommentar des pump.io-Nutzers Klaus wieder auf. Uber¨ den Inhalt hinaus sind das Profil und ein HTTP-Link auf die originale Nachricht verknupft.¨ Durch die zeitversetzte Synchronisation kann nicht gew¨ahrleistet werden, dass alle Kommentare in allen Netzwerken chronologisch gleich angeordnet sind. Ebenso unter- scheidet sich die Tiefe der Funktionsvielfalt fur¨ Kommentare in den etablierten Sozialen Netzwerken. Die Kommentare k¨onnen daher fur¨ jedes angebundene Netzwerk besser oder schlechter im Hinblick auf die Transparenz wirken (vgl. Abbildung 17 und 18).

Seite 53 Kapitel 3 Konzeption

Abbildung 17: pump.io zu pump.io, Facebook, Twitter und Googleplus und Kommentare aus den Netzwerken zuruck¨

Abbildung 18: pump.io Nachricht aus Abbildung 17 im etablierten Sozialen Netzwerk Facebook mit Kommentar im Namen von Benutzer Klaus aus pump.io

Die folgenden Schritte werden bei der Verteilung einer ¨offentlichen Nachricht durchlaufen,

Seite 54 Kapitel 3 Konzeption die von einem Benutzer durch die Brucke¨ an mehrere angebundene Netzwerke verteilt wird.

1. Vorlauf: Eine neue ¨offentliche Aktivit¨at mit zugeh¨origer Nachricht wird von einem an der Brucke¨ registrierten Benutzer uber¨ ein Client in pump.io erstellt.

2. Die Software pruft,¨ getriggert oder nach bestimmten Zeitintervallen, den ¨offentlichen Nachrichtenstrom der registrierten pump.io-Nutzer.

3. Die gefundene neue Nachricht hat in diesem Beispiel keine besonderen Merker (engl. Flags) gesetzt und wird somit in alle angebundenen Netzwerke verteilt.

4. Die Brucke¨ erstellt uber¨ die konfigurierten Schnittstellen eine neue Nachricht (Kopie des Originals) im jedem angebundenen Ziel-Netzwerk und publiziert diese ¨offentlich. Die Software ist gezwungen die Nachricht je nach Ziel in gewisser Weise anzupas- sen (in Twitter sind beispielsweise maximal 140 Zeichen pro Nachricht erlaubt). Nach der Ver¨offentlichung speichert die Brucke¨ alle ben¨otigten Referenzen und Pa- rameter aus Quelle und Ziel in der eigenen Datenbank. Die Nachricht ist danach fur¨ Benutzer in den angebundenen Sozialen Netzwerken sichtbar. Benutzer in den etablierten Sozialen Netzwerken und pump.io haben nun die M¨oglichkeit, weitere Aktionen auf die Nachricht anzuwenden (vgl. Abbildung 19 auf Seite 56). In erster Linie werden die Funktionen Favorisieren und Kommentieren von den verschieden Empf¨angern genutzt. Es ist anzunehmen, dass die Benutzer durch die Verknupfung¨ mit der Schnittstellen-App zu pump.io auf die Brucken-Software¨ und das dezentrale Soziale Netzwerk aufmerksam gemacht werden.

Der Zustand des Systems unmittelbar nach der Ver¨offentlichung und Kommentierung ein- zelner Nutzer in den Sozialen Netzwerken ist der Abbildung 19 auf Seite 56 zu entnehmen. Die Originalnachricht wurde von dem Brucken-Nutzer¨ [email protected] ¨offentlich verteilt. Fur¨ den pump.io Benutzer [email protected] auf einer entfernten Instanz ist die Nachricht 1.0 unmittelbar sichtbar und er kommentiert diese Reply 1. Der Brucken-Nutzer¨ hat in jedem angebundenen etablierten Sozialen Netzwerk einen Schatten“-Account des- ” sen zugeh¨orige Anmeldedaten in einer Datenbank in der Tabelle Benutzer-Mapping ge- speichert sind. Die Nachricht wird durch die Brucke¨ in den angebundenen Netzwerken ver¨offentlicht und die Referenzen in der Tabelle Aktivit¨aten zum ESN gespeichert. Fur¨ die Nachricht 1.0 entsteht so in der Brucke¨ die Verknupfung¨ zu den Nachrichten 1.1 in Facebook, 1.2 in Googleplus und 1.3 in Twitter. Benutzer in den etablierten Sozialen Netz- werken konsumieren die Nachricht. Die Profile maili@facebook und [email protected] geben einen Kommentar ab, haben aber noch keinen Zugriff auf die Kommentare der ande- ren Nutzer. In den n¨achsten Zyklen werden die folgenden Schritte fur¨ die Synchronisation

Seite 55 Kapitel 3 Konzeption

Abbildung 19: Schritt 1 – Synchronisation der Nachrichten in andere Soziale Netzwerke.

Seite 56 Kapitel 3 Konzeption der Kommentare durchlaufen (vgl. Abbildung 20 auf Seite 58):

1. Die Brucke¨ pruft¨ alle vorhandenen und verteilten Kommentare bzw. Antworten aus denen in der Tabelle Kommentare hinterlegten Referenzen auf Gultigkeit¨ und l¨oscht diese gegebenenfalls in den verschiedenen Zielen.

2. Die Brucke¨ l¨adt die in der Tabelle Aktivit¨aten zum ESN und Aktivit¨aten aus ESN gespeicherten Aktivit¨aten und pruft¨ in der Quelle 1.0 in pump.io und den entfernten Nachrichten wie z.B. 1.1 in Facebook, 1.2 in Googleplus und 1.3 in Twitter auf neue Kommentare, Aktionen (z.B. Favorisierungen) und Ereignisse.

3. Sind Kommentare vorhanden werden sie, m¨oglichst chronologisch, im Namen des ESN-Nutzers in dem Stil: Person X aus Netzwerk Y schreibt Z in den angeschlos- senen etablierten Sozialen Netzwerken erstellt. Andersherum werden Kommentare von entfernten ESN-Nutzern in der pump.io-Quellnachricht ver¨offentlicht. Durch die unter eigener Kontrolle stehenden pump.io-Server und offenen API k¨onnen solche Kommentare wesentlich transparenter eingebettet werden. Angepasste Clients oder die Brucken-Software,¨ die sich beispielsweise wie ein eigenst¨andiger pump.io-Server im dezentralen Konstrukt verh¨alt, kann dafur¨ sorgen, eine vollst¨andige Transpa- renz herzustellen, indem die Benutzer aus den etablierten Netzwerken wie normale pump.io-Benutzer behandelt werden. Dadurch, dass die Kommentare der entfernten Nutzer in den angeschlossenen Netzwerken unmittelbar zur Verfugung¨ stehen und die Synchronisation uber¨ die Schnittstellen Zeit in Anspruch nimmt, ist eine kom- plett zeitlich gleiche Abfolge aller Kommentare in jedem angeschlossenen Netzwerk nicht m¨oglich.

Der Abbildung 20 auf Seite 58 ist der Zustand zu entnehmen, der nach der Verteilung der Kommentare Reply 1, Reply 2 und Reply 3 besteht. Fur¨ alle Teilnehmer ist der In- formationsgehalt der Nachricht und Kommentare gleich. Die etablierten Netzwerke und pump.io sind verbunden. Der Benutzer [email protected] ist nun in der Lage mit dem Benutzer [email protected] uber¨ die Brucke¨ zu agieren. Der Brucken-Nutzer¨ mgeb- [email protected] kann in diesem Beispiel mit seinem pump.io-Client drei verschiedene angeschlossene Soziale Netzwerke steuern.

Dem Benutzer der Brucke¨ wird die Option einger¨aumt, selbst zu entscheiden ob und in welche Kan¨ale eine ¨offentliche Nachricht verteilt wird. Grunds¨atzlich ist es interessant und im Interesse des Autors ein m¨oglichst großes Publikum mit einer ¨offentlichen Mitteilung zu erreichen. Dennoch gibt es den Anwendungsfall, indem ein Nutzer ein Soziales Netzwerk als Ziel ausschließen m¨ochte. Ein gutes Beispiel ist die Anbindung des Business-Netzwerks Xing. Da in Xing vornehmlich berufliche Korrespondenz abgewickelt wird, empfiehlt es

Seite 57 Kapitel 3 Konzeption

Abbildung 20: Schritt 2 – Synchronisation aller neuen Kommentare in andere Soziale Netzwerke und zuruck¨

Seite 58 Kapitel 3 Konzeption sich unter Umst¨anden nicht, bestimmte private oder politische Inhalte zu verteilen (selbst wenn die Inhalte in anderen Netzwerken ¨offentlich zu Verfugung¨ stehen). Die Software lernt die Kontakte und Referenz auf Einzelpersonen und Gruppen eines Brucke-Benutzer¨ kennen und ist somit in der Lage Nachrichten direkt zu adressieren. Dazu werden un- ter anderem neue Gruppen erstellt, die Einzelgruppen aus angebundenen Netzwerken zusammenfassen. Das ist insbesondere fur¨ Nachrichten wichtig, die nicht ¨offentlich aber zum Beispiel an alle Freunde gerichtet sind. Dadurch, dass die Brucke¨ in der Tabelle Beziehungen und Benutzer die Referenzen auf Konten in den angebundenen etablierten Sozialen Netzwerken speichert, ist der Brucken-Nutzer¨ uber¨ den von ihm genutzten Cli- ent in der Lage, Nachrichten direkt an entfernte Personen zu senden. Die Abbildung 21 auf Seite 59 zeigt beispielhaft, wie ein Brucken-Nutzer¨ aus pump.io uber¨ den Web-Client eine Nachricht an einen lokalen Benutzer, einen Benutzer in Facebook und einen Benutzer in Googleplus verschickt. Bei der Synchronisation der Kommentare ist die Privatsph¨are- Einstellungen der Nutzer zu respektieren. Sind Nachrichten oder Kommentare an einen Personenkreis gerichtet und nicht fur¨ die Offentlichkeit¨ bestimmt, sollten diese nicht an andere Personenkreise oder die Offentlichkeit¨ weiter verteilt werden k¨onnen. Ebenso sorgt die Brucke¨ dafur,¨ dass ein gel¨oschter Kommentar an der Quelle, ebenso zeitnah in ange- bundenen Netzwerken entfernt wird. Diese Funktion gibt Anwendern die Sicherheit, selbst erstellte Inhalte zu kontrollieren und gegebenenfalls l¨oschen zu k¨onnen.

Abbildung 21: Eine Nachricht kann uber¨ die Brucke¨ an Ziele und Personen in verschiedene Netzwerke verschickt werden

Seite 59 Kapitel 3 Konzeption

3.2.2 Von etablierten Sozialen Netzwerken zu pump.io kommunizieren

Zum anderen werden Nachrichten aus einzelnen angebundenen etablierten Sozialen Netz- werken geladen und uber¨ die Brucke¨ zu pump.io verteilt. Eine grundlegende und am h¨aufigsten genutzte Funktion in Sozialen Netzwerken ist das Konsumieren von Inhalten anderer Nutzer. Laut einer Studie aus 2010 verh¨alt sich der gr¨oßere Teil (ca. 55%) nach eigenen Angaben vorwiegend passiv bzw. beobachtend in Sozialen Netzwerken [Gmb10]. Spezielle Endger¨ate sind extra dazu ausgelegt Inhalte aus Social Media ausschließlich lesend zu laden. Der Chromecast von Google l¨adt beispielsweise Inhalte aus der Video- Plattform YouTube auf ein HDMI-Anzeigeger¨at. Uber¨ die mobile Fernsteuerung bzw. Webseiten oder Desktop-Anwendung kann sp¨ater mit dem Inhalt agiert werden. Eine Nutzung ohne angemeldeten Google-Account ist erst gar nicht m¨oglich.

Nachrichten und Aktivit¨aten, die durch den Benutzer aus dem angebundenen etablier- ten Sozialen Netzwerken an pump.io verteilt werden, habe grunds¨atzlich den jeweiligen Brucken-Benutzer¨ als Empf¨anger. Da die Nachrichten fur¨ das Profil im etablierten Netz- werk uber¨ die Schnittstelle sichtbar sind, gilt der Brucken-Benutzer¨ als berechtigt die Nachricht zu empfangen. Die Nachrichten werden allerdings nicht, falls ¨offentlich, auto- matisch fur¨ andere pump.io-Benutzer sichtbar gemacht oder automatisch weiter geteilt. Das wurde¨ den Eindruck erwecken, bestimmte Inhalte wurden¨ mit Absicht geteilt worden sein (ob durch die Brucke¨ oder den Benutzer selbst). Dazu kommt, dass entweder nur abonnierte oder alle Inhalte eines angeschlossenen etablierten Netzwerks ver¨offentlicht wurden,¨ was zu einer zu große Datenbelastung auf den pump.io-Kan¨alen fuhren¨ wurde.¨ Bewusst geteilte und gezielt adressierte Nachrichten wurden¨ in dem st¨andigen Strom von Nachrichten untergehen. Zus¨atzlich ist zu beachten, dass pro weiterem angeschlossenen Netzwerk, je nach Anzahl von Freunden, Following und abonnierten Inhalten die Anzahl der ubertragenen¨ Nachrichten stark zunimmt und bei schlechter Aufbereitung im Client die Ubersicht¨ verloren geht. Allein die Tageszeitung NOZ (Neue Osnabrucker¨ Zeitung) twittert im Schnitt 20-30 Nachrichten an einem Wochentag. Unter der Betrachtung einiger weiterer Twitter-Nutzer aus der Medienbranche und den Neuigkeiten-Feed eines aktiven Facebook-Nutzers mit ca. 200 - 300 Beziehungen, sind 150 vermittelten Nachrichten pro Tag schnell erreicht. Diese Nachrichten sind haupts¨achlich indirekt an den Benutzer ge- richtet, interessieren den Benutzer aber prinzipiell und mussen¨ daher angezeigt werden. Eine Filterung und Sortierung in der Brucken-Software,¨ wie in dem Kapitel Filterung des zusammengefuhrten¨ Streams auf Seite 83 genauer ausgefuhrt,¨ ist fur¨ die hohe Anzahl an Beitr¨agen unumg¨anglich. Die folgenden Schritte werden beim Laden von Nachrichten aus etablierten Netzwerken zu pump.io durchlaufen:

Seite 60 Kapitel 3 Konzeption

1. Die Brucke¨ pruft¨ die vorhanden synchronisierten Nachrichten aus der Tabelle Ak- tivit¨aten aus ESN auf Gultigkeit¨ und l¨oscht diese ggf. in pump.io. W¨ahrend des oben erw¨ahnten zweiten Schrittes (vgl. Abbildung 20) werden fur¨ diese Nachrichten die Aktionen aus pump.io in den etablierten Sozialen Netzwerk durchgefuhrt¨ und beispielsweise die Kommentare des Brucken-Nutzers¨ erstellt. Kommentare von ande- ren Nutzern zu den originalen Nachricht in den abgebundenen Sozialen Netzwerken werden, nur fur¨ den Empf¨anger sichtbar, zu pump.io vermittelt.

2. Die Software pruft¨ uber¨ die Schnittstelle fur¨ jeden ESN-Nutzers den Posteingang und Neuigkeiten-Feed (falls nicht vorhanden werden die Postausg¨ange aller Konten abgefragt zu denen der ESN-Nutzer in einer Beziehung steht). Neue Nachrichten, die noch nicht in der Tabelle Aktivit¨aten aus ESN vorhanden sind, werden als neue Aktivit¨aten in pump.io erstellt und an den jeweiligen Benutzer aus der Tabelle Benutzer Mapping adressiert.

3. Der Brucken-Nutzer¨ bekommt die Nachrichten gekennzeichnet aber transparent in seinem von ihm genutzten Client angezeigt und kann wie gewohnt alle Aktionen darauf anwenden.

Der Abbildung 22 auf Seite 63 ist der Zustand des Systems zu entnehmen, der nach einer beispielhaften Synchronisation von drei Nachrichten aus angebundenen Netzwerken besteht. An den jeweiligen ESN-Benutzer adressiert wurden:

• Nachricht 1.0 von Facebook-Benutzer [email protected] an die Offentlichkeit.¨ Der Brucken-Nutzer¨ [email protected] empf¨angt diese Nachricht, da er in Fa- cebook mit dem Benutzer [email protected] befreundet ist. Wenn nicht anders konfiguriert werden alle Nachrichten die der Benutzer [email protected] an alle Freunde oder die Offentlichkeit¨ schreibt an den Newsfeed von [email protected] zugestellt (indirekte Nachricht).

• Nachricht 2.0 von Googleplus-Benutzer [email protected] an eine Community- Gruppe. Der Brucken-Nutzer¨ [email protected] empf¨angt diese Nachricht, da er der gleichen Community-Gruppe wie [email protected] angeh¨ort. Die beiden Benutzer mussen¨ sich nicht zwangsl¨aufig kennen. Durch die Zugeh¨origkeit in der Community werden die Neuigkeiten von der Brucke¨ uber¨ die Schnittstelle geladen.

• Nachricht 3.0 von Benutzer [email protected] als Direktnachricht an den ESN- Nutzer [email protected]. Die Nachricht ist nicht ¨offentlich und nur uber¨ den Posteingang des ESN-Nutzer [email protected] abrufbar. Andere Nutzer wie z.B. [email protected] haben kein Zugriff auf die Nachricht und k¨onnen somit auch keine Aktionen darauf anwenden. Direktnachrichten in Twitter werden erst seit Oktober

Seite 61 Kapitel 3 Konzeption

2013 unterstutzt¨ [Eth13].

Die Brucke¨ l¨adt diese Beitr¨age und speichert deren ben¨otigte Daten und Referenzen in der Tabelle Aktivit¨aten aus ESN. Der Abbildung 22 ist zu entnehmen, wie das Kommentar Reply 2 zu der Nachricht 2.1 an die Quell-Nachricht 2.0 publiziert wird. Fur¨ die Be- nutzer [email protected] und [email protected] passiert dies transparent, da der Brucken-Benutzer¨ [email protected] dem ESN-Nutzer [email protected] ent- spricht. Ebenso wird die Favorisierung von Nachricht 1.1 als Facebook-Like zur Nachricht 1.0 ubertragen.¨ Der Brucken-Nutzer¨ hat daruber¨ hinaus die M¨oglichkeit, die an ihn adres- sierten Beitr¨age an andere Benutzer weiter zu teilen oder wiederum in andere etablierte Netzwerke zu ver¨offentlichen.

Seite 62 Kapitel 3 Konzeption

Abbildung 22: Abonnement – Synchronisation aller Neuigkeiten und Nachrichten aus an- gebundenen etablierten Sozialen Netzwerken

Seite 63 Kapitel 3 Konzeption

3.2.3 Eine gemeinsame Sprache

Die Gemeinsamkeit aus den verschiedenen etablierten Sozialen Netzwerken ist die ein- zelne Aktivit¨at mit dem Nachrichtentext als Inhalt. Durch Beschr¨ankungen in einzelnen angebundenen Systemen und verschieden Bezeichnung der Funktionen und Begriffe ist ein gemeinsamer Konsens zu bilden. Die Nachrichten, die aus anderen Netzwerken gela- den werden, k¨onnen durch die Brucken-Software¨ aufbereitet werden und verhalten sich je nach gew¨ahlter Architektur mehr oder weniger transparent. Auf die Darstellung in den entfernten angeschlossenen Sozialen Netzwerken kann kein Einfluss genommen wer- den. Die fur¨ externe Netze gew¨ahlte Darstellung durch den Brucken-Nutzer¨ ist der unten aufgefuhrten¨ Aufz¨ahlung 3.2.3 zu entnehmen. Ebenso wird mit weiter verteilten Inhal- ten verfahren, die im Namen entfernter Nutzer ver¨offentlicht werden. Ein Beispiel hierfur¨ w¨are eine Nachricht, die von Googleplus zu pump.io und weiter zu Twitter geteilt wird. Nachrichten die von einem Brucken-Nutzer¨ im Namen des zugeh¨origen ESN-Nutzers (z.B. [email protected] zu [email protected]) ver¨offentlicht werden, ben¨otigen keine weitere Aufbereitung. Bei den direkten Nachrichten eines Benutzers im Namen von sich selbst, wird lediglich der Nachrichteninhalt ubertragen¨ und gegebenenfalls HTML-Encodings ent- fernt. Liegen Beschr¨ankungen seitens der Nachrichtenl¨ange vor, wie es bei Twitter der Fall ist, wird die Nachricht ab der maximalen Zeichenl¨angen abgeschnitten und mit einer Verlinkung auf die Quelle ver¨offentlicht. Bekannte Datenformate fur¨ Web-, Bilder- und Videos-Links, die zu einer Nachricht geh¨oren, werden uber¨ einfache HTML-Kommandos eingebunden, die von vielen (aber nicht allen) Clients korrekt interpretiert und aufbereitet werden.

• Brucken-Nutzer¨ zu zugeh¨origem ESN-Nutzer:

• Brucken-Nutzer¨ als entfernter fremder Nutzer zum ESN: writes via at :

• Brucken-Nutzer¨ zu zugeh¨origem ESN-Nutzer (beschr¨ankt):

Seite 64 Kapitel 3 Konzeption

(Die Links auf Bilder und Videos werden von angebundenen Netzwerken in der Regel zus¨atzlich interpretiert)

• Brucken-Nutzer¨ als entfernter fremder Nutzer ESN (beschr¨ankt): writes via at :

3.3 Anwendungsf¨alle und Szenarien

Anwendungsf¨alle (engl. use-cases) bundeln¨ die m¨oglichen Szenarien, die bei der Interakti- on mit einem System eintreten k¨onnen, bei dem ein Nutzer versucht ein bestimmtes Ziel zu erreichen. Ein Anwendungsfall-Diagramm (engl. Use-Case-Diagramm) veranschaulicht externes Verhalten eines Systems aus der Sicht des Anwenders (in UML Akteure genannt). Dazu werden die Akteure, Use-Cases und deren Beziehungen abgebildet und in dem Dia- gramm veranschaulicht [JRH+04]. Ein Akteur kann entweder eine Person oder ein System sein. Bei der Software-Brucke,¨ die Nachrichten zwischen pump.io und etablierten Sozialen Netzwerken austauscht, werden die Aktionen der Akteure entweder durch die Person selbst oder automatisch durch einen Bot, der die ben¨otigten Berechtigungen besitzt, event- oder zeitgesteuert durchgefuhrt.¨ Die Abbildung 23 auf Seite 66 zeigt das Use-Case-Diagramm der Software-Brucke.¨ Prinzipiell zeigt das Diagramm die verschiedenen M¨oglichkeiten, die sich einem Brucken-Nutzer¨ bieten. Nach der erfolgreichen Autorisierung am System k¨onnen entweder Nachrichten oder Aktionen aus pump.io an angeschlossene etablierte So- ziale Netzwerke verteilt oder von dort empfangen werden. Je nach Sichtbarkeit und Quelle der Nachricht, ob aus pump.io oder einem angeschlossenem ESN, k¨onnen der Brucken-¨ Nutzer selbst oder andere Akteure Aktionen auf diese Nachricht anwenden. Da es sich bei den Nachrichten innerhalb von pump.io (wenn uber¨ ESN empfangen) und in den angeschlossenen Netzwerken (wenn uber¨ pump.io zugestellt) um Kopien der Originale handelt, werden die Aktionen jeweils durch die Brucken-Software¨ koordiniert und synchro- nisiert. Alle Aktionen werden also durch die Brucke¨ in die jeweils entfernten Netzwerke ubertragen.¨ Die Ursache von Aktion auf Nachrichten ist immer ein Akteur, der nicht von der Software gesteuert wird. Eine geteilte Nachricht (Share) wird wie eine neue Nachricht behandelt, die eine Referenz auf die ursprungliche¨ Nachricht besitzt. Ein m¨oglicher bei- spielhafter Ablauf der Ereignisse Nachricht wird aus ESN geladen und sp¨ater kommentiert w¨are:

Mensch: Entfernter Nutzer erstellt einen Beitrag in einem ESN → Bot: Pruft¨ Neuigkeiten-

Seite 65 Kapitel 3 Konzeption

Feed eines Brucken-Account¨ zugeh¨origen ESN-Nutzers → Bot: Findet neue Nachricht von entfernten Nutzer → Bot: Erstellt zugeh¨orige Nachricht mit gleichem Inhalt in pump.io und stellt sie dem Brucken-Nutzer¨ zu → Mensch: Pump.io-Nutzer empf¨angt Nach- richt und erstellt ein neues Kommentar zu der Nachricht → Bot: Pruft¨ die Nachricht in pump.io und findet neues Kommentar → Bot: Erstellt gleichen Kommentar durch zu- geh¨origen ESN-Nutzer im Ziel-Netzwerk → Mensch: Ursprunglicher¨ Ersteller und andere Empf¨anger sehen den Kommentar im ESN

Abbildung 23: Use-Case-Diagramm der Software-Brucke.¨ Das Digramm zeigt die ben¨otigten Anwendungsf¨alle die das Softwaresystem abbildet.

Die folgenden Anwendererz¨ahlung (engl. User-Storys) formulieren Anforderungen, die durch die Software-Brucke¨ abgedeckt werden.

• Nachricht an ESN (Offentlich)¨ Als Benutzer m¨ochte ich, dass meine in pump.io ver¨offentlichten Nachrichten auto- matisch in meine angeschlossenen (ein oder mehrere) etablierten Sozialen Netzwerke ver¨offentlicht werden. Eine Nachricht die ein Benutzer in pump.io ver¨offentlicht wird automatisch in einem an- geschlossenen etablierten Sozialen Netzwerk ver¨offentlicht.

Seite 66 Kapitel 3 Konzeption

• Nachricht an ESN (Person/Gruppe) Als Benutzer m¨ochte ich, dass ich Nachrichten aus pump.io an Personen oder Grup- pen schreiben kann, die sich in angeschlossenen etablierten Sozialen Netzwerken befinden. Ein Benutzer in pump.io kann eine Nachricht direkt an einen Benutzer im etablierten Sozialen Netzwerk adressieren. Die Brucke¨ stellt die Nachricht uber¨ den ESN-Nutzer zu.

• Nachricht aus ESN Als Brucken-Nutzer¨ will ich Nachrichten, die an meinen Benutzer im etablierten Sozialen Netzwerken gerichtet sind, in pump.io empfangen k¨onnen. Eine Nachricht eines entfernten Nutzer aus einem etablierten Sozialen Netzwerk wird in pump.io angelegt und dem Brucken-Nutzer¨ zugestellt.

• Kommentar zu einer im ESN ver¨offentlichten Nachricht in pump.io Als Brucken-Nutzer¨ will ich, dass Kommentare zu einer Nachricht in pump.io auch in der zugeh¨origen Nachricht im etablierten Netzwerk auftauchen. Ein Brucken-Nutzer¨ erstellt ein neuen Kommentar zu einem bereits im ESN ver¨offentlichten Beitrag. Der Kommentar wird von der Brucke¨ automatisch im ESN ver¨offentlicht.

• Kommentar zu einer aus dem ESN stammenden Nachricht in pump.io Als Brucken-Nutzer¨ m¨ochte ich, dass meine Kommentare die ich in pump.io zu einer aus dem etablierten Netzwerk stammenden Nachricht erstelle auch dort ver¨offentlicht werden. Ein Brucken-Nutzer¨ erstellt einen Kommentar zu einem synchronisierten aus dem ESN stammenden Beitrag. Der Kommentar wird von der Brucke¨ automatisch im ESN ver¨offentlicht.

• Kommentar eines entfernten ESN-Nutzers zu einer aus dem ESN stam- menden Nachricht in pump.io Als Brucken-Nutzer¨ m¨ochte ich, dass Kommentare von anderen Nutzern aus eta- blierten Sozialen Netzwerk in der zugeh¨origen pump.io-Nachricht auftauchen. Die Brucke¨ erstellt in pump.io Kommentare im Namen entfernter ESN-Nutzer, die zu einer aus dem ESN stammenden Nachricht geh¨oren.

• Ein Kommentar eines entfernten ESN-Nutzers zu einem im ESN publi- zierten Beitrags wird in einem weiteren ESN angelegt Als Brucken-Nutzer¨ erwarte ich, dass Kommentare die zu meinem Beitrag in dem etablierten Netzwerk A gemacht wurden auch fur¨ Benutzer in dem etablierten Netz- werk B sichtbar sind. Ein Kommentar zu einem im ESN ver¨offentlichten Beitrag (A) wird zu einem Beitrag (B)

Seite 67 Kapitel 3 Konzeption

in einem anderen angeschlossenem ESN uber¨ den ESN-Benutzer des Brucken-Nutzer¨ im Namen des fremden Nutzers synchronisiert.

• Eine Favorisierung eines Beitrags in pump.io der aus angeschlossenen Netzwerken stammt oder dort hin verteilt wurde Als Brucken-Nutzer¨ will ich, dass Favorisierungen (Likes) zu einer Nachricht in pump.io auch auf der zugeh¨origen Nachricht im etablierten Netzwerk angewandt werden. Ich erwarte nicht, dass die Likes anderer Benutzer in den angeschlossenen Netzwerken auftauchen. Die Favorisierung einer Nachricht in pump.io fuhrt¨ dazu, dass der zugeh¨orige ESN-Benutzer den ESN-Beitrag ebenfalls favorisiert.

• Eine im ESN ver¨offentlichte oder aus dem ESN stammende Nachricht/- Kommentar/Favorisierung wird gel¨oscht Als Brucken-Nutzer¨ erwarte ich, dass Nachrichten und Kommentare zeitnah gel¨oscht werden, wenn sie an der ursprunglichen¨ Quelle gel¨oscht werden. Das gilt fur¨ meine Objekte genau so wie fur¨ Objekte anderer Nutzer. Werden Nachrichten, Kommentare oder Favorisierungen in pump.io gel¨oscht, werden diese auch zeitnah in allen angeschlossenen Netzwerken gel¨oscht. Ebenso werden alle Nachrich- ten, Kommentare oder Favorisierungen zeitnah in pump.io entfernt, wenn sie vom Ersteller im ESN gel¨oscht wurden.

3.3.1 Mehrwert

Die Interaktion und der Austausch von Nachrichten uber¨ Grenzen von Sozialen Netz- werken hinweg, l¨asst neue Mehrwerte wie die oben genannte Filterung und Draufsicht entstehen, die es ohne eine Verknupfung¨ nicht geben wurde.¨ Ebenso stehen dem Anwen- der neue Funktionalit¨aten und Szenarien bereit, die es beispielsweise erlauben Nachrichten zu verteilen und externe Benutzer zu verbinden. Im Folgenden werden beispielhaft einige dieser neuen Mehrwerte aufgezeigt.

Bekanntmachungen automatisch in alle Kan¨ale verteilen

Offentliche¨ Nachrichten k¨onnen aus einer Quelle in alle angeschlossenen etablierten So- zialen Netzwerke verteilt werden. Der Benutzer kann entscheiden ob und in welche Netze verteilt wird und ob im weiteren Verlauf Kommentare zwischen den beteiligten Netz- werken ausgetauscht werden sollen. Durch die Aufbereitung der Nachricht in der Brucke¨

Seite 68 Kapitel 3 Konzeption k¨onnen die Nachrichten auch in Netze mit Beschr¨ankungen wie Twitter verteilt werden. Der Text wird dann, wie ublich,¨ mit einem Link auf die Quelle versehen.

Eine aus dem ESN stammende Nachricht per Knopfdruck (share) in ein anders Soziales Netzwerk verteilen

Nachrichten werden aus dem pump.io-Netzwerk und angeschlossenen etablierten Sozialen Netzwerken geladen und zu ihnen verteilt. Benutzer haben dadurch die M¨oglichkeit einen Beitrag eines Benutzers A im Netzwerk B an alle Benutzer in Netzwerk C zu verteilen. Die Benutzer im Netzwerk C profitieren von dem Inhalt der Nachricht und werden auf Benutzer A und die Brucken-Software¨ aufmerksam. Beispiel: Ein spannender Beitrag aus Googleplus wird uber¨ die Brucke¨ an die Offentlichkeit¨ geteilt. Die Brucke¨ verteilt den Bei- trag mit Informationen uber¨ die Herkunft an pump.io und die angeschlossenen Netzwerke Facebook und Twitter. Ein Freund des Brucken-Benutzers¨ in Facebook sieht den geteilten Beitrag aus Googleplus in seinem Neuigkeiten-Strom.

Benutzer aus unterschiedlichen Sozialen Netzwerken kommunizieren uber¨ Kommentare und Beitr¨age

Die Brucke¨ tauscht Kommentare im Namen der jeweiligen Nutzer uber¨ die Grenzen der Sozialen Netzwerke hinweg aus. Die Benutzer k¨onnen sich dadurch, unabh¨angig davon wo sie sich befinden, untereinander austauschen. Durch den unbeschr¨ankten Austausch k¨onnen neue Beziehungen und ein ganz neuer erweiterter Sozialer Graph entstehen.

Nutzung eines einzigen Clients

Ein Brucken-Nutzer¨ muss nicht fur¨ jedes Soziale Netzwerk einen eigenen Client benutzen oder fur¨ jedes angeschlossene Netzwerk eine eigene Webseite aufrufen. Durch die Zu- sammenfuhrung¨ spart der Anwender Zeit. Durch eine intelligente Filterung k¨onnen die Neuigkeiten-Str¨ome auf Wesentliches reduziert werden oder bei Bedarf alles anzeigen. Weitere Soziale Netzwerke k¨onnen modular hinzugefugt¨ werden.

Schutz vor Zensur und L¨oschung

Nachrichten werden aus den Sozialen Netzwerken geladen und in neue Kan¨ale ubertragen,¨ die nicht unter der Kontrolle des jeweiligen Betreibers stehen. Durch die Verknupfung¨ der

Seite 69 Kapitel 3 Konzeption zentralen Strukturen mit einem dezentral organisierten Netzwerk (das Inhalte kopiert), verteilen sich Mitteilungen, Beitr¨age und Nachrichten unzensiert in verbundene Instan- zen weiter. Die Abbildung 24 auf Seite 70, zeigt wie sich eine ursprungliche¨ Nachricht aus Googleplus uber¨ die Brucke¨ in die etablierten Sozialen Netzwerke Twitter und Face- book verteilt. Uber¨ den pump.io-Account des Brucken-Nutzer¨ wird die Nachricht an alle Benutzer verteilt, die auf externen Instanzen dem Brucken-Nutzer¨ folgen. Diese wieder- um k¨onnen die Nachricht weiter verteilen. Das fuhrt¨ dazu, dass die Nachricht an weitere Benutzer in anderen pump.io-Instanzen verteilt wird.

Abbildung 24: Schutz vor Zensur und Blockierung. Eine Nachricht aus Googleplus wird uber¨ die Brucke¨ an etablierte Netzwerke und viele weiter pump.io- Instanzen verteilt.

3.4 Architektur

Fur¨ die Erstellung einer Software-Brucke¨ die etablierte Soziale Netzwerke und pump.io verbindet, k¨onnen verschiedene Multiplexverfahren angewandt werden. Sie unterscheiden sich in ihrer Architektur, Transparenz und dem Grad ob oder wie der originale Quell- code ver¨andert und angepasst werden muss. Eine Anforderung an das Konzept ist eine geringe und minimalinvasive Manipulation der Schnittstellen und Software um weiterhin interoperabel mit anderen pump.io-Instanzen arbeiten zu k¨onnen und den Dienst ande- ren Instanzen anbieten zu k¨onnen. Die Software-Brucke¨ soll fur¨ das gesamte dezentrale pump.io-Netzwerk und nicht nur fur¨ speziell angepasste Server funktionieren. Dem offizi- ellen Wiki von pump.io ist die folgende Aussage zur m¨oglichen Architektur von Brucken¨ zu entnehmen [al.14b]:

Global idea is to keep bridges outside of pump.io scope so that they can be ”

Seite 70 Kapitel 3 Konzeption

developped as separate projects. Also, there should not be any need to release a new pump.io version just because a foreign service changed something on its API“

In der Konzeption werden verschiedene Architektur-Typen untersucht, die es erm¨oglichen bidirektional Daten zwischen pump.io und einem etablierten Sozialen Netzwerk auszutau- schen. Eine Grundvoraussetzung fur¨ den funktionierenden Austausch zwischen pump.io und anderen Sozialen Netzwerken ist die M¨oglichkeit, Zugangsdaten bzw. Berechtigungs- nachweise (engl. Credentials) wie z.B. OAuth und die Verbindung (engl. Mapping) zwi- schen dem pump.io-Benutzer und ESN-Nutzer in der Software speichern und abbilden zu k¨onnen. An der Brucken-Software¨ angemeldete pump.io-Nutzer k¨onnen die Verbin- dung zu den angebundenen Sozialen Netzwerken herstellen und die entfernten Profile verknupfen.¨ Die Software fur¨ die Synchronisation und Synthese der Netze verh¨alt sich entweder wie ein eigenst¨andiger pump.io-Server oder pump.io-Client, an dem sich Nutzer fur¨ den Brucken-Dienst¨ registrieren. Im Folgenden wird auf zwei grunds¨atzliche Multiplex- verfahren genauer eingegangen. Wie schon erw¨ahnt, werden Aktionen in angebundenen Sozialen Netzwerken grunds¨atzlich im Namen des jeweiligen ESN-Profils des Brucken-¨ Nutzers durchgefuhrt.¨ Die Brucke¨ selbst kummert¨ sich im Back-End um die Abfrage und st¨andige Synchronisation von Aktionen auf bereits ausgetauschte Nachrichten. Die Zeit- intervalle werden fur¨ ¨altere Nachrichten nach und nach gr¨oßer um die Datenmengen und Belastungen der Schnittstellen m¨oglichst gering zu halten. Eine Nachricht im Stream von vor 3 Monaten hat nicht die gleiche Relevanz wie eine Nachricht vom selben Tag.

3.4.1 Proxy-Benutzer – Zustellung uber¨ Stellvertreter

Zu den an der Brucken¨ registrierten Benutzern werden fur¨ jedes angeschlossene etablierte Soziale Netzwerk stellvertretende Benutzer-Accounts angelegt. Die Accounts der Brucken-¨ Software verhalten sich nach außen wie eigenst¨andige pump.io-Benutzer auf einem exter- nen Server, der alle ben¨otigten Endpunkten bereitstellt bzw. simuliert. Alle ben¨otigten Informationen zu einem Benutzer, die der Server bereitstellen muss, sind dem Listing2 auf Seite 73 zu entnehmen. Ein Großteil der Endpunkte kann entweder 1:1 von dem Quell- Benutzer ubernommen¨ werden oder bei externen ins Leere fuhren,¨ da sie fur¨ die Aufbe- reitung im Ziel-System irrelevant sind. Ebenso werden fur¨ jeden ESN-Nutzer, der nicht mit einem pump.io-Konto verknupft¨ ist, Stellvertreter-Accounts angelegt. Der Benutzer Tim ist beispielsweise nur in dem Sozialen Netzwerk Googleplus aktiv. Die Software lernt [email protected] uber¨ die Beziehung des Brucken-Nutzers¨ [email protected] zu seinem zugeh¨origen Googleplus-Account [email protected] kennen und legt einen

Seite 71 Kapitel 3 Konzeption neuen Stellvertreter im System an. Die Brucken-Software¨ pruft¨ diese Stellvertreter re- gelm¨aßig und aktualisiert deren ¨offentliche Eigenschaften gegebenenfalls. Die Stellvertre- ter sind durch ihren Benutzernamen in den jeweiligen zentralen etablierten Sozialen Netz- werken einmalig und stehen ggf. fur¨ andere Brucken-Nutzer¨ zur Verfugung.¨ Die Software kann nun Nachrichten im Namen des Stellvertreter an Benutzer im pump.io-Netzwerk sen- den. Die Stellvertreter externer Benutzer dienen ausschließlich der Repr¨asentation und Darstellung. Die Inhalte, die der Stellvertreter versendet, stammen aus Abfragen der verschiedenen Nachrichten-Str¨ome der ESN-Profile der Brucken-Nutzer,¨ die den einzigen Empf¨anger darstellen (vgl. Abbildung 22 auf Seite 63; Die Kopien der ESN-Nachrichten 1.1, 2.1, 3.1 haben nur den Brucken-Nutzer¨ als Empf¨anger ausgew¨ahlt und sind fur¨ andere Benutzer nicht sichtbar). Das kann bei der Synchronisation von Kommentaren aus dem jeweiligen etablierten Netzwerk unter Umst¨anden zu dem Problem fuhren,¨ dass Stellvertreter keine Berechtigung haben, die Nachricht in Nachhinein zu kommentie- ren. Damit dieser Ablauf nicht gest¨ort wird, muss die Brucke¨ den jeweiligen Stellver- treter nachtr¨aglich als Empf¨anger der Nachricht deklarieren. Ein Vorteil bei der Nut- zung von Stellvertretern ist die M¨oglichkeit, Favorisierungen aus angeschlossenen Netz- werken ubernehmen¨ zu k¨onnen. Dadurch ist es m¨oglich, Nachrichten vollst¨andig in Quelle und Ziel abzubilden. Die ¨offentlichen Nachrichten von Benutzern in etablierten Netzwer- ken k¨onnen durch den Stellvertreter ebenfalls ¨offentlich in pump.io publizieren werden. Das gilt allerdings ausschließlich fur¨ ¨offentliche Nachrichten. Offentliche¨ Nachrichten sind beispielsweise bei Twitter ublicher¨ als bei Facebook und Googleplus, da sich die An- wendungsszenarien unterscheiden. Daruber¨ hinaus entsteht durch den Stellvertreter die M¨oglichkeit, dass sich andere pump.io-Nutzer mit einer Person, die sich nur in einem eta- blierten Netzwerk befindet, verbinden. Werden Nachrichten von Brucken-Nutzern¨ (z.B. [email protected]) an Stellvertreter gesendet, werden sie durch eine simulierten Posteingang uber¨ den zugeh¨origen ESN-Nutzer (z.B. [email protected]) direkt an das jeweilige Ziel zugestellt. Dem Flussdiagramm in Abbildung 33 auf Seite 114 im Anhang ist die Zustellung von Nachrichten uber¨ einen Stellvertreter in vereinfachter Form zu entneh- men. Bei der Verarbeitung durch Proxy-Benutzer kann es fur¨ die vollst¨andige Integration unter Umst¨anden erforderlich sein, kleinere Anpassungen am pump.io-Server vorzuneh- men. Das betrifft haupts¨achlich kleinere Prufmechanismen¨ und die nachtr¨agliche Anpas- sung von entfernten Aktivit¨aten. Grunds¨atzlich verh¨alt sich die Architektur im Back-End wie ein eigenst¨andiger Server der uber¨ die Schnittstellen mit anderen Server im pump.io- Netzwerk kommuniziert. Das Front-End kann durch eine Webseite dargestellt werden, an dem sich potenzielle Brucken-Nutzer¨ uber¨ den bereits vorhandenen Anmeldeprozesse in pump.io autorisieren k¨onnen. Die Benutzer haben nach der Anmeldung die M¨oglichkeit, die Zugangsdaten bzw. Berechtigungsnachweise fur¨ die etablierten Sozialen Netzwerke zu

Seite 72 Kapitel 3 Konzeption

konfigurieren.

Fur¨ die transparente Darstellung der ESN-Nutzer im Client sind die folgenden Merkmale und Eigenschaften relevant:

• id: Eindeutiger Identifizierer des Benutzers. Beispielsweise matze at [email protected]

• displayName: Der angezeigte Name. Beispielsweise Matze ([email protected])

• url: Die Web-URL auf das Profil im etablierten Sozialen Netzwerk.

• fullImage / image: Link auf das ¨offentliche Profilbild des Nutzers. Das Pro- filbild hat bei Anwendern einen hohen Wiedererkennungswert und ist fur¨ die Re- pr¨asentation sehr wichtig.

• activity-inbox: Link auf den Posteingang des Stellvertreter. Die Brucke¨ nimmt die Nachrichten an und verteilt diese zu dem zugeh¨origen Nutzer im angebundenem Sozialen Netzwerk.

1 a c t o r ” : { 2 ”preferredUsername”: ”mgebbe”, 3 ”url”: ”https://io.intevation.de/mgebbe”, 4 ”displayName”: ”Mathias Gebbe”, 5 ”id”: ”acct:[email protected]”, 6 ” l i n k s ” : { 7 ” s e l f ” : { 8 ”href”: ”https://io.intevation.de/api/user/mgebbe/profile” 9 } , 10 ” a c t i v i t y −inbox ” : { 11 ”href”: ”https://io.intevation.de/api/user/mgebbe/inbox” 12 } , 13 ” a c t i v i t y −outbox ” : { 14 ”href”: ”https://io.intevation.de/api/user/mgebbe/feed” 15 } 16 } , 17 ”objectType”: ”person”, 18 ” f o l l o w e r s ” : { 19 ”url”: ”https://io.intevation.de/api/user/mgebbe/followers” 20 } , 21 ” f o l l o w i n g ” : { 22 ”url”: ”https://io.intevation.de/api/user/mgebbe/following” 23 } , 24 ” f a v o r i t e s ” : { 25 ”url”: ”https://io.intevation.de/api/user/mgebbe/favorites” 26 } , 27 ” l i s t s ” : { 28 ”url”: ”https://io.intevation.de/api/user/mgebbe/lists/person” 29 } , 30 ” updated ” : ”2014−03−06T19:39:17Z”, 31 ” pump io ” : { 32 ” f u l l I m a g e ” : { 33 ”url”: ”https://io.intevation.de/uploads/mgebbe/2014/3/6/ onEJA. jpg”, 34 ” width ” : 1392 , 35 ” h e i g h t ” : 1392 36 } 37 } , 38 ” l o c a t i o n ” : { 39 ”objectType”: ”place”, 40 ”displayName”: ”Osnabrueck”

Seite 73 Kapitel 3 Konzeption

41 } , 42 ”summary ” : ”” , 43 ” image ” : { 44 ”url”: ”https://io.intevation.de/uploads/mgebbe/2014/3/6/ onEJA thumb. jpg”, 45 ” width ” : 96 , 46 ” h e i g h t ” : 96 47 } 48 }

Listing 2: Ben¨otigte Accountinformationen zu einem pump.io-Benutzer

3.4.2 Allgemein repr¨asentativer Benutzer in pump.io

Eine andere M¨oglichkeit ist die Erstellung eines repr¨asentativen Benutzers der fur¨ alle oder einzelne etablierte Netzwerke zust¨andig ist. Die Brucke¨ h¨alt die Zugangsdaten dieses Benutzers und ist autorisiert Nachrichten zu verschicken und zu empfangen. Pump.io- Benutzer haben die M¨oglichkeit sich fur¨ diesen Dienst uber¨ eine Webseite, die er Brucken-¨ Server anbietet, zu registrieren. Autorisierte Benutzer k¨onnen nach der Anmeldung ihr vorhandenes pump.io-Konto mit den verschiedenen Konten in etablierten Netzwerken ver- binden. Die Software speichert die Zugeh¨origkeiten und Berechtigungsnachweise in einer lokalen Tabelle. Die Brucke¨ pruft¨ regelm¨aßig die Posteing¨ange und Nachrichtenstr¨ome der angeschlossenen Konten in den etablierten Netzwerken. Werden neue Nachrichten ge- funden werden sie im Namen des repr¨asentativen Benutzers (z.B. twitterbridge) an den jeweiligen Empf¨anger zugestellt. Die Nachricht wird dabei von der Brucken-Software¨ so aufbereitet, dass deren tats¨achlicher Inhalt alle ben¨otigten Metainformationen aus den angebundenen Netzwerken enth¨alt. Die Aufbereitung der Nachricht in HTML verh¨alt sich wie die im Kapitel Eine gemeinsame Sprache auf Seite 64 beschriebenen Darstellung: Brucken-Nutzer¨ als entfernter fremder Nutzer zum ESN. Die Software verh¨alt sich wie ein einfacher Client, der ausschließlich vorhandene API nutzt. Diese Architektur ist per Definition fur¨ jeden pump.io-Server einsetzbar und bedarf keiner besonderen Anpassung. Dem Flussdiagramm in Abbildung 34 auf Seite 115 im Anhang ist die Zustellung von Nachrichten uber¨ einen repr¨asentativen Benutzer in vereinfachter Form zu entnehmen. Dadurch, dass der einzelne Benutzer pro ESN alle Korrespondenz abwickelt, treten kei- ne Berechtigungsprobleme auf. Alle Sichtbarkeiten und Zuordnungen werden durch die Logik der Brucke¨ gesteuert. Die Brucke¨ selbst sieht alle Nachrichten, was unter gewissen Umst¨anden ein h¨oheres Sicherheitsrisiko darstellt. Kommentare k¨onnen ohne Schwierig- keiten an jede zugestellte Nachricht angehangen werden. Direktnachrichten an einzelne Personen in etablierten Sozialen Netzwerken, sind nicht ohne weiteres m¨oglich. Die Cli- enten k¨onnen nur den einzelnen Brucken-Nutzer¨ (z.B. [email protected]), der kein eindeutiges Ziel darstellt, ausw¨ahlen. Die Brucke¨ muss daher eine Adressbuch mit End- punkten vorhalten, die von den verschiedenen Clienten als Empf¨anger abgefragt werden

Seite 74 Kapitel 3 Konzeption k¨onnen. Offentliche¨ Nachrichten von Brucken-Nutzern¨ werden je nach Konfiguration im Namen des jeweiligen ¨offentlich in den angeschlossenen etablierten Netzwerken verteilt. Die Abbildung 25 auf Seite 75 zeigt beispielhaft, wie eine Nachricht aus Twitter durch einen repr¨asentativen Benutzer [email protected] aufbereitet und dargestellt wird.

Abbildung 25: Nachricht aus Twitter die durch den repr¨asentativen Benutzer bridge dar- gestellt wird.

3.5 Daten und Inhalt – Referenz oder Kopie

Die Daten der Software-Brucke¨ die aus den etablierten Sozialen Netzwerken stammen k¨onnen entweder als Kopie oder Referenz vorgehalten werden. Bei einer Referenz wird lediglich ein Verweis auf die Quelle der Information gespeichert, nicht aber die Informati- on selbst. Bei einem Aufruf einer Referenz wird jedes Mal das Original erneut abgefragt. Eine Referenz ¨andert sich also zeitgleich mit der Quelle. Wird die Quelle gel¨oscht oder steht nicht zur Verfugung,¨ ist die Referenz nutzlos und zeigt ins leere. Bei einer Kopie wird die Quelle lokal reproduziert. In EDV-Systemen wird bei lokal vorgehaltenen Kopien von Daten, die einen schnellen Zugriff gew¨ahren sollen, von einem Cache gesprochen. Bei der Kopie handelt es sich um ein identisches Duplikat der digitalen Quelle. Die Kopie

Seite 75 Kapitel 3 Konzeption steht auch dann weiter zur Verfugung,¨ wenn die Quelle nicht vorhanden oder gel¨oscht ist. Da eine Kopie sich bei Anderung¨ nicht selbst¨andig der Quelle anpasst sollte sie re- gelm¨aßig aktualisiert und gepruft¨ werden. Beide Methoden haben Vor- und Nachteile und bestimmte Seiteneffekte die in der folgenden Tabelle3 genauer erl ¨autert werden. Bei der Konsolidierung von mehreren großen etablierten Sozialen Netzwerken spielt Performance und die entstehenden Datenmengen eine wichtige Rolle. Das muss bei der Auswahl der Methoden berucksichtigt¨ werden. Ebenso ist abzuw¨agen, welche weitreichenden Vorteile mit vollst¨andigen Kopien erreicht werden k¨onnen. L¨oschen Betreiber oder Regierungen durch Zensur beispielsweise den Zugang zu bestimmten Beitr¨agen oder kompletten So- zialen Netzwerken kann eine Kopie, die sich in einem dezentralen Netzwerk befindet, ungehindert weiter verbreiten.

Beschreibung Referenz Kopie Profil- Die Referenz zu Profil- Die Kopie der Daten wer- Informationen Informationen ist ein Link auf den alle ben¨otigten Profil- das Profil im ESN selbst. Die Informationen einmalig lokal Daten (Name, Profilbild etc.) vorgehalten und Zeit oder mussen¨ bei jeder Abfrage und Event getriggert aktualisiert. Darstellung uber¨ die Schnitt- Vorteil: Schneller Zugriff stelle neu geladen werden. auf die Daten und sofortige Vorteil: Benutzer-Daten Verfugbarkeit¨ auch bei Mehr- immer aktuell. Grundlegende fachabfrage. Anderung¨ der Profildaten Nachteil: Die Benutzer- fuhrt¨ nicht zu Defekten im Daten sind nicht immer System. Ben¨otigt wenig Spei- aktuell. Andert¨ ein Benutzer cher in der Datenbank. sein Profilbild oder den Na- Nachteil: Sehr langsam men, ist dies nicht unmittelbar bei vielen Abfragen, Enor- in der Brucke¨ sichtbar. Das mer Daten-Overhead und verf¨alscht unter Umst¨anden Belastung der Schnittstellen einen Kontext (z.B. bei ei- ner Nachricht in Bezug auf ein neues Profilbild). Wenn nicht nur Text, sondern auch Bin¨ardaten kopiert werden, ist der Bedarf an Speicherplatz sehr hoch. weiter auf der n¨achsten Seite

Seite 76 Kapitel 3 Konzeption

Tabelle 3 – Fortfuhrung¨ der vorherigen Seite Beschreibung Referenz Kopie Nachrichten Soziale Netzwerke bieten Eine Kopie der Nachricht h¨aufig Funktionen an, um verh¨alt sich ¨ahnlich wie die Ko- Nachrichten direkt zu refe- pie der Profil-Informationen. renzieren. Mit der Funktion Pump.io verfolgt das Grund- soll die M¨oglichkeit geschaffen konzept, Nachrichten im werden, Beitr¨age in exter- dezentralen Netzwerk zu nen Webseiten (z.B. einen kopieren. Der Nachrichten- Blog) einzubinden. Tech- austausch uber¨ Servergrenzen nisch werden dazu IFRAMES hinweg findet in pump.io (eingebettete Frames) oder grunds¨atzlich uber¨ Kopien JavaScript-Bibliotheken der statt – so bleiben Information Anbieter genutzt. Fur¨ die erhalten auch wenn einzelne Betreiber ist die Einbindung Knoten ausfallen. Die Kopie eine M¨oglichkeit die Benutzer enth¨alt den Nachrichtentext. weiter an das Soziale Netzwerk Bilder und Videos werden zu binden. Durch eingebettete gesondert betrachtet. Frames oder quer geladene Bibliotheken beziehen die Betreiber weiterhin Nutzer- und Metainformationen zum Verhalten der Anwender. Der Abbildung 26 auf Seite 81 ist eine so eingebettete Nachricht von Googleplus zu entnehmen. Eine andere M¨oglichkeit ist es, die Nachrichten bei je- der Abfrage erneut von der Schnittstelle anzufordern. Die- ses Vorgehen bringt allerdings die gleichen Vor- und Nach- teile wie das Referenzieren von Profil-Informationen mit sich, f¨allt aber aufgrund der Komplexit¨at von Nachrichten noch drastischer aus. weiter auf der n¨achsten Seite

Seite 77 Kapitel 3 Konzeption

Tabelle 3 – Fortfuhrung¨ der vorherigen Seite Beschreibung Referenz Kopie Vorteil: Die eingebetteten Vorteil: Schneller Zugriff Nachrichten spiegeln den ori- auf die Daten und soforti- ginalen Zustand der Nachricht ge Verfugbarkeit¨ selbst bei wieder. Dem Benutzer stehen Mehrfachabfrage vom gleichen alle bekannten Funktionen System. Schutz vor Zensur zur Verfugung.¨ Die Nachricht und Blockierung durch Dritte. verh¨alt sich so, als ob der Nachteil: Die Nachricht Benutzer sie im Sozialen verbraucht viel Speicher im Netzwerk nutzt. Die Referenz Zielsystem. Daten sind nicht verbraucht kaum Speicher- immer aktuell. Wenn Benutzer platz in der Brucke.¨ Nachrichten im etablierten Nachteil: Die Aktionen auf Netzwerk bearbeiten wird die den eingebetteten Nachrichten Anderung¨ nicht automatisch verhalten sich nicht vollst¨andig in der Kopie ubernommen.¨ transparent. Aktionen werden Falls keine Anderung¨ m¨oglich nicht in das Netzwerk von ist, muss eine Nachricht ggf. pump.io ubertragen¨ (vgl. gel¨oscht und neu publiziert Abbildung 26 – dort sind die werden. Funktionen Kommentieren, Favorisieren usw. in pump.io und in dem eingebetteten Post vorhanden). Um die eingebetteten Nachrichten anzuzeigen und um mit ih- nen interagieren zu k¨onnen, mussen¨ die Personen in dem jeweiligen Sozialen Netzwerk eingeloggt sein. Eine korrekte Nutzung nach Konzept ist mit eingebetteten Nachrichten nicht m¨oglich. weiter auf der n¨achsten Seite

Seite 78 Kapitel 3 Konzeption

Tabelle 3 – Fortfuhrung¨ der vorherigen Seite Beschreibung Referenz Kopie Kommentare Kommentare sind Nachrichten Siehe Referenz (links) (Antworten) die Bezug auf eine vorhergehende Nachricht neh- men. Nachrichten bringen die- selben Vor- und Nachteile wie Profil-Informationen mit sich. Dennoch kann in Erw¨agung gezogen werden, Kommentare anders zu behandeln als Nach- richten, da sie in der Regel einen anderen Stellenwert be- sitzen als die Information der Nachricht selbst. Im Falle einer L¨oschung, nicht Erreichbarkeit oder Zensur w¨aren Kommen- tare nicht abrufbar, die Nach- richt selbst aber schon. weiter auf der n¨achsten Seite

Seite 79 Kapitel 3 Konzeption

Tabelle 3 – Fortfuhrung¨ der vorherigen Seite Beschreibung Referenz Kopie Beziehungen In der Regel reicht es aus, die In der Kopie werden die Beziehungen zwischen dem an- Beziehungen von Brucken-¨ gemeldeten Benutzer und an- Nutzern lokal vorgehalten und deren Profilen in angeschlosse- regelm¨aßig aktualisiert. Die nen Sozialen Netzwerken zu re- Kopie selbst besteht dabei aus ferenzieren bzw. bei Bedarf dy- wenigen Profil-Informationen namisch abzufragen. Die Be- und den Endpunkten im ziehungen sind fur¨ Funktio- angeschlossenem Sozialen nen wichtig, in dem der Be- Netzwerk. nutzer Nachrichten an Per- sonen oder Gruppen inner- halb der angeschlossenen Net- ze schicken m¨ochte oder bei- spielsweise alle Freunde an- gezeigt werden sollen. Steht eine Ziel-Netzwerk nicht zur Verfugung,¨ steht auch der Po- steingang der Beziehung nicht bereit. Bilder und Videos Die Referenz auf Bilder und Die Kopie erm¨oglicht die Videos wird durch HTTP-Link Persistenz und schnelle realisiert. Die bin¨aren Daten Verfugbarkeit¨ der Daten werden in den Nachrichten ein- verbraucht allerdings viel gebunden und von dem Client Speicherplatz auf dem des Anwenders geladen und Brucken-Server.¨ Auch die- ausgewertet. se Daten mussen¨ regelm¨aßig gepruft¨ und gegebenenfalls aktualisiert werden.

Tabelle 3: Vor- und Nachteile bei der Nutzung von Referenzen oder Kopien in der Software-Brucke¨

Als Ziel wird eine Hybridl¨osung geschaffen, die fur¨ den Kontext wichtige Daten und In- formationen der Nachricht auf Text-Basis als Kopie vorh¨alt und diese in immer gr¨oßer

Seite 80 Kapitel 3 Konzeption werdenden Zeitintervallen aktualisiert. Weniger relevante und vor allem bin¨are Daten werden als Referenz gespeichert, da bei der Zusammenfuhrung¨ von mehreren aktiven Be- nutzern in etablierten Netzwerken die Datenmengen zu groß sind. Die Architektur der Brucke¨ spielt bei der M¨oglichkeit Nachrichten vollst¨andig zu referenzieren ebenfalls eine Rolle. Beim referenzieren von Inhalten muss der Brucken-Server¨ anderen pump.io-Servern die Nachrichten dynamisch bereitstellen und eine neue Schnittstelle bieten um interope- rabel zu bleiben. Nachrichten die zu etablierten Netzwerken verteilt werden, lassen sich nur schwierig transparent referenzieren, da die M¨oglichkeiten beispielsweise HTML ein- zubinden in der Regel stark beschr¨ankt sind. Eine einfache M¨oglichkeit beispielsweise in Facebook auf einen Beitrag zu referenzieren w¨are ein Web-Link auf die Quell-Nachricht zu posten. Dadurch geht allerdings die vollst¨andige Integration verloren und Nutzern in ande- ren Sozialen Netzwerken k¨onnten die Nachricht nicht unmittelbar empfangen (2-Schritte n¨otig). Aufgrund der Verfugbarkeit,¨ Datenbelastung, Geschwindigkeit und Schutz vor Zensur und L¨oschung empfiehlt es sich fur¨ die Umsetzung Nachrichten und Kommentare als Kopie abzubilden. Eine Quell-Nachricht hat dadurch jeweils eine zugeh¨orige Nachricht in einem bestimmten etablierten Sozialen Netzwerk. Nachricht X in pump.io ist die Ko- pie von Nachricht Y in Twitter. Nachricht A in Facebook und Nachricht B in Googleplus sind die Kopien der Nachricht C in pump.io; Jede Nachricht ist durch einen eindeutigen Identifizierer im Netzwerk gekennzeichnet.

Abbildung 26: Eingebettete Googleplus-Nachricht in pump.io

Seite 81 Kapitel 3 Konzeption

3.6 Datenschema

Das Datenschema zeigt das gew¨ahlte Datenbankdesign und Struktur der gespeicherten Daten in der Software-Brucke.¨ Die Nachrichten selbst befinden sich in dem angeschlos- senen pump.io-Server der von der Brucke¨ gesteuert wird. Die folgenden Tabellen in der Datenbank werden fur¨ die Realisierung des Konzepts ben¨otigt. Das Schemata ist in Ab- bildung 27 auf Seite 83 als UML-Datenbankdiagramm verbildlicht.

• Benutzer aus pump.io oder ESN (BridgeUser): Benutzer und dessen Infor- mationen (Name, Profilbild, Link etc.) aus pump.io oder aus einem angeschlosse- nen Netzwerken. Das schließt ebenfalls ESN-Benutzer mit ein, die keinen pump.io- Account besitzen (Atomar). Diese Tabelle kennt alle Benutzer die mit der Brucke¨ agieren.

• Benutzer-Mapping zwischen pump.io und ESN-Nutzer (UserMap): Die Verknupfung¨ eines pump.io-Accounts zu den angeschlossenen Sozialen Netzwerken (1:N Beziehung). Die Tabelle gibt Auskunft an welche Benutzer Nachrichten verteilt und von welchen Benutzern Nachrichten empfangen werden. Ein pump.io-Benutzer hat mehrere Accounts im ESN (z.B. pump.io ⇔ twitter, pump.io ⇔ facebook usw.) Ein Account im ESN kann wiederum nur zu einem pump.io-Account gemappt wer- den.

• Aktivit¨aten zum ESN (ToESN): Alle Aktivit¨aten bzw. Nachrichten die von pump.io zu angeschlossenen etablierten Sozialen Netzwerken verteilt werden (1 Quel- le ⇔ N Ziele). Die Nachricht selbst steht nicht in dieser Tabelle – sie wird hier, unabh¨angig von der Architektur, referenziert.

• Aktivit¨aten vom ESN (FromESN): Alle Aktivit¨aten bzw. Nachrichten die von angeschlossenen etablierten Sozialen Netzwerken zu pump.io verteilt werden (1 Quel- le ⇔ N Ziele). Grunds¨atzlich bildet die Brucke¨ eine 1:1 Beziehung ab, da die Nach- richt aus dem ESN zu einem pump.io-Benutzer zugestellt wird. Es ist aber m¨oglich, dass zwei Brucken-Nutzer¨ dieselbe Nachricht empfangen wenn die jeweiligen zu- geh¨origen ESN-Accounts beispielsweise derselben Person in Twitter folgen.

• Beziehungen zwischen den Benutzern (Edge): Bildet die Beziehung zwischen Benutzern in pump.io und Benutzern in entfernten etablierten Sozialen Netzwerken ab. Die Daten sind relevant, falls ein pump.io-Benutzer beispielsweise eine Nachricht an alle Freunde und Follower aber nicht die Offentlichkeit“¨ richten will (N Personen ” ⇔ M Freunde).

• Kommentare (Comments): Kommentare und deren Zugeh¨origkeit zu einer Ak-

Seite 82 Kapitel 3 Konzeption

tivit¨at. In der Tabelle werden alle Kommentare abgebildet, die zu einer pump.io- oder ESN-Nachricht geh¨oren. (1 Nachricht ⇔ N Kommentare)

Abbildung 27: Datenschema der Daten in der Software-Brucke¨

3.7 Filterung des zusammengefuhrten¨ Streams

Aufgrund der großen Datenmengen des zusammengefuhrten¨ Streams ist es unumg¨anglich, Daten zu filtern. Eine Filter bietet noch weiter M¨oglichkeiten die User Experience der Brucken-Nutzer¨ zu verbessern. Bei einem Feed, der sich aus allen Neuigkeiten und Nach- richten aus vielen etablierten Netzwerken zusammensetzt, kann die Ubersicht¨ verloren ge- hen und unter Umst¨anden potenziell interessante oder sogar wichtige Beitr¨age ubersehen¨ werden. Grunds¨atzlich sollte der Anwender die jeweiligen Feeds der einzelnen angeschlos- senen Sozialen Netzwerke schnell und unkompliziert ab- und zuschalten k¨onnen (vgl. Ab- bildung 28). Die aus externen Netzwerken geladenen Aktivit¨aten werden mit einfachen Tags versehen die durch den Client ausgewertet werden.

Seite 83 Kapitel 3 Konzeption

Abbildung 28: Einfache Filter um die Feeds der angeschlossenen etablierten Sozialen Netz- werke ab- oder anzuschalten (im Bild ist der Twitter-Stream ist ausgeschal- tet).

Neben dieser einfachen Filterung der Herkunft k¨onnen Brucken-Nutzer¨ Nachrichten be- stimmter Anwender herausfiltern ohne die jeweilige Beziehung zu der Person aufl¨osen zu mussen¨ (zum Beispiel Beziehungen zu Zwangsfreunden). Nachrichten die durch diese Person direkt oder an bestimmte Gruppen gesendet wurden, werden aber weiterhin zuge- stellt. Ebenso k¨onnen Schlagworte angelegt werden, die Beitr¨age besonders hervorheben (beispielsweise jemand hat einen Namen oder Begriff erw¨ahnt) oder herausfiltern (zum Beispiel nervige Einladungen eine Spiele-App zu benutzen oder tats¨achliche als Empfeh- lung getarnte Werbung). Eine Filter kann beispielsweise Beitr¨age die von bestimmten Personen oder Gruppen stammen, Beitr¨age mit besonders vielen Kommentaren oder Fa- vorisierungen speziell kennzeichnen und hervorheben. Durch eine intelligente Suche kann gezielt der gesamten Inhalt eines aktuellen Streams durchsucht werden. Dadurch wer- den Funktion wie zum Beispiel Hashtags adaptiert und fur¨ pers¨onliche Zwecke erweitert. Ebenso k¨onnen relativ einfach Nachrichten auf ihren Typ gefiltert werden wie zum Bei- spiel zeige nur Nachrichten die ein Bild enthalten. Ahnliche¨ oder gleiche der aufgez¨ahlten Funktionen werden teilweise innerhalb der einzelnen etablierten Sozialen Netzwerke ange- boten, k¨onnen aber nicht durch die Anwender selbst konfiguriert oder erweitert werden. Da die Nachrichten aus den angeschlossenen Netzwerken vollst¨andig aufgegriffen werden und es sich bei pump.io und der verarbeitenden Brucke¨ um Freie Software handelt, sind der Anpassung und Erweiterung der Filter keine Grenzen gesetzt. Zus¨atzlich kann eine Suche als Erweiterung der Filter implementiert werden, die mit regul¨aren oder speziel- len Ausdrucken¨ arbeitet. Die Filterung und Suche die als Datenbasis die konsolidierte Masse aller (aktuellen) Beitr¨age an eine Person nutzt, bietet dem Anwender der Brucken-¨ Software eine noch nicht dagewesene Sichtweise auf einen einzigartig zugeschnittenen und zusammengefassten Strom von Informationen. Eine starke Auspr¨agung der andauernden Indexierung geht dabei naturlich¨ zu Lasten der Performance. Filterung und Suche k¨onnen je nach Komplexit¨at auf großen Datenmenge sehr Rechenintensiv sein. Durch den Einsatz von Programmiersprachen wie JavaScript ist es m¨oglich, einen Teil dieser aufwendigen Arbeiten auf den anzeigenden Client (clientseitig) auszulagern.

Seite 84 Kapitel 3 Konzeption

3.8 Probleme und Grenzen

Bei dem Betrieb und Nutzung der Brucke¨ st¨oßt die Software an bestimmte Grenzen, wobei neben den rechtlichen Aspekten verschiedene Probleme technischer und organisatorischer Natur auftreten.

• Es lassen sich nicht alle Funktionen, die Soziale Netzwerke anbieten mit der kon- zeptionierten Brucke¨ abbilden. Durch die Beschr¨ankung auf das Wesentliche fehlen angebotene Spezial-Funktionen und integrierte Anwendungen die vielen Anwendern wichtig sind. Die etablierten Sozialen Netzwerke behalten ihre Daseinsberechtigung. Da sich die Netzwerke und deren Darstellung und Funktion st¨andig ¨andern, muss die Brucke¨ um ihre Interoperabilit¨at zu bewahren, st¨andig angepasst und erweitert werden.

• Um den dezentralen Ansatz mit den Vorzugen¨ fur¨ den Datenschutz und der Kon- trolle der eigenen Daten nicht zu brechen und um durch die Verknupfung¨ vieler etablierter sozialer Netzwerke pro Benutzer nicht das Problem einer zentralen Sam- melstelle aller Informationen als lohnendes Ziel fur¨ Datendiebstahl durch Hacker darzustellen, sollte jeder Brucken-Nutzer¨ eine eigene zu schutzende¨ autarke Instanz betreiben. Dem Anwender muss klar sein, dass Informationen die zu oder von eta- blierten Sozialen Netzwerken geladen werden nach wie vor aus datenschutztechni- scher Sicht gef¨ahrdet sind und nicht unter eigener Kontrolle stehen, was aber auch nicht das Ziel der Interaktion ist. Ebenso sollten fur¨ die Schnittstellen zu den an- gebundenen Sozialen Netzwerken eigene API-Zug¨ange fur¨ die jeweiligen Instanzen genutzt werden, um bei einer m¨oglichen L¨oschung nicht die Anbindung alle Benut- zer zu gef¨ahrden. Laut Formulierungen in den TOS bzw. AGB der Betreiber ist es oftmals untersagt, Inhalte uber¨ die Grenzen des Netzwerkes zu verteilen, ohne eingebettet Nachrichten zu nutzen (embedded sharing) oder anders als uber¨ die of- fizielle API Informationen zu laden. Zuwiderhandlungen kann eine L¨oschung des Accounts in dem jeweiligen Netzwerk nach sich ziehen. Nicht problematisch bzw. nicht nachweisbar ist jedoch das Laden der eigenen Inhalte aus etablierten Sozialen Netzen und das Verteilen an den eigenen pump.io-Account.

• Die zu verarbeitenden Datenmengen steigen pro weiterem angeschlossenem Netz- werk und ubertragener¨ Nachricht, die regelm¨aßig gepruft¨ werden muss. Dazu muss der Server genugend¨ Bandbreite und Leistung besitzen. H¨aufig sind die API-Zug¨ange zu den etablierten Netzwerken auf eine bestimmte Anzahl oder H¨aufigkeit von An- fragen beschr¨ankt, was fur¨ die Antwortzeiten der Applikation und Verarbeitungs- Intervalle des Systems eine Rolle spielt. Die Verz¨ogerung muss bei der Umsetzung

Seite 85 Kapitel 3 Konzeption

und Nutzung berucksichtigt¨ werden. Der Betrieb eines eigenen Servers stellt fur¨ den Durchschnitts-Anwender ohne technisches Know-how (dt. gewusst wie) ein Problem dar. Eine L¨osung k¨onnte eine fertige Brucken-Installation¨ sein, die auf virtuellen Ser- vern mit einfacher Konfiguration bei bestimmten Anbietern ausgerollt werden kann.

• Die Sichtbarkeiten einzelner Nachrichten von Benutzer sind zu respektieren. Be- nutzer mussen¨ daruber¨ in Kenntnis gesetzt werden, oder sich zumindest im klaren sein, dass die eigene Nachricht weiter verteilt werden kann. Eine private Nachricht an eine Person sollte nicht bedenkenlos fur¨ die Offentlichkeit¨ zug¨anglich weiter ver- teilt werden k¨onnen. Es empfiehlt sich die Erlaubnis des Urhebers einzuholen, bevor Aktionen auf solche Nachrichten angewandt werden. Dem Anwender der Software- Brucke¨ muss das Gefuhl¨ gegeben werden selbst die Kontrolle zu behalten in welchen Kan¨alen was fur¨ Nachrichten in seinem Namen publiziert werden. Eine weitreichende und genaue Konfiguration der Brucke¨ was wann und wo warum passiert ist unbe- dingt notwendig. In der offiziellen Web-UI (Alpha-Version) von pump.io k¨onnen bei- spielsweise keine Kommentare gel¨oscht werden, was annehmen l¨asst, dass Benutzer sich scheuen Kommentare zu ver¨offentlichen, die sie diese danach nicht mehr unter Kontrolle haben. Einige etablierte Netzwerke bieten Privatsph¨are-Einstellungen an, die verhindern, dass Nachrichten uber¨ Schnittstellen von Dritten abgefragt werden k¨onnen. Die Funktion fuhren¨ dazu, dass sich der abgerufene Strom an Neuigkeiten verf¨alscht (uber¨ die API ist schlichtweg nicht alles zu sehen) und der Anwender nun doch gezwungen ist, die Webseite des etablierten Sozialen Netzwerks direkt aufzurufen. Dies l¨asst vermuten, dass dies eher im Sinne der Anbieter getan wird, als im Sinne der Anwender. Die Anbieter binden die Kunden so enger an die eige- ne Plattform und haben dort die M¨oglichkeit zum Beispiel Werbung zu schalten. Ebenso verhalten sich die Schnittstellen restriktiv indem beispielsweise Benutzer- IDs verf¨alscht werden und Funktionen nicht zur Verfugung¨ stehen. Daruber¨ hinaus werden die API-Zug¨ange (sog. Apps) Prufungen¨ durch die Anbieter unterzogen, die sich das Recht vorbehalten, den Zugang jederzeit zu sperren. Eine vollst¨andige Um- setzung des Konzeptes uber¨ die offiziellen Schnittstellen ist daher praktisch nicht m¨oglich. Fur¨ eine vollst¨andige Umsetzung werden Webseiten-Roboter ben¨otigt, die sich fur¨ die Anbieter v¨ollig transparent (als wenn der Anwender selbst vor dem Bildschirm sitzt) verhalten.

Seite 86 Kapitel 4 Implementierung – Proof of Concept

4 Implementierung – Proof of Concept

Die Implementierung der im vorherigen Kapitel ausgefuhrten¨ Konzeption soll den Mach- barkeitsnachweis anhand eines Prototypen, der die Kernfunktionalit¨aten der Brucke¨ be- sitzt, erbringen. Die fur¨ diese Arbeit entwickelte Software soll zeigen, dass der Austausch zwischen pump.io und angeschlossenen etablierten Sozialen Netzwerken uber¨ die vorge- sehenen Schnittstellen nach Konzept funktionieren kann. Durch die Umsetzung, Pro- grammierung und Nutzung werden Erkenntnisse gewonnen, die eine Aussage daruber¨ liefert, ob dezentrale und zentrale Soziale Netzwerke in der Praxis miteinander agieren k¨onnen und wo in welcher Form Beschr¨ankungen auftreten. Die Entwickelte Software der Arbeit tr¨agt den Namen pumpbridge. connecting social networks. Bei der Softwa- re handelt es sich um Freie Software unter der Apache Lizenz 2.0 [Fou14]. Der Namen pumpbridge ist eine Wortsch¨opfung (Neologismus) der aus den W¨ortern pump.io und bridge (dt. Brucke)¨ besteht. Die Software steht zum ¨offentlichen Test unter der Webseite https://pumpbridge.me zur Verfugung.¨ Dieses Kapitel veranschaulicht den Aufbau und die Funktion der Software und kennzeichnet etwaige Probleme.

4.1 Planung

In der Planung ist die Auswahl des technischen Konzepts, Methoden und Werkzeuge fest- gelegt, die den Machbarkeitsnachweis erbringen. Fur¨ die Software pumpbridge in dieser Arbeit ist das Konzept Allgemein repr¨asentativer Benutzer in pump.io“ umgesetzt. Das ” Konzept einen repr¨asentativen Benutzer zu verwenden, der durch einen Robot-Client au- tomatisch ferngesteuert Nachrichten aus den etablierten Netzwerken l¨adt und zu ihnen hin verteilt, verspricht eine einfache und effektive L¨osung. Die Anforderung die Brucke¨ ohne Manipulation am eigentlichen pump.io-Server zu betreiben, um die Operabilit¨at mit anderen Instanzen zu gew¨ahrleisten ist dadurch sicher gegeben. Sicherlich hat das Kon- zept einige Schw¨achen und keine vollst¨andige Transparenz wie beispielsweise das Kon- zept Zustellung uber¨ Stellvertreter“. Die Implementierung l¨asst es aber zu, die Brucke¨ ” mit den wichtigsten Funktionen zu betreiben und sie der Allgemeinheit zur Verfugung¨ zu stellen, wodurch ein unmittelbarer Mehrwert fur¨ das Projekt pump.io ensteht. Die Brucken-Software¨ selbst stellt einen Web-Service bereit, an dem sich Benutzer mit einem beliebigen vorhandenen pump.io-Account uber¨ den im pump.io-Netzwerk bekannten Re- mote login anmelden k¨onnen. Nach der Anmeldung kann der Benutzer Zugangsdaten fur¨ die angeschlossenen etablierten Sozialen Netzwerke hinterlegen. Dies geschieht uber¨ die offiziellen Schnittstellen und API-Autorisierung mit OAuth oder OAuth ¨ahnlichen Stan- dards, sodass der Brucken-Server¨ zu keinem Zeitpunkt uber¨ das echte Klartext-Kennwort

Seite 87 Kapitel 4 Implementierung – Proof of Concept verfugt.¨ Der Machbarkeitsnachweis soll damit eine Aussage uber¨ Funktionalit¨at und Ein- schr¨ankung der Schnittstellen geben k¨onnen. Die folgenden Funktionen werden durch die Implementierung fur¨ den Machbarkeitsnachweis erbracht:

• Offentliche¨ Nachrichten automatisch aus pump.io in die angeschlossenen etablierten Sozialen Netzwerke verteilen.

• Nachrichten ggf. mit Bild (keine privaten) aus den etablierten Sozialen Netzwerken automatisch laden, zu pump.io-Aktivit¨aten konvertieren und dem Brucken-Benutzer¨ zustellen.

• Favorisierungen von Nachrichten aus angeschlossenen Netzwerken in pump.io zu dem jeweiligen Netzwerk synchronisieren.

• Kommentare zu Nachrichten aus angeschlossenen Netzwerken in pump.io zu dem jeweiligen Netzwerk synchronisieren.

Die Funktionen stellen fur¨ sich kein rechtliches Risiko dar. Lediglich ein ¨offentliches wei- ter teilen von aus dem ESN geladenen Nachrichten k¨onnte eine Urheberrechtsverletzung darstellen. Dieses Ereignis passiert aber zu keinem Zeitpunkt automatisch und kann nur durch die Interaktion des jeweiligen Benutzers ausgel¨ost werden.

4.1.1 Angeschlossene etablierte Netzwerke

An die Software angeschlossen werden die etablierten Sozialen Netzwerke Googleplus, Fa- cebook und Twitter die, wie schon in der Konzeption erw¨ahnt, aus Sicht eines in Deutsch- land ans¨assigen Unternehmen und fur¨ die uber¨ die Welt verteilten privaten Anwender als besonders relevant angenommen wurden. Von dem Hersteller von pump.io gibt es bereits eine Freie Software, die ¨offentliche Nachrichten unidirektional zu Twitter verteilen kann. Der angebotene Dienst unter www.pump2tweet.com steht der Offentlichkeit¨ im August 2014 nicht mehr zur Verfugung.¨

In den angeschlossen Sozialen Netzwerken wurden sogenannte interne Applikationen ange- legt, die ben¨otigt werden um einen API-Schlussel¨ zu erhalten (vgl. Abbildung 29 auf Seite 89). Nur mit diesem API-Key kann die eigene Software mit den offiziellen Schnittstellen kommunizieren. Den Schnittstellen-Anwendungen mussen¨ jeweils bestimmte Rechte ein- ger¨aumt werden, damit Benutzer bei der Autorisierung informiert sind, welche Folgen eine Nutzung der jeweiligen Anwendung nach sich ziehen kann – zum Beispiel: Die Anwen- dung darf in meinem Namen posten. Dieser Einsatz von Anwendungen fur¨ die Schnittstelle erm¨oglicht den Anbietern zu protokollieren, welcher Benutzer welche Anwendung wann

Seite 88 Kapitel 4 Implementierung – Proof of Concept und wie nutzt. Daruber¨ hinaus steuern die Anbieter, wie oft und welche Funktionen zur Verfugung¨ stehen. Facebook erlaubt beispielsweise ohne ein genaues Review der Anwen- dung keine ¨offentliche Anmeldung fur¨ die Schnittstelle – nur die Entwickler selbst und speziell benannte Personen k¨onnen auf Funktionalit¨aten zugreifen.

Abbildung 29: Facebook Schnittstellen-Management fur¨ Entwickler von Facebook-Apps

Googleplus und Facebook bieten uber¨ die Einbindung von Bibliotheken die M¨oglichkeit an, Zugriffsschlussel¨ mit der Anwendung auszutauschen. Twitter benutzt den OAuth- Mechanismus zur Autorisierung.

4.2 Software und Betrieb

Dieses Kapitel beschreibt den Aufbau und Arbeitsweise der Software und geht auf die Schnittstellen-Problematik der Hersteller ein. Bei der Inbetriebnahme und genaueren Un- tersuchung der Schnittstellen der Sozialen Netzwerke wurde festgestellt, dass es uber¨ die API-Schnittstelle von Googleplus keine M¨oglichkeit gibt Nachrichten zu ver¨offentlichen:

Note: The Google+ API currently provides read-only access to public data. All API calls require either an OAuth 2.0 token or an API key. [INC14b]

Um Nachrichten auf Googleplus im Namen des Brucken-Benutzers¨ ver¨offentlichen zu k¨onnen, muss der Umweg uber¨ Webseiten-Roboter genutzt werden, der fur¨ diese Im- plementierung nicht umgesetzt wurde. Diese Tatsache wird von vielen Entwicklern und in Googleplus kontrovers diskutiert [Dwy13].

4.2.1 Verwendete Werkzeuge

Die Brucke¨ basiert auf einem angepassten Framework fur¨ pump.io-Webanwendungen [E1414b] und ubernimmt¨ die Struktur der Software pump2status bzw. pump2tweet [E1414a] als Vorgabe fur¨ die Entwicklung um den Programmierstil (engl. coding conventions) des

Seite 89 Kapitel 4 Implementierung – Proof of Concept

Herstellers fortzufuhren.¨ Weiter ist dadurch eine korrekte Autorisierung der pump.io- Konten gew¨ahrleistet und die Konfiguration und Installation ¨ahnlich zu anderer pump.io- Software gehalten. Ebenso ist es fur¨ den Hauptentwickler einfacher die Programmierung nachzuvollziehen. Die Brucken-Software¨ ist in der JavaScript-Programmiersprache Cof- feeScript entwickelt. Ahnlich¨ wie die Programmiersprachen Ruby und Python nutzt CoffeeScript einen syntaktischen Zucker, der die Lesbarkeit des Codes erh¨oht. Zur Aus- lieferung des Web-Dienstes und der Arbeit im Back-End wird die Plattform Node.js eingesetzt. Node.js erlaubt die serverseitige Ausfuhrung¨ von JavaScript-Code und ist laut eigener Aussage besonders fur¨ große Datenmengen in Echtzeit-Anwendungen die uber¨ ver- schiedene Plattformen laufen geeignet. Die Aufbereitung der Webseiten erfolgt uber¨ die fur¨ Node.js verbreitete Template-Engine Jade. Die persistente Datenhaltung der Benut- zer und Aktivit¨aten wird uber¨ eine lokale Redis In-Memory-Datenbank realisiert. Die zur NoSQL-Familie geh¨orende Datenbank speicherte Key/Value-Paare und h¨alt die Daten- bank vollst¨andig im Arbeitsspeicher. Die Schreib- und Lesezugriffe sind daher besonders schnell im Vergleich zu Datenbanken die haupts¨achlich auf der Festplatte des Systems arbeiten. Die Persistenz wird in Redis dadurch erreicht, dass die Inhalte in kurzen In- tervallen auf die Festplatte ausgelagert werden. Als Betriebssystem der Brucken-Software¨ wird Debain/GNU Linux Wheezy eingesetzt. Durch die Modularit¨at und Plattformun- abh¨angigkeit sind aber auch andere Betriebssysteme als Host denkbar.

4.2.2 Arbeitsweise und Betrieb

Die Referenz-Implementierung h¨alt die Zugangsdaten fur¨ einen repr¨asentativen Benutzer [email protected]. Uber¨ die API des zugeh¨origen pump.io-Servers kann die Brucke¨ Nachrichten an beliebige Benutzer im pump.io-Netzwerk schicken. Benutzer k¨onnen sich mir ihrem pump.io-Account (z.B. [email protected]) an der Brucken-Software¨ re- gistrieren (vgl. Abbildung 35 auf Seite 116 im Anhang). Nach der Autorisierung uber¨ pump.io haben die Benutzer die M¨oglichkeit sich per Klick auf die Schaltfl¨ache add cre- dentails oder Logo des jeweiligen Netzwerks an Facebook, Googleplus oder Twitter anzu- melden (vgl. Abbildung 36 auf Seite 116 im Anhang). Beim Login werden die Benutzer auf die Seite der jeweiligen Anwendung im Sozialen Netzwerk geleitet und haben dort die M¨oglichkeit, wenn noch nicht eingeloggt, die tats¨achlichen Zugangsdaten einzugeben (vgl. Abbildung 37 auf Seite 117 im Anhang). Dieses Prozedere kennen viele Benutzer h¨aufig schon aus anderen Anwendungen oder Diensten die Funktionen wie Login uber¨ Facebook oder einem anderen Sozialen Netzwerk anbieten. Ist die Brucken-Applikation¨ erfolgreich registriert stehen nach der Anmeldung die Software-Token in der aktuellen Browser-Sitzung bereit. Unter den Logos der Sozialen Netzwerke wird der Benutzername

Seite 90 Kapitel 4 Implementierung – Proof of Concept der Anmeldung aus der aktuellen Browser-Sitzung geladen und angezeigt, der auf das jeweils verbundene Profil verlinkt. Durch den Klick auf die Schaltfl¨ache save credentails werden die aktuellen Sitzungsdaten persistiert und die Brucke¨ aktiviert. Sollte in der Datenbank der Software-Brucke¨ bereits gultige¨ Zugangsdaten fur¨ den angemeldeten Be- nutzer (logged in as:) zu einem Sozialen Netzwerk gefunden werden, wird die Schaltfl¨ache add credentails zu delete credentails und die Zugangsdaten beim Klick auf die Schalt- fl¨ache aus der Datenbank gel¨oscht. Die Brucke¨ speichert die Zugangsdaten in dem Format pump.io-Account ⇐⇒ ESN-Account ab (zum Beispiel der Schlussel¨ fur¨ die Benutzerzu- ordnung pump.io zu Twitter: usermap:[email protected] to 2217889806@twitter). Zus¨atzlich speichert die Brucke¨ die Zugangsdaten des jeweiligen pump.io-Accounts selbst, um die ausgehenden Nachrichten des Benutzers an die etablierten Netzwerke verteilen zu k¨onnen. Die Brucken-Software¨ ist modular aufgebaut, sodass jedes Soziale Netzwerk ge- trennt voneinander betrachtet und abgearbeitet wird. Dieser Aufbau ist n¨otig, da sich die Schnittstellen der Sozialen Netzwerke untereinander zu stark unterscheiden. In Googleplus muss beispielsweise der abgefragte Neuigkeiten-Feed selbst aufgebaut werden, in Facebook kann er direkt abgefragt werden. Bei Googleplus kommen bei der Abfrage einer Nachricht alle ben¨otigten Informationen wie z.B. das Profilbild des Absenders automatisch mit – bei Facebook mussen¨ die Benutzerprofile der Freunde und Seiten explizit abgerufen wer- den. Innerhalb der Module sind die Funktionen fur¨ die Vermittlung zu (toESN) und von (fromESN) etablierten Sozialen Netzwerk getrennt. Diese Trennung erlaubt Benutzern die jeweilige Funktionalit¨at nach Bedarf an- oder abzuschalten. Jedes Modul bietet eine Sync-Funktion nach außen an, die als Ubergabeparameter¨ die oben erw¨ahnte Benutzerzu- ordnung erwartet, in der die Zugangsdaten fur¨ die API-Schnittstelle hinterlegt sind. Das Front-End mit der ausgelieferten Webseite und Back-End fur¨ den Datenaustausch mit pump.io und den angeschlossenen Sozialen Netzwerken kann getrennt voneinander betrie- ben werden. Das hat den Vorteil, dass die Webseite bei einer Trennung jeder Zeit schnell ausgeliefert werden kann, auch wenn der Back-End-Prozess aufgrund der Synchronisati- on ausgelastet ist. Im Back-End pruft¨ ein Dienst in einem konfigurierbaren Zeitintervall (standardm¨aßig im 15 Minuten Takt) diese Schlussel¨ der Benutzerzuordnung (vgl. Listing 3 im Anhang). Der interne Sync-Ablauf der Module ist der folgenden Aufz¨ahlung zu ent- nehmen. Fur¨ jeden Benutzerzuordnung, die dem Modul des jeweiligen Sozialen Netzwerk zugeordnet ist, wird der folgende Ablauf durchlaufen. Die Realisierungen innerhalb der Module unterscheiden sich, wie erw¨ahnt, untereinander in Details und sind teilweise durch fehlende Funktionalit¨at in der Schnittstelle anders oder gar nicht implementiert.

1. Lade Benutzerdaten aus der Zuordnung (z.B. usermap:[email protected] to 100002056487693@facebook

Seite 91 Kapitel 4 Implementierung – Proof of Concept

2. Prufe¨ Postausgang des pump.io-Accounts (z.B. [email protected])

3. Alle Aktivit¨aten die ¨offentlich und junger¨ als Zeitintervall + Puffer (z.B. 20 Minuten) sind zu prufen.¨ Prufung¨ in der Datenbank, ob die gefundenen Aktivit¨aten schon in das angeschlossene Soziale Netzwerk verteilt wurden. Falls die jeweilige Aktivit¨at noch nicht ins soziale Netzwerk verteilt wurde, an das Netzwerk senden und alle Referenz-Informationen in der Datenbank speichern.

4. Frage alle Nachrichten aus dem angeschlossenen etablierten Sozialen Netzwerk ab, die junger¨ als Zeitintervall + Puffer sind. Prufe¨ in der Datenbank, ob die Nachrich- ten schon an den pump.io-Account gesendet wurden. Wenn die Nachricht noch nicht zu pump.io ubertragen¨ wurden, konvertiere sie zu einer neuen pump.io-Aktivit¨at. Die Aufbereitung der Aktivit¨aten findet nach dem Muster aus dem Kapitel Eine ge- meinsame Sprache statt. Die Nachricht wird im Namen des repr¨asentativen Benut- zers [email protected] als Direktnachricht an den Posteingang des pump.io- Nutzers der Benutzerzuordnung ubertragen.¨

5. Prufe¨ alle Nachrichten an der Quelle die zu den Sozialen Netzwerk geschickt wurden und fuhre¨ ggf. die Anderungen¨ an der Kopie durch (z.B. L¨oschen). Die Anderung¨ wird ebenfalls am Datensatz in der Datenbank durchgefuhrt.¨

6. Prufe¨ alle Nachrichten an der Quelle die aus dem Sozialen Netzwerk stammen und fuhre¨ ggf. die Anderung¨ an der Kopie in pump.io durch (z.B. L¨oschung) Die Anderung¨ wird ebenfalls am Datensatz in der Datenbank durchgefuhrt.¨

7. Prufen¨ alle Kopien der Nachrichten in pump.io, die aus dem Sozialen Netzwerk an den Benutzer synchronisiert wurden auf neue Kommentare oder Favorisierun- gen. Falls Kommentare oder Favorisierungen gefunden werden synchronisiere zum angeschlossenen Sozialen Netzwerk und speichere die Referenz in der Datenbank.

Abbildung 30: Durch die Referenz-Implementierung aufbereitete Nachricht aus Facebook (Original siehe Abbildung 31) in pump.io. Der Benutzer hat die Nachricht favorisiert und kommentiert.

Seite 92 Kapitel 4 Implementierung – Proof of Concept

Abbildung 31: Die Favorisierung und das Kommentar des pump.io-Nutzers wurden aus der Kopie (siehe Abbildung 30) ubernommen¨

Nach der Aktivierung der Brucke¨ werden durch den Prozess alle Nachrichten die junger¨ als ein konfigurierbares Zeitintervall + Puffer sind, aus dem Sozialen Netzwerk empfangen. Offentliche¨ Nachrichten des jeweiligen Benutzers aus pump.io, die junger¨ als dieser Zeit- intervall sind, werden an das Soziale Netzwerk ubertragen.¨ JavaScript und somit auch die Node.js-Plattform z¨ahlen zu den asynchronen Scriptsprachen. Der asynchrone Ablauf des oben beschriebenen Prozesses erlaubt eine parallele Verarbeitung der einzelnen Schritte und mehrerer Benutzer und sogar ganzer Sozialer Netzwerke gleichzeitig. Bei vielen Be- nutzer in der Software-Brucke¨ muss dieser Prozess auf die eingesetzte Hardware angepasst werden. In der Referenz-Implementierung werden zur Zeit alle ausgetauschten Nachrich- ten auf Updates und L¨oschung gepruft,¨ was nach einiger Zeit im Betrieb eine enormen Overhead erzeugt. Eine L¨osung, das Problem der ewig steigenden Masse an Nachrichten in den Griff zu bekommen, ist eine langsame Erh¨ohung der Zeitintervalle zur Prufung.¨ Ist eine Nachricht eine Woche alt, ist es unwahrscheinlicher, dass neue Aktionen auf sie angewandt werden. Eine Nachricht die mehrere Monate alt ist, hat in der Regel kaum noch Relevanz in schnelllebigen Netzwerken wie Twitter. Es genugt¨ alle 24 Stunden auf Anderungen¨ zu prufen.¨ Nachrichten die beispielsweise ¨alter als 6 Monate sind, k¨onnten vollst¨andig aus dem System heraus rotieren. Die Originale bleiben grunds¨atzlich an der Quelle erhalten und Benutzer k¨onnten wichtige Nachrichten mit einem nicht-l¨oschen-Flag versehen.

Seite 93 Kapitel 4 Implementierung – Proof of Concept

4.2.3 Restriktive Schnittstellen

Ein Problem, dass die Umsetzung des Machbarkeitsnachweises der geplanten Konzeption gef¨ahrdete, stellen die beschr¨ankten und limitierten Schnittstellen der etablierten Sozialen Netzwerke dar. Keine der ausgew¨ahlten Anbieter Googleplus, Facebook und Twitter bietet eine vollst¨andig offene API ohne Limitierung an, mit der alle Informationen abgerufen werden k¨onnen die (dem selben!) Benutzer auf der originalen Webseite zur Verfugung¨ stehen – selbst wenn der API-Anwendung explizit alle Rechte einger¨aumt werden. Twitter und Facebook lassen dabei noch die meisten Funktionen zu und erlauben das Posten und die Abfrage von (einigen) nicht ¨offentlichen Nachrichten. Bei Googleplus hingegen k¨onnen keine Nachrichten publiziert werden und bei einer Abfrage von Nachrichten werden lediglich ¨offentliche Postings zuruckgeliefert¨ – was quasi zu einer Unbenutzbarkeit der Google-Schnittstelle fuhrt.¨ Zudem kann bei Googleplus kein direkter Neuigkeitenstrom abgefragt werden. Daher muss jeder Feed jedes Benutzers einzeln abgefragt werden, zu dem der Brucken-Nutzer¨ in einer Beziehung steht. Weiter beschr¨ankt Google die maximale Anzahl der Abfragen auf 10.000 pro Tag. Bei drei Personen mit 50 Freunden (in Kreisen), die alle 15 Minuten abgefragt werden, wird dieses Limit durch die Brucke¨ innerhalb von 24 Stunden schon weit uberschritten.¨ Auf Anfrage an Googleplus, mehr Quota zu Verfugung¨ zu stellen, gab es die folgende Ruckmeldung¨ des Entwickler-Teams:

Thanks for your interest in receiving a higher quota for the Google+ API. Af- ” ter further review, we have decided not to grant this request. The Google+ API does not support creating an alternative stream. Thanks, Google+ Developer Relations Team“

Die Googleplus-Schnittstelle bietet mehr Quota fur¨ Abfragen auch kostenpflichtig an. Die Schnittstellen von Facebook liefern nicht die offiziellen, sondern anwendungsspezifische Benutzer-IDs zuruck,¨ was dazu fuhrt,¨ dass Abfragen der Profile nicht mit den Absender- IDs der Nachrichten ubereinstimmen¨ und um Profilbilder den Nachrichten zuzuordnen interne L¨osungen geschaffen werden mussen.¨ Ebenso spielen die schon erw¨ahnten Pri- vatsph¨are-Einstellungen eine Rolle. Durch die Facebook-Brucke¨ kann nicht gew¨ahrleistet werden, dass Nachrichten einzelner Benutzer bzw. Posts ubertragen¨ werden. Eine No- tifikation fur¨ nicht ubertragene¨ Inhalte, die nur uber¨ die Webseite und offiziellen Cli- ents empfangen werden k¨onnen, gibt es nicht. Da sich die Facebook-Anwendung, um fur¨ die Offentlichkeit¨ zug¨anglich gemacht werden zu k¨onnen, einem Review unterziehen muss, dem die Software aufgrund der Richtlinien nicht standhalten wurden,¨ kann die- ser Dienst nur dem Entwickler selbst und wenigen Testpersonen zur Verfugung¨ gestellt werden. Die OAuth-Logins der Netzwerke Facebook und Googleplus mussen¨ regelm¨aßig

Seite 94 Kapitel 4 Implementierung – Proof of Concept verl¨angert werden, da sie sonst verfallen. Ein Automatismus fuhrt¨ in der Brucke¨ diese Aufgabe regelm¨aßig durch, dennoch kann es sein, dass Tokens als ungultig¨ markiert wer- den. Die Brucken-Benutzer¨ sollten sich bei nicht funktionierender Synchronisation unter Umst¨anden noch einmal an der Brucke¨ anmelden und die Zugriffs-Tokens aktualisieren. Sicherlich sind einige dieser angefuhrten¨ Restriktionen zum Schutz der Anwender und Limitierungen von Anfragen pro Zeiteinheit zum Schutz der Server und Performance ge- dacht, dennoch ist anzunehmen, dass die Anbieter bewusst Funktionen unterbinden und beschr¨anken um die Benutzer weiter an die eigenen Anwendungen und Webseiten zu bin- den.

4.3 Messung

Die entwickelte Software-Brucke¨ wurde am 12.06.2014 in den Betrieb genommen und der Offentlichkeit¨ als Dienst unter der Webseite pumpbridge.me zur Verfugung¨ gestellt. Die Software selbst wurde einen knappen Monat zuvor ohne offizielle Bekanntmachung als Freie Software in einem ¨offentlichen Repository zug¨anglich gemacht und dort weiterent- wickelt [Gmb14]. Die Messung dient der Untersuchung, welche Schwierigkeiten bei der Nutzung einer Software-Brucke¨ mit pump.io und etablierten Sozialen Netzwerken auf- treten und ob Zug¨ange durch Betreiber abgeschaltet werden. Weiter soll das Verhalten der Nutzer untersucht werden und Kenntnis uber¨ unbedingt ben¨otigte Funktionalit¨aten gewonnen werden. Zus¨atzlich soll die ¨offentlich genutzte Brucke¨ Kenntnisse uber¨ Da- tenmengen und Performance des Systems liefern, um in Erfahrung zu bringen, welche Anforderung an die Hardware gestellt wird und welche Ressourcen wichtig sind um ein Dienst in ¨ahnlicher Form fur¨ eine Personengruppe anzubieten. Durch Einschr¨ankungen der Schnittstellen konnte der Offentlichkeit¨ nur die Brucken-Funktionalit¨ ¨aten fur¨ Twitter (lesend und schreibend) und Googleplus (nur ¨offentliche Nachrichten lesend) angeboten werden. Die Brucken-Funktionalit¨ ¨aten fur¨ Facebook konnte lediglich durch den Entwick- ler und Autor getestet werden. Neben dem Dienst k¨onnen Benutzer die Freie Software selbst in Betrieb nehmen und Probleme und Wunsche¨ auf der Projekt-Website melden.

• Zeitraum der Messung: Donnerstag den 12.06.2014 bis zum Donnerstag den 14.08.2014

• L¨ange in Tagen: 63 Tage (ca. 2 Monate)

• Angebotene Funktionen:

– pump.io-Accounts mit ESN-Accounts verknupfen¨ oder l¨oschen (Austausch der Berechtigungsnachweise)

Seite 95 Kapitel 4 Implementierung – Proof of Concept

Ausstattung des pumpbridge Brucken-Server¨ Ressource Beschreibung Anbeiter DigitalOcean Plattform Kernel-based Virtual Machine (KVM) Prozessor CPU 2x2,4 Ghz QEMU Virtual CPU Version 1.0 Arbeitsspeicher RAM 2GB RAM Festplatte HDD 20GB SSD Betriebssystem OS Debian 7

Tabelle 4: Hardware-Spezifikation des eingesetzte Brucken-Servers¨

– Offentliche¨ pump.io-Nachrichten im Namen des jeweiligen ESN-Nutzers auf Twitter ver¨offentlichen (mit Anpassung)

– Offentliche¨ Twitter-Nachrichten die als Direktnachricht vom repr¨asentativen Benutzer an den Posteingang (Inbox-Stream) des jeweiligen pump.io-Nutzer

– Offentliche¨ Googleplus-Nachrichten als Direktnachricht vom repr¨asentativen Benutzer an den Posteingang (Inbox-Stream) des jeweiligen pump.io-Nutzer

Die Zielgruppe der Messung war jeder Benutzer im pump.io-Netzwerk, der zus¨atzlich einen Account in Twitter oder Googleplus benutzt. Durch eine ¨offentliche Mitteilung [Geb14b] in pump.io sind Nutzer aufgefordert worden, die Brucke¨ zu testen (vgl. Abbil- dung 16 aus Seite 50). Die Benutzer sind darauf hingewiesen worden, dass es sich um einen Machbarkeitsnachweis und fruhe¨ Alpha-Version der Software handelt. In dem Verlauf der Arbeit sind zu dieser Mitteilungen Kommentare von Teilnehmern und Unbeteiligten als Ruckmeldung¨ eingeflossen.

4.3.1 Testumgebung und gemessene Daten

Die Hardware-Spezifikation des Brucken-Servers¨ sind der Tabelle4 zu entnehmen.

Uber¨ den Zeitraum des Betriebs wurden die folgenden Datenmengen festgestellt. Die Auslastung des Servers uber¨ den Zeitraum des Testbetriebs ist der Abbildung 32 zu ent- nehmen.

Seite 96 Kapitel 4 Implementierung – Proof of Concept

Messung vom 12.06.2014 bis zum 14.08.2014 Beschreibung Menge Zeitraum 63 Tage ca. 2 Monate Benutzer insgesamt 34 angemeldete Benutzer Benutzer aktiv 14 aktive Benutzer am 14.08.2014 Benutzer Twitter 9 aktive Konten Benutzer Google 8 aktive Konten Nachrichten zu ESN 103 Nachrichten (toESN) Nachrichten aus ESN 138130 Nachrichten (fromESN) davon aus Google 1280 Nachrichten davon aus Twitter 136850 Nachrichten

Tabelle 5: Auswertung der Datenmengen der Brucken-Software¨ (pumpbridge) nach 2 mo- natigem Betrieb

Abbildung 32: Auslastung des virtuellen Servers

Die asynchrone Verarbeitung der verschiedenen Benutzer in den etablierten Sozialen Netz- werken, fur¨ die jeweils in Googleplus die letzten 3 Nachrichten von jeder Beziehungen und fur¨ Twitter die letzten 15 Tweets aller Following (HomeTimeline) im 15 Minuten- Takt uberpr¨ uft¨ werden, setzten mit dem jeweils gestarteten Prozess einen CPU-Kern des Servers unter hohe Auslastung (100%). Durch langsame Antwortzeiten und teilweise

Seite 97 Kapitel 4 Implementierung – Proof of Concept insgesamt lange Laufzeiten der GET- und POST-Requests an den Schnittstellen (gleich- zeitige Abfragen verschiedener Benutzer uber¨ die API-Schnittstelle mit der selben IP des Servers) stehen vor allem der Prozessor und Arbeitsspeicher, die sich um das Ressourcen- Management der einzelnen Prozesse kummern,¨ unter hoher Last. Die Auslagerung der Funktion in eigene Module, die fur¨ jedes angeschlossene Soziale Netzwerk pro Benutzer abgerufen werden k¨onnen, ist besonders in dieser Situation des Datenaustauschs mit an- deren Diensten vorteilhaft. Es mussen¨ Anfragen abgesetzt, empfangen und verarbeitet werden. Die Antworten werden aufbereitet und in die lokale Datenbank geschrieben. Die Trennung erlaubt dem System, je nach Hardware und Anzahl der Benutzer im System, zu konfigurieren, wie viel parallele Verarbeitungen gleichzeitig stattfinden durfen.¨ Dabei wurde die parallele Verarbeitung in der Implementierung haupts¨achlich mit der Node.js- Bibliothek Async.js [al.14a] und der Funktion eachLimit(arr, limit, iterator, callback) realisiert. Durch andauernde Indexierung in der Datenbank werden Schlusselpaare¨ (engl. Key/Value) schnell gefunden.

4.3.2 Evaluierung

Die Evaluierung beschreibt die Bewertung der Implementierung des Machbarkeitsnach- weises und gibt Aufschlusse¨ fur¨ eine zukunftige¨ Entwicklung der Brucken-Software,¨ in- wieweit sich das entwickelte Konzept und die Freie Software pump.io eignen und welche Must-have-Features fehlen um ein breit genutztes synthetisiertes Soziales Netzwerk zu betreiben.

Schwierigkeiten traten vor allem auf Grund der restriktiven Schnittstellen auf. Die API- Schnittstellen reagieren langsam, beschr¨anken die Anzahl der Abfragen und unterbinden den Austausch ben¨otigter Informationen. Die zusammengefassten Nachrichtenstr¨ome, wie sie ublicherweise¨ nach der Anmeldung auf den Startseiten der etablierten Sozialen Netz- werke angezeigt werden, sind uber¨ die untersuchten Schnittstellen von Googleplus gar nicht und der Schnittstelle von Facebook nur in ver¨anderter Form zu empfangen. Selbst wenn die offiziellen Schnittstellen-Anwendungen genutzt werden, k¨onnen beispielsweise bei Facebook ohne ein Review durch den Anbieter die Anwendung selbst keinen ande- ren Personen angeboten werden. Um einen vollst¨andigen Ersatz fur¨ die Webseiten- und Programm-Clients der etablierten Sozialen Netzwerke anzubieten ist der Weg uber¨ Webseiten-Crawler und Bots, die mit den Zugangsdaten der Benutzer arbeiten und sich wie eine echte Person vor dem Bildschirm verhalten, unumg¨anglich. Nur so ist es M¨oglich, sich der Kontrolle und Willkur¨ der angebotenen Schnittstellen zu entziehen und auf alle Funktionen und Informationen zugreifen zu k¨onnen. Der Nachteil: Bei den untersuchten

Seite 98 Kapitel 4 Implementierung – Proof of Concept

Sozialen Netzwerken werden durch den Einsatz von Robotern und der Zusammenfassung und Speicherung in einem alternativen Stream die AGBs bzw. TOS der Anbieter verletzt. Das kann im glimpflichen Fall eine Sperrung oder L¨oschung des Accounts nach sich ziehen. Im schlimmsten Fall, angenommen durch das Angebot eines (kostenpflichtigen) Dienstes, ist mit einer Klage des Anbieters zu rechnen. Ganz abgesehen davon, ist in der Rechtspre- chung noch nicht abschließend gekl¨art, wie sich das (automatisierte) Teilen von fremden Inhalten verh¨alt und ob und wann bei der Kopie und Publikation eine Urheberrechtsver- letzung vorliegt. Wird der Roboter und die Brucke¨ allerdings auf einem eigenen Server betrieben und ausschließlich fur¨ den pers¨onlichen Bedarf genutzt um eigene Nachrichten an mehrere Soziale Netzwerke zu verteilen und Nachrichten aus den Netzen zusammen- gefasst in einem Stream zu empfangen, haben die Anbieter der Sozialen Netzwerke wenig M¨oglichkeiten einen Vertragsbruch nachzuweisen.

Die Implementierung der Abfrage und Aufbereitung der Aktivit¨aten aus etablierten Sozia- len Netzwerken muss bei der Integration in die Software-Brucke¨ jedes Mal individuell neu betrachtet werden. Von den angeschlossenen Netzwerken unterstutzen¨ alle Schnittstellen ein activitystrea.ms-¨ahnlichen [CC11] Aufbau im JSON-Format. Jedoch unterscheiden sich die Namen und Interpretationen der Datentypen. Was bei dem einen Sozialen Netzwerk Message ist, ist bei dem anderen Text. Der dauerhafte Betrieb einer Software-Brucke¨ er- fordert einen fortlaufenden Update-Prozess damit die Informationen kontinuierlich gleich und korrekt aufbereitet und angezeigt werden – auch wenn sich Funktionen der etablier- ten Netzwerke ¨andern. Die Verarbeitung zu den etablierten Netzen spielt ebenfalls eine Rolle und ist in keinem Netzwerk gleich. In einigen Netzen werden Links auf Bilder, Vi- deos und Webseiten interpretiert und eingebunden in anderen nur als Text angezeigt. Wiederum andere haben beispielsweise Darstellungsprobleme mit HTML-Umlauten, wie sie durch einige pump.io-Clients erzeugt werden. Das entwickelte Konzept gibt hier nur das Grundgerust¨ vor, welche Informationen fur¨ einen verst¨andlichen Kontext ubertragen¨ werden mussen.¨

Die Implementation zeigt auch, dass auf der Seite, die allen Input der angeschlossenen Sozialen Netzwerke zusammenfasst und darstellt die Ubersichtlichkeit¨ und der Uberblick¨ verloren gehen kann. Die Frequenz der Nachrichten aus den angeschlossenen Netzwer- ken ist sehr unterschiedlich. In dem Zeitraum des Tests kamen auf einen ¨offentlichen Googleplus-Post zirka 105 Twitter-Tweets. Eine intelligente Filterung, Sortierung und Markierung (Highlighting), die das Front-End und die Software pumpbridge zur Zeit noch nicht liefern, ist unverzichtbar. Durch Ruckmeldungen¨ wurde klar, dass sich die Qualit¨at und Wahrnehmung von Nachrichten und Posts aus Sozialen Netzwerken unterscheiden. Neigen Benutzer dazu Googleplus und pump.io-Nachrichten aufmerksam zu verfolgen,

Seite 99 Kapitel 4 Implementierung – Proof of Concept werden Twitter-Tweets bei Gelegenheit konsumiert und viele ignoriert – was bei der An- zahl an neuen Twitter-Nachrichten auch nicht wirklich anders zu h¨andeln w¨are. Einigen Benutzern ist die Bidirektionalit¨at an sich unwichtig und eine Option, Nachrichten aus- schließlich zu empfangen oder zu verteilen sinnvoll. (aus der Wunschliste weiterer Featuers: option to configure the importing of the remote feed to pump.io).

Der Machbarkeitsnachweis zeigt, wenn auch rudiment¨ar, dass die Konsolidierung von So- zialen Netzwerken gut funktionieren kann und dem Benutzer, selbst uber¨ die offiziellen Schnittstellen, ein echter Mehrwert geliefert wird. Weitere Funktion (vor allem durch Filte- rung) und h¨ohere Transparenz durch die Umsetzung der Architektur uber¨ Proxy-Benutzer und die Nutzung eigener Schnittstellen verspricht eine noch nicht da gewesene Benutzer- Erfahrung auf einer neuen Ebene. Durch die Fokussierung auf das Wesentliche und die Verlinkung auf Originalquellen behalten die eingebundenen Sozialen Netzwerke ihre Da- seinsberechtigung. Spezialisierte Anwendungen und Funktionen innerhalb der Netzwerke werden durch die Software-Brucke¨ und der Nutzung eines einzigen Clients nicht abgel¨ost oder untergraben.

Fur¨ den Betrieb von pumpbridge empfiehlt es sich im Hinblick auf den Datenschutz, Da- tensicherheit, der rechtlichen Situation und der allgemeinen Performance einen eigenen Server zu betreiben. Ein Angebot eines fertigen Images mit einfacher Konfiguration, wel- ches beispielsweise bei einem Server-Hoster platziert werden kann, w¨are denkbar um die Software zug¨anglicher fur¨ den eigenen Betrieb zu machen.

4.3.3 Resonanz

Die Resonanz auf die Ver¨offentlichung durch Nachrichten in pump.io selbst [Geb14b] [Geb14a] war sehr unterschiedlich. Viele Benutzer haben grunds¨atzlich das Bedurfnis¨ die Sozialen Netzwerke zu konsolidieren und mit einem Client zu steuern. Die derzeitige Imple- mentierung liefert einigen Benutzer einen echten Mehrwert und erspart Zeit. Ohne eine intelligente, konfigurierbare Filterung und die derzeitige Darstellung in pump.io neigen aber viele Anwender dazu, die Brucke¨ weider abzuschalten. Den Benutzern gehen unter den unz¨ahligen Twitter-Nachrichten, die potenziell nicht alle gelesen werden, die wichtigen Nachrichten aus dem pump.io-Netzwerk verloren. Einige Benutzer berichten davon, dass sie gezielt Leuten auf Twitter entfolgten, da die andauernde Pr¨asenz in dem pr¨aferierten Sozialen Netzwerk als Spam empfunden wurde. Die Direktnachrichten des allgemein re- pr¨asentativen Benutzers sorgen bei vielen Clients zu einer Notifikation, die bei jeder neuen Nachricht als st¨orend empfunden wird. Das fuhrte¨ dazu, dass einige Clients angepasst wur- den. Das deutet darauf hin, dass die Integration der Vorgestellten Konzeption nicht ganz

Seite 100 Kapitel 4 Implementierung – Proof of Concept ohne kleinere Anpassungen an dem pump.io-Server auskommt. Durch in der Brucke¨ nach außen nicht klar definierte Verhaltensmuster, sind Benutzer verunsichert, ob und welche Daten wann synchronisiert werden. Eine Prufung¨ des aufbereiteten, aus pump.io stam- menden, Textes im angeschossenen etablierten Sozialen Netzwerk bleibt meist nicht aus. Andere Nutzer, wie zum Beispiel Bradley M. Kuhn (President of the Software Freedom Conservancy) [Kuh14] oder Mike Macgirvin (Creator of Friendica and Zot Red Matrix) [Mac14], machen sich besonders Sorgen um die rechtlichen Aspekte, m¨ogliche Verletzung der AGBs und TOS und dem Fakt indirekt geschlossene unfreie System zu unterstutzen.¨ Mike Macgirvin, der Erfinder von Frendica (einem weiteren dezentralen Sozialen Netz- werk), spricht von einem Kampf gegen Windmuhlen¨ und Aussperrung durch die Provider bei einem ¨ahnlichen Versuch der Integration in die eigene Software. Zusammengefasst ist der Bedarf an einer Software-Brucke¨ da, die Proof of Concept Implementierung und die Clients aber in der Tiefe noch nicht ausgereift genug fur¨ den allt¨aglichen Einsatz. Bis zu der Fertigstellung dieser Arbeit wurde kein Schnittstellen-Zugang zu den angeschlosse- nen Sozialen Netzwerken gesperrt und kein Account blockiert. Im Folgenden sind einige Ruckmeldungen¨ von pump.io-Nutzern zu der pumpbridge-Diskussion unkommentiert auf- gefuhrt,¨ die ein allgemeines Stimmungsbild vermitteln sollen (vgl. [Geb14b][Geb14a]):

Christopher Allan Webber: I am not a Twitter apologist. I do think it’s a ” bummer that there are legal issues, because I think bridges are good for free software. It’s probably true that the ToS won’t allow it. That sucks. I’m really glad @Mathias Gebbe is working on this stuff though. I think building and proving the tools is important, and even if there are pain points, were those pain points ever clearer? Thanks for your hard work, @Mathias Gebbe! You rock!“

macgirvin: We went through this with Friendica - as service after service ” (including those on the so-called ”free web”) started shutting their doors to federation and blocking access from foreign services. Some as a direct result of the fact that we were providing things that they couldn’t or wouldn’t. Call me jaded. I left that project and started doing something completely different. Better and cooler but different. I don’t believe federation is possible in today’s climate. You’re just chasing windmills. I understand - I chased the damn things too.“

sazius: I’m not sure I like that the entire Twitter feed comes in as direct ” messages to me. Not sure what would be a better solution, though...“

joeyh: Yeah, not ideal for twitter, but perfect for facebook. This is stunning!“ ”

Seite 101 Kapitel 4 Implementierung – Proof of Concept

jrobb: ...maybe I should just unfollow a lot of people on twitter :-)...“ ”

Seite 102 Kapitel 5 Fazit

5 Fazit

In dieser Arbeit wird die Konzeption des automatischen Austauschs von Inhalten zwi- schen etablierten Sozialen Netzwerken und dem dezentralen Freien Software Netzwerks pump.io beschreiben und mit einem Machbarkeitsnachweis untersucht. Die Bedeutung und Arten von Sozialen Netzwerken in unser Gesellschaft werden beschreiben und die elementaren Funktionen gepruft.¨ Weiter werden rechtliche Aspekte dargestellt und die Nachricht mit digitalen Inhalt als Grundelement herausgestellt. Der Entwurf der Konzep- tion wurde ohne Berucksichtigung¨ der aktuellen rechtlichen Lage und technischen Details der ¨offentlichen API-Schnittstellen betrachtet. Die entworfenen Architekturen zeigen, dass es grunds¨atzlich m¨oglich ist, ein Soziales Netzwerk aufzubauen, das mit Hilfe von Freier Software mehrere etablierte Soziale Netzwerke zusammenfasst und steuert. Das Ergebnis und die neuen M¨oglichkeiten liefern dem Anwender einen echten, in der Form auf dem Markt nicht vorhanden, Mehrwert.

In der Praxis ist eine vollumf¨angliche Umsetzung der Konzeption dank der beschr¨ankten ¨offentlichen Schnittstellen nur bedingt m¨oglich. Zu viele Informationen und Funktionen werden zuruckgehalten¨ und k¨onnen nicht genutzt werden. Die Implementierung zeigt, dass sich aber grunds¨atzlich die Freie Software pump.io technisch eignet, einen gemeinsamen Konsens aus den Netzen zu bilden und diesen durch allgemeine Standards (wie HTML5 und CSS) anschaulich aufzubereiten und darzustellen. Ebenso ist uber¨ die Basis eine An- steuerung der angeschlossenen Netze m¨oglich. Die derzeitige Umsetzung ohne Filterung, ohne explizite Konfiguration des Verhaltes der Brucke¨ und die gegenw¨artige Aufbereitung von Inhalten zu den etablierten Sozialen Netzwerken machen die Software-Brucke¨ zur Zeit fur¨ die meisten Anwender in der Praxis weitestgehend untauglich. Durch kleineren Wei- terentwicklungen an der Brucke¨ und pump.io kann den Benutzern von etablierten Sozialen Netzwerken mit relativ offenen Schnittstellen, wie z.B. Twitter, indem haupts¨achlich mit ¨offentlichen Nachrichten gearbeitet wird, ein echter Mehrwert geboten werden. Dennoch bleibt zu vermuten, dass der Betrieb eines ¨offentlichen zug¨anglichen Dienstes nicht von langer Dauer ist. Werden die Anbieter durch exzessive Nutzung auf die Brucke¨ aufmerk- sam, werden sie voraussichtlich die Zug¨ange der Anwendung sperren oder l¨oschen, da fast immer Nutzungsbedingungen verletzt werden. Naturlich¨ besteht die M¨oglichkeit sich de- ren Gunst mit Geldern einzukaufen – was aber nicht Sinn der Schnittstelle ist. Google bietet beispielsweise kostenpflichtig mehr Quota fur¨ Abfragen uber¨ die Schnittstelle an.

Der lokale Betrieb fur¨ auf einem eigenen Server und die Bereitstellung der Freien Software pumpbridge als Werbung und sinnvolle Erweiterung fur¨ die Funktionalit¨at (Feature-Set) von pump.io, ist hingegen unproblematisch. Die Software bringt Vorteile mit sich, die es

Seite 103 Kapitel 5 Fazit zum Beispiel erm¨oglichen pump.io gleichzeitig fur¨ die interne und externe Unternehmens- kommunikation einzusetzen. Der Betrieb eines eigenen Dienstes bzw. Servers ist naturlich¨ mit Kosten verbunden und setzt ein gewisses technisches Verst¨andnis voraus. Durch die Anbindung an Produkte, die nicht unter der eigenen Kontrolle stehen, steht die Software selbst allerdings immer in starker Abh¨angigkeit zu den jeweils angeschlossenen Diensten und deren Anbietern. Ebenso sind die erw¨ahnten Probleme in der Software pump.io zu l¨osen, um die Privatsph¨are und den Datenschutz von Benutzern nicht zu gef¨ahrden.

5.1 Ausblick

Zukunftig¨ ist eine Weiterentwicklung der vorhandenen Software-Brucke¨ denkbar. Ein sinn- voller n¨achster Schritt w¨are eine Analyse und Absch¨atzung des Aufwands fur¨ die Entwick- lung von Webseiten-Robotern fur¨ einige bzw. bestimmte etablierte Soziale Netzwerke oder die Umsetzung von Filterung und Suche in pump.io – wovon auch nicht Brucken-Nutzer¨ profitieren wurden.¨

Ein Funke Hoffnung bleibt, dass Anbieter großer Sozialer Netzwerke in Zukunft zu der Einsicht gelangen, welche großen Vorteile ein f¨oderiertes Soziales Netzwerk mit sich bringt. Von offenen Schnittstellen und Standards wurden¨ alle profitieren, wie es bereits bei der E-Mail der Fall war. Der Implementation der Brucken-Software¨ fehlen noch viele Funktion fur¨ den Datenaustausch und Konfiguration der Benutzer, die bereits in der Konzeption festgelegt sind. Es ist abzuw¨agen welche Funktionen zu welchem Aufwand umgesetzt und welche davon fur¨ ein m¨ogliches Szenario tats¨achlich ben¨otigt werden.

Bei dem Betrieb der Software liegt es in der Auslegung der Anbieter ob durch den Einsatz der bidirektionalen Brucke¨ die Nutzungsbedingungen des jeweiligen etablierten Sozialen Netzwerks verletzt werden. Der Benutzer setzt sich aber grunds¨atzlich der Gefahr aus, seinen Account in dem etablierten Sozialen Netzwerk zu verlieren. Das ist vor allem bei der weiteren Investition von Zeit und Geld durch die Weiterentwicklung zu berucksichtigen.¨

Es bleibt zu hoffen, dass die deutsche Rechtsprechung zukunftig¨ Anderung¨ am Urheber- rechtsgesetz (UrhG) vornimmt um fur¨ die beschriebenen Problematiken des Teiles, auf- greifen von Inhalten und kopieren uber¨ Netzwerkgrenzen hinweg eine interessengerechte, eindeutige und zeitgem¨aße L¨osung zu finden. Damit k¨onnte auch die Willkur¨ der Anbieter unterbunden und Abmahnanw¨alte ruhig gestellt werden.

Seite 104 Kapitel 5 Quellenverzeichnis

Quellenverzeichnis

[al.14a] al., Caolan M.: Async.js is a utility module which provides straight-forward, powerful functions for working with asynchronous JavaScript. (2014). https: //github.com/caolan/async#eachLimit. – Abgerufen am 17.08.2014

[al.14b] al., Jean Baptiste F.: pump.io-Wiki: Bridge Architecture. (2014). https: //github.com/e14n/pump.io/wiki/BridgesArchitecture. – Abgerufen am 05.08.2014

[Bar64] Baran, Paul: On distributed communications networks. In: Communications Systems, IEEE Transactions on 12 (1964), Nr. 1, 1–9. http://goo.gl/GpYhEc

[Beh14] Behrenshausen, Bryan: pump.io: the decentralized social network that’s re- ally fun. (2014). https://opensource.com/life/13/7/pump-io. – Abgerufen am 21.07.2014

[Ber14] Bertram, Nika: Gibt es ein Leben ohne Facebook? (2014). http://www. wdr5.de/sendungen/leonardo/facebook_zehnjaehriges100.html. – Abge- rufen am 15.07.2014

[Bug14] Buggisch, Christian: Social Media und soziale Netzwerke – Nutzerzahlen in Deutschland 2014. (2014). http://goo.gl/0LhU8S. – Abgerufen am 30.06.2014

[CC11] Creative Commons 3.0, Site content released u.: Activity sTreams li- censed under OWFa 1.0. In: Abgerufen am 10.07.2014 (2011). http:// activitystrea.ms

[Dat14] DataDriven, Philipp: Das neue MySpace. Ohne Tom. (2014). http: //datadriven.de/blog/2012/09/24/das-neue-myspace-ohne-tom/. – Ab- gerufen am 15.07.2014

[Dwy13] Dwyer, Jeff: Why is the Google+ API read only? (2013). http://goo.gl/ yzuwbS. – Abgerufen am 10.08.2014

[E1414a] E14N: pump2status. (2014). https://github.com/e14n/pump2status.– Abgerufen am 15.07.2014

[E1414b] E14N: pump.io-client-app. (2014). https://github.com/e14n/pump. io-client-app. – Abgerufen am 15.07.2014

[E+07] Ellison, Nicole B. u. a.: Social network sites: Definition, history, and schol-

Seite 105 Kapitel 5 5 Quellenverzeichnis

arship. In: Journal of Computer-Mediated Communication 13 (2007), Nr. 1, 210–230. goo.gl/17IviW

[EGH11] Ebersbach, Anja ; Glaser, Markus ; Heigl, Richard: Social Web 2. Auflage. UVK-Verlag-Ges., 2011. – ISBN 978–3–8252–3065–4

[Ehm10] Ehms, Karsten: Social Software Vulkan – Weiterentwicklung des Dreiecks. (2010). http://www.ehms-muenchen.de/blogs/karsten/stories/3560.– Abgerufen am 25.05.2014

[Eth13] Etherington, Darrell: Twitter Solves The Follow-Back Tango, Enables Di- rect Messages From All Your Followers. (2013), Oktober. http://techcrunch. com/2013/10/15/twitter-direct-messages-all-followers/

[Fen13] Fenniak, Mathieu: The Web API Checklist. (2013). https://mathieu. fenniak.net/the-api-checklist. – Abgerufen am 23.06.2014

[Fir14] Firsching, Jan: Maslowsche Bedurfnispyramide¨ fur¨ Soziale Netzwerke. (2014). goo.gl/TAFGO2. – Abgerufen am 15.08.2014

[Fou14] Foundation, The Apache S.: Apache License, Version 2.0. (2014). http:// www.apache.org/licenses/LICENSE-2.0.html. – Abgerufen am 15.07.2014

[Geb14a] Gebbe, Mathias: higher quota for the Google+ API. (2014). http://goo. gl/QXwEXj. – Abgerufen am 14.08.2014

[Geb14b] Gebbe, Mathias: Pumpbrige publish post. (2014). http://goo.gl/QXwEXj. – Abgerufen am 14.08.2014

[Gem14] Gemeinfrei: Vier-Seiten-Modell de. (2014). http://commons.wikimedia. org/wiki/File:Vier-Seiten-Modell_de.svg. – Abgerufen am 15.07.2014

[Gmb10] GmbH, Fittkau & Maaß C.: Social Networks im Reality Check: Mehr passive als aktive Networker. In: Abgerufen am 30.07.2014 (2010). http://www.w3b. org/web-20/social-networks-mehr-passive-als-aktive-networker. html

[Gmb12] GmbH, BITKOM R.: Social Media in deutschen Unternehmen. In: Abgerufen am 25.05.2014 (2012), 1–28. http://www.bitkom.org/de/publikationen/ 38338_72124.aspx

[Gmb13] GmbH, BITKOM R.: Soziale Netzwerke – dritte, erweiterte Studie. In: Abgerufen am 25.05.2014 (2013), 1–62. http://www.bitkom.org/de/

Seite 106 Kapitel 5 5 Quellenverzeichnis

publikationen/38338_77778.aspx. – Stand 31.10.2013. Eine repr¨asentative Untersuchung zur Nutzung sozialer Netzwerke im Internet

[Gmb14] GmbH, Intevation: pumpbridge lets you link your pump.io account to other social networks. (2014). https://wald.intevation.org/projects/ pumpbridge/. – Abgerufen am 15.08.2014

[Hab13] Habring, Stefan: Analyse und Vergleich von dezentralen sozialen Netz- werken. (2013). http://stefanhabring.me/fileadmin/portfolio/assets/ Habring-Stefan-Bachelorarbeit-Teil-2.pdf. – Abgerufen am 25.02.2014

[HV13] Heise Verlag (jk): Internet-Uberwachung:¨ Google, Apple, Microsoft, Fa- cebook, Twitter & Co. gegen die NSA. (2013). http://goo.gl/cV8W3J.– Abgerufen am 30.06.2014

[HV14] Heise Verlag ds: Facebook kann Reingewinn mehr als verdoppeln. (2014), July. http://goo.gl/2qp6i0. – Abgerufen am 19.08.2014

[Inc14a] Inc, Facebook: Erkl¨arung der Rechte und Pflichten. (2014). https://www. facebook.com/legal/terms. – Abgerufen am 19.08.2014

[INC14b] INC, Google: Google+ API. (2014). https://developers.google.com/+/ api/. – Abgerufen am 10.08.2014

[Ins14] Institut, Bibliographisches: Duden. (2014). http://www.duden.de/ rechtschreibung/etablieren. – Abgerufen am 30.06.2014

[(ja14] ([email protected]), JanKusanagi: Some tips for a better experience using the Pump.io network. (2014). http://goo.gl/X5TTpg. – Abgerufen am 15.08.2014

[JH14] Judith Horchert, Ole R.: Ein Jahr NSA-Skandal: Das sind Snowdens wichtigste Enthullungen.¨ (2014). http://goo.gl/eYU0dY. – Abgerufen am 30.06.2014

[jpo14] jpope: pump.io User Directory. (2014). https://static.jpope.org/users. html. – Abgerufen am 30.06.2014

[JRH+04] Jeckle, Mario ; Rupp, Chris ; Hahn,Jurgen¨ ; Zengler, Barbara ; Queins, Stefan: UML 2 glasklar. 2004. – ISBN 3–446–22575–7

[Jun14] June 2014, ranked by number of active users (in m. o.: sta- tista. (2014). http://www.statista.com/statistics/272014/

Seite 107 Kapitel 5 5 Quellenverzeichnis

global-social-networks-ranked-by-number-of-users/. – Abgerufen am 30.06.2014

[Kaz14] Kazim, Hasnain: Twitter-Verbot in der Turkei.¨ (2014). http://goo.gl/ uTY7B4. – Abgerufen am 30.06.2014

[Kra13] Kraemer, Christopher: Wie Facebook ohne Katzen. In: Abgerufen am 23.06.2014 (2013). http://www.manager-magazin.de/unternehmen/it/ a-900225.html

[Kuh14] Kuhn, Bradley M.: I’m delighted that you’ve found a way to again con- struct a two-way bridge to Twitter... (2014), July. https://identi.ca/bkuhn/ comment/tLZo3oYPTNGK4TinrvHOrA. – Abgerufen am 18.08.2014

[LH08] Leskovec, Jure ; Horvitz, Eric: Planetary-scale views on a large instant- messaging network. (2008), 915–924. http://goo.gl/Wn94z2

[Mac14] Macgirvin, Mike: (2014), July. https://identi.ca/macgirvin/comment/ -MDf3fUvTgytDEENpt9otg. – Abgerufen am 18.08.2014

[Mil67] Milgram, Stanley: The small world problem. In: Psychology today 2 (1967), Nr. 1, 60–67. http://goo.gl/zVQ8c8

[Obe14] Oberndorfer, Elisabeth: Social Media Sperre im Irak: Whi- sper als Alternative. (2014). https://curved.de/news/ social-media-sperre-im-irak-whisper-als-alternative-83991.– Abgerufen am 30.06.2014

[pin11] pingp: The Great Firewall of China: Background. In: Torfox – A Stanford Project (2011). http://goo.gl/E9o2GH. – Abgerufen am 19.08.2014

[Pro14] Prodromou, Evan: pump.io-Wiki: pump.io API. (2014). https://github. com/e14n/pump.io/blob/master/API.md. – Abgerufen am 15.08.2014

[rec11] recht medien-internet-und: LG Berlin, Beschluss vom 15.03.2011 - 15 O 103/11. (2011). http://medien-internet-und-recht.de/volltext.php? mir_dok_id=2324. – Abgerufen am 15.07.2014

[Red14] Red., DiePresse: MySpace schrumpft monatlich um zehn Mio. Nutzer. (2014). goo.gl/aAg0i1. – Abgerufen am 15.07.2014

[RK08] Richter, Alexander ; Koch, Michael: Funktionen von Social-Networking- Diensten. 26 (2008), 28. goo.gl/RxZQwp

Seite 108 Kapitel 5 5 Quellenverzeichnis

[rob14] robinson jason: diaspora* statistics hub. (2014). http://pods. jasonrobinson.me. – Abgerufen am 30.06.2014

[Saw14] Sawall, Achim: Facebook betreibt Nutzerforschung wie mit Laborratten. (2014). http://goo.gl/nmI0A8. – Abgerufen am 15.07.2014

[Sch11] Schulz, Jakob: Facebook speichert sogar Gel¨oschtes 1.200 Seiten voller Per- sonendaten. In: TAZ (2011). http://www.taz.de/!79069/. – Abgerufen am 15.08.2014

[Sch13] Schwenke, Thomas: Teilen im Netz oder die rechtlichen Grenzen und Ge- fahren der Verwendung von User Generated Content bei Facebook, Google+, Youtube, Twitter, Instagram und Co. (2013). http://goo.gl/Z5xIeE. – Ab- gerufen am 01.08.2014

[Sch14] Schroder¨ , Jens: Top 20: die popul¨arsten sozialen Netzwer- ke in Deutschland. (2014). http://meedia.de/2014/03/27/ top-20-die-populaersten-sozialen-netzwerke-in-deutschland.– Abgerufen am 30.06.2014

[Sny14] Snyder, Bill: Snowden: The NSA planted backdoors in Cisco products. (2014). goo.gl/jBLPUo. – Abgerufen am 30.06.2014

[SS08] Stanoevska-Slabeva, Katarina: Web 2.0–Grundlagen, Auswirkungen und zukunftige¨ Trends. Bd. 2. 2008. – S. 13–38. http://goo.gl/cR72zd

[Thu14] Thun, Friedemann S.: Das Kommunikationsquadrat. (2014). www.schulz-von-thun.de/index.php?article_id=71. – Abgerufen am 15.07.2014

[Twi14a] Twitter: Allgemeine Gesch¨aftsbedingungen. (2014). https://twitter.com/ tos. – Abgerufen am 19.08.2014

[Twi14b] Twitter: Developer Rules of the Road. (2014). https://dev.twitter.com/ terms/api-terms. – Abgerufen am 19.08.2014

[Ulb11] Ulbricht, Dr. C.: Gef¨ahrliches Teilen ? – Haftungsrisiken beim Sharing uber¨ Facebook, Google Plus und Co. (2011). http://goo.gl/FiMybr. – Abgerufen am 01.08.2014

[Ulb13] Ulbricht, Dr. C.: Social Media Sharing Policy – Richtlinien fur¨ mehr Rechts- sicherheit beim Teilen auf Facebook , Google+ und Co. (2013). http: //goo.gl/FiMybr. – Abgerufen am 01.08.2014

Seite 109 Kapitel 5 5 Quellenverzeichnis

[Ulb14] Ulbricht, Dr. C.: Facebook ¨andert seine Terms of Service. (2014). http: //goo.gl/KzKM7l. – Abgerufen am 30.06.2014

[Ver14] Verlag, Heise: Facebook kauft WhatsApp. (2014 Abgeru- fen am 18.06.2014). http://www.heise.de/newsticker/meldung/ Facebook-kauft-WhatsApp-2118920.html. – Autoren: (spo) / (vbr) / (heb) / (jkj)

[WF14] Wikimedia Foundation, Inc.: Comparison of software and protocols for distributed social networking. (2014). http://en.wikipedia.org/wiki/ Comparison_of_software_and_protocols_for_distributed_social_ networking. – Abgerufen am 30.06.2014

[Wie14] Wiese, Jens: Das Problem: Facebook und die Klar- namenpflicht. (2014). http://allfacebook.de/policy/ das-problem-facebook-und-die-klarnamenpflicht. – Abgerufen am 15.07.2014

[WM08] Windisch,E; Medman, N: Understanding the digital natives. In: Ericsson Business Review 1 (2008), Nr. 2008, 36–39. http://goo.gl/VhMGdU

[Wyl14] Wyllie, Diego: Marktubersicht:¨ Soziale Netzwerke fur¨ Unternehmen im Ver- gleich. (2014). http://goo.gl/BrT2qT. – Abgerufen am 25.06.2014

Seite 110 Kapitel 5 Abkurzungsverzeichnis¨

Abkurzungsverzeichnis¨

AGB Allgemeine Gesch¨aftsbedingungen API Application Programming Interface FQDN Fully Qualified Domain Name D-A-CH Deutschland, Osterreich,¨ Schweiz DOS Denial of Service ESN Etabliertes Soziales Netzwerk IETF Internet Engineering Task Force JSON JavaScript Object Notation LIFO Last In – First Out (dt. zuletzt rein, zuerst raus) NSA National Security Agency P2P Peer to Peer REST Representational State Transfer RSS Really Simple Syndication TOS Terms of Service URI Uniform Resource Identifier

Seite 111 Kapitel 5 Glossary

Glossar

Aggregator Ger¨at, Software ¨o.A.,¨ mit dem automatisch etwas ausgew¨ahlt, zusammenge- stellt und zug¨anglich gemacht wird.9

API-Driven-Development Schnittstellen gesteuerte Programmierung bei der die Business- Logik im Vordergrund steht.. 29

B2B business-to-business. Eine Beziehungen zwischen Unternehmen. Im Gegensatz zu einer Unternehmensbeziehung zu einem End-Kunden (Business-to-Customer).2

Crossposting (auch Multiposting). Das gleichzeitige Verteilen bzw. Senden der selben Nachricht bzw. Beitrag an mehrere Ziele (z.B. Soziale Netzwerke).I

Diskussionsthread Diskussionsfaden bzw. Gespr¨achsfade. Klassischerweise in Foren und Online-Communitys. Ein Benutzer ¨offnet ein neuen Thread (Thema) und andere Nutzer antworten und nehmen Bezug auf die vorangegangen Nachrichten. Alle Bei- tr¨age zusammen ergeben einen Thread (engl. Strang)..4, 44

Employer Branding Unternehmerische Maßnahme (Marketing) sich als besonders attrak- tiver Arbeitgeber gegenuber¨ dem aktuellen oder zukunftigen¨ Arbeitnehmer darzu- stellen.4 hashen Mathematische Einwegfunktion die zu einem Eingabewert immer das gleiche Er- gebnis liefert. Aus dem Ergebnis soll sich die Eingabe nur schwer berechnen lassen. Auch Fallturfunktion¨ genannt.. 15 kritische Masse Aus der Spieltheorie bedeutet kritische Masse, dass nur eine bestimmte Anzahl an Personen einer Gruppe uberzeugt¨ werden muss einer Stragie zu folgen. Ist diese Masse erreicht, wird sich diese Strategie durchsetzen. Bei Sozialen Netzwerken fuhrt¨ der Effekt dazu, das Menschen sich eher bei etablierten Netzen anmelden als an Alternativen..I minimalinvasiv mit kleinstm¨oglichem Aufwand bzw. Ver¨anderung in etwas eingreifen. Hier: Den originalen Server-Code nicht grundlegend ver¨andern und um die Inter- operabilit¨at zu schutzen..¨ 70

Newsfeed ein Nachrichtenstrom von Neuigkeiten der meist chronologisch sortiert ist. Bei Facebook beispielsweise die Neuigkeiten aller Freunde.. 18

Seite 112 Kapitel 5 Glossary

OAuth OAuth ist ein offenes Standard-Autorisierungsprotokoll, mit dem Dritte auf Daten zugreifen k¨onnen, ohne das echte Passwort des Nutzers kennen zu mussen.¨ 29, 31, 71

REST Representational State Transfer ist ein Programmierparadigma fur¨ zustandslosig Webanwendungen.. 29

Social Media digitale Medien und Technologien die es Nutzern erlaubt, Daten zu erstel- len und untereinander auszutauschen.1,3

Social Network Sites Ein webbasierter Social Networking Dienst wie z.B. Facebook, Twitter und GooglePlus. 13

Social Software Software die der Zusammenarbeit und zwischenmenschenlichen Kom- munikation dient (z.B. soziale Netzwerke, Wikis, Blogs, Instant Messaging, Foren). 1,2,4,5

URI Uniform Resource Identifier ist ein eindeutiger Bezeichner fur¨ eine Ressource. Wird h¨aufig durch eine Zuf¨allige Zahlen- und Buchstabenkombination dargestellt. 29

User Experience Nutzererlebnis oder Nutzungserlebnis die der Anwender bei dem Um- gang mit einer Software wiederf¨ahrt. Werden Erwartungen an eine Software erfullt,¨ fuhlt¨ der Anwender sich wohl. Genau so hat der Anwender bestimmte Erwartungen an ein Produkt..7, 83

Web 2.0 Oberbegriff fur¨ ein interaktives World Wide Web.1

Wiki Webseiten, deren Inhalte von den Benutzern im Web-Browser nicht nur gelesen, sondern auch online direkt editiert werden k¨onnen. 50, 70

Seite 113 Anhang Anhang

Anhang

Abbildung 33: Flussdiagramm fur¨ den Abruf von Nachrichten aus etablierten Sozialen Netzwerken und Zustellung durch Stellvertreter

Seite 114 Anhang Anhang

Abbildung 34: Flussdiagramm fur¨ den Abruf von Nachrichten aus etablierten Sozialen Netzwerken und Zustellung durch einen repr¨asentativen Benutzer

Seite 115 Anhang Anhang

Abbildung 35: Login-Oberfl¨ache der pumpbridge. Beliebige pump.io-Accounts k¨onnen sich registrieren

Abbildung 36: Hauptseite der pumpbridge. Hier k¨onnen die jeweiligen Zugangsdaten fur¨ die etablierten Soziale Netzwerke hinterlegt und gel¨oscht werden

Seite 116 Anhang Anhang

Abbildung 37: Autorisierung-Mechanismus fur¨ die Verbindung der pumpbridge-App in Twitter

1 # Copyright (C) 2014 by Intevation GmbH 2 # Author: Mathias Gebbe 3 # 4 # This file is Free Software under the Apache License, Version 2.0; 5 # and comes with NO WARRANTY! 6 # See the documentation coming with pumpbridge for details. 7 8 = require(”underscore”) 9 async = require(”async”) 10 Facebook = require(”./facebook”) 11 Usermap = require(”./usermap”) 12 Google = require(”./google”) 13 Config = require (”./config”) 14 config = Config.config 15 Twitter = require(”./twitter”)(config) 16 17 databank = require(”databank”) 18 Databank = databank.Databank 19 DatabankObject = databank.DatabankObject 20 21 db = Databank.get(config.driver , config.params) 22 DatabankObject.bank = db 23 24 syncFromESN = ( ) −> 25 console.log ’syncFromESN’ 26 27 #### 28 # Facebook 29 t r y 30 Usermap.scan ((user) −> 31 if user.id.indexOf(’@facebook’) isnt −1 32 console.log ”start sync for facebook user” 33 Facebook.sync(user) 34 ) , ( e r r ) −> 35 c a t c h e r r

Seite 117 Anhang Anhang

36 console.log ’Facebook Error!’ + err 37 38 # T w i t t e r 39 t r y 40 Usermap.scan ((user) −> 41 if user.id.indexOf(’@twitter’) isnt −1 42 console.log ”start sync for twitter user” 43 Twitter.syncToESN(user) 44 Twitter.syncFromESN(user) 45 ) , ( e r r ) −> 46 c a t c h e r r 47 console.log ’Twitter Error!’ + err 48 49 # Google 50 t r y 51 Usermap.scan ((user) −> 52 if user.id.indexOf(’@google’) isnt −1 53 console.log ”start sync for google user” 54 Google . sync ( u s e r ) 55 ) , ( e r r ) −> 56 c a t c h e r r 57 console.log ’Google Error!’ + err 58 #### 59 60 r e t u r n 61 62 sync = ( ) −> 63 64 #Do this every xx minutes 65 c o n s o l e . l o g ’\ n\n\n’ + ”starting sync deamon” 66 interval = config.interval 67 i f not ( i n t e r v a l ? ) 68 i n t e r v a l = 15 ∗ 60 ∗ 1000 # 900 000 ms (15min) 69 async . w a t e r f a l l [ 70 ( c a l l b a c k ) −> 71 db.connect(config.params, callback) 72 ] , ( e r r , r e s u l t ) −> 73 setInterval syncFromESN, interval 74 syncFromESN ( ) 75 r e t u r n 76 77 sync ( ) Listing 3: Dienst (Deamon) der in einem bestimmten Zeitintervall die Synchronisation fur¨ Benutzer aus dem User-Mapping fur¨ das jeweilge Soziale Netzwerk startet

Seite 118 Anhang Anhang

Inhalt der CD

Inhalt der CD Pfad Beschreibung latex/* Latex-Ordner des Dokuments pumpbridge/* Repository-Ordner der Implementierung Masterarbeit.pdf Masterarbeit im PDF-Format

Seite 119 Eidesstattliche Erkl¨arung

Hiermit erkl¨are ich an Eides statt, dass ich die vorliegende Arbeit selbst¨andig und ohne fremde Hilfe angefertigt habe. Die aus fremden Quellen direkt oder indirekt ubernommenen¨ Gedanken sind als solche einzeln kenntlich gemacht. Es wurden keine anderen als die angegebenen Quellen und Hilfsmittel benutzt. Die Arbeit wurde bisher keiner anderen Prufungsbeh¨ ¨orde vorgelegt und auch nicht ver¨offentlicht.

Datum: ...... (Unterschrift)