Conference PaperPDF Available

SONIC: Bridging the Gap between Different Online Social Network Platforms

Authors:

Abstract and Figures

Online Social Network (OSN) platforms have become an important part of our everyday online lives. We communicate, share content, and organize meetings and events using social platforms and services. However, even though there is a strong trend towards OSN services to become the main communication medium, most OSN platforms are still proprietary, closed services that keep users from connecting directly and seamlessly to the services of other OSN platforms. The resulting lock-in effects are intentionally created by OSN operators, as their business models are built mostly on targeted advertisement services. While open and decentralized communication protocols exist for most other aspects of digital social interaction, there are only few micro-standards and protocols in existence for the social web. A holistic standard is yet missing. We envision a truly open and decentralized ecosystem of OSN platforms, where users are not cut off from friends using other social platforms and can freely migrate from one OSN platform to another at any time without losing established relationships in the social graph. This would allow users to freely choose an OSN platform of their liking instead of being limited in their choice to the platform used by one's friends. In this paper, we give an overview about the SOcial Network InterConnect protocol (SONIC), a novel social protocol for seamless social cross-platform communication. SONIC proposes a decentralized and heterogeneous Online Social Network Federation (OSNF), in which platforms are connected via a communication protocol. This allows different OSN platforms to seamlessly communicate with each other, while giving users the ability to migrate social profiles between platforms on demand without losing previously established connections to other user profiles.
Content may be subject to copyright.
SONIC: Bridging the Gap between Different Online
Social Network Platforms
Sebastian G¨
ond¨
or, Felix Beierle, Senan Sharhan§, Hussam Hebbok, Evren K¨
uc¨
ukbayraktarand Axel K¨
upper
Telekom Innovation Laboratories, TU Berlin
Service-centric Networking
Ernst Reuter Platz 7, 10587 Berlin, Germany, Tel.: +49 30 835358166
Email: sebastian.goendoer@tu-berlin.de, beierle@tu-berlin.de, §senan.mh.sharhan@campus.tu-berlin.de,
§hussam.hebbo@campus.tu-berlin.de, evren.kuecuekbayraktar@campus.tu-berlin.de, axel.kuepper@tu-berlin.de
Abstract—Online Social Network (OSN) platforms have
become an important part of our everyday online lives. We
communicate, share content, and organize meetings and events
using social platforms and services. However, even though there
is a strong trend towards OSN services to become the main com-
munication medium, most OSN platforms are still proprietary,
closed services that keep users from connecting directly and
seamlessly to the services of other OSN platforms. The resulting
lock-in effects are intentionally created by OSN operators, as
their business models are built mostly on targeted advertisement
services. While open and decentralized communication protocols
exist for most other aspects of digital social interaction, there
are only few micro-standards and protocols in existence for the
social web. A holistic standard is yet missing. We envision a
truly open and decentralized ecosystem of OSN platforms, where
users are not cut off from friends using other social platforms
and can freely migrate from one OSN platform to another at
any time without losing established relationships in the social
graph. This would allow users to freely choose an OSN platform
of their liking instead of being limited in their choice to the
platform used by one’s friends. In this paper, we give an overview
about the SOcial Network InterConnect protocol (SONIC), a novel
social protocol for seamless social cross-platform communication.
SONIC proposes a decentralized and heterogeneous Online Social
Network Federation (OSNF), in which platforms are connected via
a communication protocol. This allows different OSN platforms
to seamlessly communicate with each other, while giving users the
ability to migrate social profiles between platforms on demand
without losing previously established connections to other user
profiles.
I. INTRODUCTION
The rise of the social web, which started with web plat-
forms such as Classmates.com,Sixdegrees, and Friendster,
began in the middle of the 1990’s by allowing users to link to
other individuals in order to model and maintain relationships
of former friends or classmates. The idea of modeling social
connections between individuals in a web service was extended
by MySpace in 2003. The service featured detailed and highly
personalized profile pages, on which users could not only
provide information about themselves, but could also add
further content such as images, music files, and videos - or
even blogs and user groups.
As of today, Online Social Networks (OSN) have become
one of the main communication platforms, allowing users to
communicate via text, audio, and video, share content, or just
stay in contact with friends and relatives. While a large number
of competing OSN platforms with a broad variety of features
exist as of today, Facebook, which was founded in 2004,
managed to overcome its predecessors and competitors by far
in terms of number of users and popularity [1]. This forced
many competitors to focus on niche markets such as modeling
relations to business partners (e.g. LinkedIn and Xing), or to
address different aspects of social interactivity (e.g., commu-
nication via WhatsApp) or activities (e.g., publishing images
via Instagram).
OSN platforms are nowadays mostly organized in a cen-
tralized manner, which forces their users to not only entrust
all personal information to a single platform operator, but
also to surrender copyrights. The personal data is then used
e.g. for targeted advertisement or other forms of monetization
with little or no control for users regarding how and what
private information is used. The resulting consequences in
terms of privacy and being locked-in by the OSN platform
bother most users as control over one’s data privacy is lost
[2][3][4]. This led to the development of decentralized OSN
architectures and systems such as the open source applications
Diaspora1or Friendi.ca2that allow users to host their own
data at an arbitrary server. Diaspora is based on a set of open
standards and protocols such as WebFinger, but still fails to
facilitate a seamless communication with arbitrary other OSN
platforms [5]. To overcome this problem, many OSN platforms
support specialized plugins that connect to OSN accounts on
other OSN platforms via their respective - mostly proprietary
- APIs and consolidate content such as status updates or
friend lists in one web service or application [6]. Anyhow, this
requires users to maintain an account at each connected OSN
platform. Data, such as status updates, is then automatically
synchronized between all connected platforms, which eases the
process of managing multiple social accounts, but does not
solve the problem of privacy concerns. Furthermore, seamless
interaction such as group communication or commenting on
content with two or more users from different OSN platforms
is not possible [7].
The current trend of OSN platforms becoming the main
social communication medium causes severe changes in busi-
ness models of even big companies such as telecommunication
providers [8], since revenue from traditional services such
as voice calls and short message service (SMS) are losing
significance. Yet unlike for established forms of digital human-
to-human communication such as email or instant messaging,
1Diaspora: http://joindiaspora.com
2Friendi.ca: http://friendica.com/
there is no common and holistic standard for interaction of
online social networks, even though features of such services
tend to be very similar. As of this, players such as Facebook are
able to keep their users, following the well known principle of
the rich get richer: As migrating to other OSN platforms would
cut of the digital connections to our friends and relatives,
everyone stays with the biggest player. Potentially new users
don’t have a real choice when choosing a platform, as they are
pressured to join the platform their friends are already using. A
common and open standard that interconnects all participating
OSN platforms would weaken the market position of all too big
players such as Facebook and therefore allow other platforms
to attract more users.
In this work, we present the SOcial Network InterConnect
protocol (SONIC), which proposes an open and decentralized
OSN ecosystem, in which users can freely communicate with
each other - even when communication partners are hosted
on different types of OSN platforms. In order to bridge the
gaps between existing OSN platform implementations, the
fact that a user’s profile is hosted on another server should
be kept transparent when communicating. The architectural
requirements for the SONIC federation have been defined in
[7][9], comprising a decentralized architecture, the use of open
protocols and formats, the option for users to migrate their
social accounts, seamless communication, the use of a single
social profile, and global user identification. The remainder of
this paper is organized as follows: The next section provides an
overview about existing approaches, protocols, and standards
in the area of distributed OSN. Chapter III gives a detailed
description of the concept of the SONIC federation and defines
the feature set of the SONIC federation. Chapter IV describes
the architecture of the SONIC federation, while Chapter V
gives an overview about the actual protocol. Chapter VII
concludes the paper.
II. RE LATE D WORK
Faced with the task of addressing privacy issues of centrally
organized OSN platforms, Applequist et al. proposed a concept
where users maintain a central repository of their data, which
can be connected to multiple OSN platforms [10]. Following
this approach, users can determine to which connected OSN
platform what content should be synchronized, so that multiple
types of OSN platforms can be maintained simultaneously via
one central service. This allows a logical separation between
a professional OSN profile such as Linked.in and a more
personal one such as Facebook. This eases the user experience
for users who are active in more than one OSN, yet OSN
platform operators still get access to most of your personal
information. Furthermore, users are forced to maintain user
accounts on each connected platform, to which new content is
then pushed. Distributed alternatives such as Friendi.ca or Di-
aspora proposed alternative architectures, where social profiles
of users are stored on arbitrary servers. Social communication,
e.g. messages or status updates, is carried out using special pro-
tocols to bridge the gaps between servers called Pods [6]. Other
approaches tried to eradicate the use of centralized client-
server architectures by implementing peer to peer technology.
Examples are PeerSoN, which uses a Distributed Hash Table
(DHT) to replicate profiles and related data to other devices in
order to maintain availability even when a participant’s device
is turned off [11][12], or TRIBLER, which is based on the
popular peer-to-peer software Bit Torrent to benefit from its
superior content discovery and recommendation mechanisms
[13]. Safebook, which was proposed by Strufe et al. focuses
on privacy and security aspects in peer-to-peer-based social
architectures. Here, information about a user’s location in the
network is replicated to other trusted peers forming logical
shells around each user referred to as the Matryoshka. Requests
to a user’s data have to pass through these shells, so each user’s
privacy is enforced using multi-hop communication links [14].
Other research proposed to design OSNs as mobile hosted
applications [15], e.g. POLARIS [16] or VEGAS [17]. Here, a
user’s personal mobile device is used to store social profiles as
well as access social profiles of other users. Even though these
approaches mitigate or eradicate the influence and knowledge
of a central OSN platform operator about personal information,
they all propose again semi-closed solutions and ecosystems,
in which users are still hindered from connecting to other OSN
platforms.
A. OSN Protocols
Today, most OSN platforms provide an API to allow
developers of third party applications and services to con-
nect to the OSN, thus creating well integrated solutions. For
example, Facebook allows external services to connect to
the platform via its Facebook Graph API3, which comprises
nodes representing items or persons, edges connecting nodes,
and fields that describe attributes of nodes. Most other OSN
platforms offer similar functionality but differ in the details.
For example, Google+ defines four resource types to be used
in its API, being people,activities,comments, and moments4,
while Twitter provides an extensive REST-based API to their
services. To access the API’s functionality, each external
application or service needs to register with the platform first
and is assigned a unique API key to authenticate itself with
each session or request. As most OSN platforms provide their
own proprietary API which developers have to use, lock-in
effects are created due to the extensive efforts required to adapt
an application or service to a certain API. While most OSN
platforms provide an API for external services to integrate
themselves into the OSN platform, other approaches focus on
open and distributed solutions. In 2010, Facebook introduced
the Open Graph Protocol with the intent to include web pages
into the social graph. The standard was inspired by Dublin
Core and makes use of RDFa to enrich a web page with
semantic information that describes the web page’s contents
[18][19].
In order to ease the process of adapting applications and
services to multiple OSN platforms for developers, Google
proposed to agree on one standardized social API. The stan-
dard would enable application developers to implement against
one standard set of APIs, allowing the resulting applications to
work with any OSN platform. OpenSocial, which was initially
released in 2007, comprises a set of interfaces for applications
and services to access data of any kind of OSN platform
[20]. By implementing OpenSocial interfaces, OSN platforms
provide a uniform standard API for social applications, so
that the same application can be used within multiple OSN
3Facebook Graph API Reference: https://developers.facebook.com/docs/
graph-api
4Google+ API Reference: https://developers.google.com/+/api/latest/
platforms without the need to adapt a new set of APIs to
support each new OSN platform. For this purpose, OpenSocial
defines distinct protocols for data,people, and activities,
which allow access to the respective functionality. Even though
OpenSocial defines a common social API, seamless commu-
nication between different OSN platforms is not supported.
As OpenSocial focuses on APIs for social applications, the
standard supports Gadgets to render the content. Shindig5a
reference implementation is provided by the Apache Founda-
tion. As of 2015, work on the OpenSocial standard has been
taken over by the W3C Social Web Working Group.
Other approaches focus on more basic details, such as
providing a common way to exchange status updates without
being bound to a specific platform. One good example is
ActivityStreams 2.0, which is an open and extensible standard
for describing activities comprising types,actors, and objects.
This way, ActivityStreams are ”semantic descriptions of a
completed or ongoing action” [21]. The standard is based on
JSON and is easily extensible. OStatus, which was originally
designed for microblogging services is an open standard for
exchanging status messages. The standard defines an XML-
based data format and implements PuSH as distribution mech-
anism [22]. Even though its functionality is limited, OStatus
has been integrated into several existing OSN platforms such
as Friendi.ca,Lorea,Duuit!, and SocialRiver.
Several other social protocols aim at connecting social
profiles on different servers, but only cover certain aspects.
One example is Tent.io, which is a protocol for evented data
storage that allows users to subscribe to status updates from
other users. The architecture proposes a similar subscription
mechanism as PuSH and is based on HTTP and JSON [23].
For the domain of text-based real-time communication, the Ex-
tensible Messaging and Presence Protocol (XMPP) facilitates
instant message exchange in an open and decentralized manner
[24]. While XMPP originally focused on instant messaging,
hundreds of extensions have been implemented for other
uses, including OSN support6.Friend-of-a-Friend (FOAF) is
a standard to model relationships between individuals using
RDF [25]. The format is used within the protocol FOAF+SSL
[26] for secure authentication of communication partners. Indi-
viduals are identified using an X.509 certificate and a WebID.
WebID is used to publish information related to an individual
using a dedicated URL in a profile document [27]. Each WebID
profile is an RDF document that describes a person or entity
associated with this document. For the domain of describing
individuals, Portable Contacts provides a simple and elegant
way to describe address books and persons. The specification
supports JSON and XML and also defines authorization and
access patterns [28].
A more comprehensive protocol called Distributed Friends
& Relations Network (DFRN) was introduced in 2010 by Mac-
girvin, which was designed ”to provide an open and distributed
social communication platform with server requirements com-
parable to that of a typical hosted blog” [29]. The protocol is
based on the Atom Syndication Protocol and provides polling
and pushing of content between DFRN compliant servers. The
distributed OSN platform Friendi.ca was originally built as
5Apache Shindig: http://shindig.apache.org/
6OneSocialWeb: http://onesocialweb.org
a reference implementation for DFRN. As the protocol was
considered as too ”cumbersome” by the Friendi.ca developers,
development of an alternative protocol called ZOT was initi-
ated. ZOT was designed to connect different OSN platforms
by using publicly available APIs and protocols. In 2012, ZOT
was discontinued because of tendencies of centralized OSN
platforms to apply ”strict limits to outside services accessing
their proprietary platforms” 7.
Even though social features such as commenting, express-
ing appreciation, messaging, or sharing content has become
an integral part of the social web we know, integration of
such features as of today is only possible by implementing
against proprietary APIs. Even more severe impairment is the
requirement for users to maintain an account on each OSN
platform that should be used. For example, liking content
requires to be logged in with Facebook. This requires users
to maintain social user accounts on multiple OSN platforms.
B. OSN Featuresets
Even though today’s OSN platforms differ in their provided
functionality, architectural approaches, privacy and security
concepts, or API model, most functions are equivalent or at
least similar. This allows to derive a generalized featureset
of today’s OSN platforms to provide a better definition of
social features. Heidemann et al. defined core functionalities
of OSN platforms, which are user profiles, subscription to
interest groups, and personal contacts [30], while classifying
OSN platform based on three criteria: primary usage (private
vs. business), focus (general vs. special interest), and access
(open vs. closed) [31]. Rohani and Hock proposed a general
featureset of social web sites describing a personal profile,
communication with peers, a personal bill board, a thinking
room, an e-newsletter, a friendship network, and forums [32].
Richter and Koch proposed a rather high level approach by
defining a list of six basic functions of social networking
sites, which can be narrowed down in the two basic categories
keeping in touch and identity management. The basic func-
tionality comprises identity management (presenting oneself),
expert search (searching the network for specified criteria, or
receiving recommendations), context awareness (discovering
common interests), contact management (tagging people and
defining access restrictions), network awareness (receiving
status updates about activities of other’s), and exchange (being
direct communication, e.g. instant messaging) [33]. Boyd and
Ellison derived a general featureset of social networking sites
in 2007, comprising semi-public profiles,connections to other
users, and traversing this list of connections [34]. In 2012,
Paul et al. defined both a basic and an extended feature set
for OSN services from an architectural point of view. Here,
basic functionality comprises profile management,relationship
handling, and interaction, i.e., messaging and sharing content.
Extended features include APIs or search and recommenda-
tion functionality. OpenSocial’s approach to build a common
API for arbitrary OSN platforms required a common set of
resources application developers could access as well as data
formats that would fit to all kinds of OSN platforms. Here,
OpenSocial defines data formats and RPC calls for People,
Groups,Activity Streams,AppData,Albums,MediaItems, and
Messages [20].
7The Friendi.ca Blog: http://friendica.com/node/24
III. THE SONIC OSN FE DE RATI ON
Today’s OSN platforms are mostly closed solutions, which
disallow users to connect to and communicate freely with
other platforms and services. Solutions proposed to address
and mitigate these issues mainly proposed either alternative
centralized OSN platforms themselves or rely on federated or
completely decentralized architectures. All proposed alterna-
tives have in common that users need to create a new user
account within the new system, while seamless interaction with
other OSN platforms is mostly still not possible. The motiva-
tion for users to abandon one closed system for another closed
solution is therefore limited. In contrast to the approaches
mentioned above, SONIC proposes a different paradigm. Here,
a common protocol is used to allow different kinds of OSN
platforms to interact directly. Following this approach, OSN
platforms support a common API and protocol, which allows
to exchange social information across platform borders, while
addressing remotely hosted user accounts directly. This way,
users can choose the OSN platform they prefer while staying
seamlessly connected to all friends using other OSNs. Hence,
it is rendered irrelevant whether a user’s friends are using the
same or a different OSN platform. The result is an Online
Social Network Federation (OSNF) defined as a heterogeneous
network of loosely coupled OSN platforms using a common
set of protocols and data formats in order to allow seamless
communication between different platforms [7].
Figure 1 depicts the concept of SONIC. A user (Alice)
accesses the user interface of her OSN Platform A using
a web browser, mobile application, or other interface. For
Alice, it is not important whether her friends use the same
OSN Platform or not. Her OSN platform server retrieves
all relevant information for her in the background directly
from her friends’ OSN Platforms B and C using the SONIC
protocol. The retrieved data (e.g., status updates or profile
pages) are transmitted in a standardized data format and are
integrated seamlessly into the view of the user interface Alice
is using. This builds a foundation for an open and decentralized
OSN ecosystem with no lock-in effects, in which any kind of
OSN platform can participate while control over one’s personal
information is not necessarily given to a central authority.
Prerequisites for an OSNF ecosystem have been defined in
[7] comprising a decentralized architecture, the use of open
Fig. 1. Federation in SONIC: Information from other user’s (remote) Social
Profiles is directly embedded into the user interface. This closes the gap
between different OSN platforms.
protocols and formats to facilitate seamless communication
between platforms, allowing migration of user accounts to
other OSN platforms [9] while not forcing a user to sign up
with more than one OSN platform at once, i.e. having a single
profile, which is identifiable across platform borders using
global user identification. By implementing SONIC, barriers
between existing OSN platforms will be mitigated by allowing
transparent inter-platform communication. Users will still be
able to use the OSN platform they are used to in the same
way as before.
A. Core OSN Featureset
The task of defining a common standard for multiple
OSN platforms requires to interconnect different features and
formats of existing platforms. Even though today’s OSN
platforms differ in their provided functionality, architectural
approaches, privacy and security concepts, or API models,
most functionality is semantically equivalent or at least similar.
This allows to derive a generalized featureset of today’s
OSN platforms to provide a better definition of existing
OSN functionality. Based on the identified featuresets of
other researchers as described in Section II-B, APIs and the
general functionality of today’s most popular OSN platforms
have been analyzed. The analyzed platforms comprise Face-
book,Google+, the distributed and open source approaches
Friendi.ca and Diaspora, the Russian network vKontakte, the
Chinese platform RenRen, the business platforms Xing and
LinkedIn, and the micro-blogging platform Twitter. Looking at
the provided APIs and user interfaces of these OSN platforms,
the following list of general features has been identified8:
Profile page A personalized profile page with information
about a user.
Adding/following friends Ability to add other users to a
list of friends or acquaintances.
Instant Messaging Exchanging text messages with other
users.
Multiuser Instant Messaging Engaging in group commu-
nication with more than two other users.
Posting status updates Publishing posts about activities
in a stream for others to watch.
Sharing content Notifying others about content (e.g. a web
page) by posting it in a stream.
Liking content Expressing that you appreciate or value a
content object.
Commenting on content Posting a textual comment on
other content for others to read.
Tagging Tagging people in content who are associated with
the content.
Image galleries Publishing images and managing them in
image galleries.
Event organization Inviting other users to events.
Groups Defining specific groups of users.
Poking Sending a poke with no fixed semantic meaning to
another user.
8The analyzed features are limited to features involving exchange of data
between two or more users. Features that do not effect other users’ profiles
are not considered, e.g. categorizing users in local user groups.
Further features can be found in only few, mostly special-
ized OSNs, comprising for example rating content or voting.
Table I gives an overview about what features are supported
by which network. By analyzing the features of popular OSN
platforms, a list of features can be derived, forming a core
featureset, i.e. they are supported by almost all OSNs. These
features comprise a profile page,adding or following friends,
(multiuser) instant messaging,posting and sharing content e.g.
status updates, liking content,commenting on content, and
tagging users in content. The SONIC protocol is designed to
support this core featureset, while optional protocol extensions
will facilitate supporting additional features between OSN
platforms.
IV. SONIC ARCHITECTURE
SONIC promotes an open and decentralized OSNF, in
which different OSN Platforms are loosely coupled. Users
maintain Social Accounts, comprising the associated Social
Profile and a Social Record. While Social Profiles, which are
a collection of all data associated with a user account are
hosted on a Platform,Social Records, comprising information
about how to retrieve a certain Social Profile.Social Profile are
stored in a decentralized directory service called Global Social
Lookup System (GSLS). This section defines and describes the
architectural components, roles, and concepts of the SONIC
OSNF.
Social Account In SONIC, every user maintains a Social
Account, comprising the aggregation of all information and
resources associated with this user’s account, including the
Social Profile and Social Record.
Social Profile ASocial Profile describes content associated
with a Social Account, which can be accessed by other
users. This comprises data such as name, date of birth, or
gender, but also other content such as images, exchanged
messages and comments, or connections to other Social
Accounts.
Social Record ASocial Record is a dataset that comprises
all information that is required to uniquely identify and
locate a Social Account.
A. Roles
In the SONIC OSNF users maintain Social Accounts,
which they use to access or create content. Content is encap-
sulated in data objects with a standardized data format. Here,
the following roles have been defined:
Author The Author of any content is the user who initially
created it. Information about authorship is indicated for
every content object by a globally unique identifier, the
Global ID.
Owner Content is stored within the Social Profile of a
user, who gains ownership for this content. In some cases,
content is stored within the Social Profile of a user who is
not the content’s Author. Comments on user Bob’s status
updates for example are stored within Bob’s Social Profile,
although he is not the Author (see Section IV-C).
Viewer AViewer is a user accessing any content object.
Depending on the access permissions set by the content’s
Owner, different Viewers will be provided with different
content. For example, as a close friend of Bob,Alice might
see different content when accessing his profile.
Provider The Provider runs a Platform, on which one or
more Social Profiles are hosted.
B. Architectural Components
The proposed SONIC protocol connects different OSN
servers via loose coupling. The RESTful request/response
protocol is based on HTTP and uses JSON to exchange content
and messages. To verify the authenticity of content from a
remote OSN platform, public key cryptography is used to
digitally sign exchanged content as well as requests. In SONIC,
befriending another user involves the exchange of IDs as well
as public keys. The process is carried out using a central
directory service that stores the Social Records of all users.
Social Records contain all relevant information for connecting
to another user’s Social Profile. The protocol does not cover
server-to-client communication, i.e. how content is delivered
to a user’s social application. The following architectural
components are defined in SONIC:
Platform APlatform, as depicted in Figure 2, is a web
service that runs the business logic, i.e. provides OSN
functionality as described in Section V. The platform hosts
and manages Social Profiles and allows users to access
their Social Accounts via a user interface, e.g. a mobile
application or web page. A Platform is required to support
the core featureset and provides an API for the SONIC
protocol to allow cross-platform communication. Each
Platform’s API must be accessible for other Platforms. In
addition to that, Platforms support an interface to connect
to the GSLS.
Client AClient is an application that is used to access a
Platform’s user interface, e.g. a website or mobile appli-
cation.
GSLS The Global Social Lookup System is a peer-to-peer-
based directory service that stores and manages the Social
Records of all users in SONIC. The GSLS provides a
RESTful interface for retrieving, creating, updating and
deleting Social Records, while cryptographic signatures
prevent forged data records [7].
As stated in Section III, one requirement of SONIC is the
possibility to migrate user accounts between different OSN
Fig. 2. A SONIC Platform hosts Social Profiles of users and provides OSN
functionality. Users can access this functionality via the user interface of the
Platform. The Platform is connected to the SONIC OSNF via the SONIC
API, while discovery of other user’s Social Profiles is facilitated by the GSLS
TABLE I. COMPARISON OF FEATURES OF POPULAR OSN PLATFORMS
Feature description Facebook Google+ Friendi.ca Diaspora vKontakte RenRen Xing LinkedIn Twitter
Profile page
Adding/following friends
Instant Messaging #
Multiuser Instant Messaging ## #G#
Posting status updates
Sharing content
Liking content G#
Commenting on content
Tagging #
Image galleries # ###
Event organization ## ##
Groups ## #
Poking users ########
feature is supported G# feature is supported with limitations #feature is not supported
platforms. This requires a common standard for social user
accounts, which is logically decoupled from the business logic
of the OSN Platform. Therefore, in SONIC all data associated
with a user account is encapsulated in Social Accounts, which
comprises both the actual profile data as well as further
information for e.g. profile lookup.
C. Privacy concept
All content in SONIC is encapsulated in content objects
with a standardized format and stored within the Author’s
Social Profile. Hence, content is stored at the user’s OSN
Platform giving him full control over the distribution of his
content. For access control, each OSN Platforms needs to
implement access control schemas. This allows users to specify
who is permitted to access what parts of their Social Profiles.
If anyhow content is related to another content object, which is
stored in another Social Profile, it is attached to this object and
stored alongside it. As of this, depending on the location of the
referenced content object, content can be stored in a remote
Social Profile. For example, a comment by a user Alice on a
post of a user Bob is stored as an attachment to the post of
Bob within Bob’s account. In this scenario, even though Alice
is the Author of the comment, Bob becomes it’s Owner and is
responsible for storage and delivery of the data. This allows
users to maintain full control over who can access what part
of their personal information while giving authors full control
over what content is published related to their content (e.g. a
discussion on a status update).
Sonic distinguishes between local and remote content ob-
jects. While local content is always stored at the Author’s
Platform, remote content may be stored in a remote Social
Profile. To ensure that remote content is not altered by the
Owner, remote content objects are signed by the Author. To
uniquely identify content across Platforms, a unique Object
ID is assigned to every content object. Remote content object
are attached to other content objects by specifying a Target ID
referring to the Object ID of the associated content object.
Local Content Content which is stored within the Social
Profile of its Author is classified as Local Content. As the
content’s Owner is also its Author, he may edit or delete
it when necessary. Integrity and origin of the content can
be verified by a signature created by the Author.
Remote Content Content, which is associated with content
stored within the Social Account of another user. It is stored
as an attachment to its target content object, i.e. as part
of the Social Profile of the Owner of the content. As this
content is then owned by somebody other than the content’s
Author, a digital signature is created using the Author’s
Account KeyPair. This way, the content’s integrity can be
verified.
D. Social Record
As migrating Social Profiles to other Platforms would
result in a change of the URL of a profile, links to other users’
Social Profiles would break. Hence, SONIC uses a domain
independent, globally unique identifier for Social Accounts -
the Global ID - which is kept intact during the migration
process. The Global ID is stored with information about
aSocial Profile’s current location and proof of authenticity
and integrity in the Social Record. The GSLS, which stores
the Social Records of all users serves as a central directory
service. The Global ID is derived directly from an RSA
public key using the key derivation function PBKDF2 [35]
and a salt of fixed length. The RSA key pair is also used to
digitally sign the Social Record, rendering forgery of a Social
Record is prevented. This way, Global IDs are directly bound
to the public key of a Social Account. SONIC makes use
of two different key pairs, which are used to sign content,
requests, and responses to verify the authenticity and integrity
of messages.
Account KeyPair The Account KeyPair is used and man-
aged by the Platform to sign content created by the account
owner as well as requests and responses. This requires that
the private part of the Account KeyPair is entrusted to the
platform.
Personal KeyPair The Personal KeyPair is used to create
the Global ID of a Social Account and sign the Social
Record. As it is required for revocation and exchange of
the Account KeyPair, it should be kept secret and shouldn’t
be made accessible to the Platform.
As the Account KeyPair is used to sign content, requests,
and responses in the SONIC OSNF, the Platform is required
to store and manage the key pair. Both the personal and the
account public key are included in the Social Record. The
Personal key is used to create the Global ID. In order to allow
revocation of the Account KeyPair, the Personal Keypair is
used to both create the Global ID and sign the Social Record.
This way, the Global ID remains unchanged when the Account
KeyPair needs to be revoked. Revocation information is stored
in the Social Record and signed using the Personal KeyPair.
V. TH E SONIC PROTOCOL
The Sonic API provides access to the relevant resources of
a social profile using a REST-like design. The protocol covers
Platform-to-Platform communication for retrieving or pushing
content to remote Social Accounts. As SONIC does not define
any constraints how to display or utilize the exchanged infor-
mation, Platforms are free to deliver content (e.g. a list of status
updates received from multiple connected Social Accounts) to
their users in any way. SONIC only defines a protocol and
data formats defining how social information is exchanged
between Platforms. This way, Platforms are free to provide
any user experience they want, while allowing their users to
stay connected to other users on different Platforms.
For authentication purposes, a set of HTTP request and
response headers are specified that are used to transfer addi-
tional information required to correctly process a request. This
includes the targeted API version of SONIC, a timestamp, the
Global ID of the Social Account that initiated the request, and a
digital signature. Content transferred with a request is required
to be formatted according to the specifications of the SONIC
API.
A. SONIC API
The SONIC protocol provides access to business logic of a
Platform. Here the core featureset as defined in Section III-A,
comprising resources link (adding friends), profile (profile
page), stream (posting and sharing content), comment (com-
menting on other content), like (liking content), tag (tagging
people in posts), and conversation (instant messaging).
1) LINK: The resource link provides access to all data
associated with links to other Social Accounts. This includes
accessing the friends roster, which lists the Social Accounts
a user is linked to. Furthermore, new connections to other
Social Accounts can be initiated by sending a signed link
request object. Here, each Platform is responsible for defining
access permissions, i.e. allowing or denying access to different
resources of a user’s Social Profile once the request has been
accepted. Platforms may implement different authorization
schemes. In SONIC, links between two Social Profiles are
unidirectional.
2) PROFILE: The resource profile allows access to other
users’ Social Profiles. Similar to OpenSocial’s Person, a
SONIC profile object comprises an extensive list of informa-
tion related to the Social Profile’s owner. While only a few
attributes such as Global ID or displayName are mandatory,
an extensive list of other optional attributes can be specified.
This includes a user’s date of birth, gender, or relationship
status.
3) STREAM: The stream resource comprises reading, cre-
ating, updating, and deleting activities such as status updates
or shared content. Activities are Activity Streams 2.0 objects
with additional mandatory attributes describing signature, and
information identifying the content’s Author. Users may post
activity objects to another user’s stream resource, while the
targeted Social Profile Owner may define rules to allow or
deny the incoming request. This allows Platforms to assemble
a stream of activities from linked Social Profiles.
4) COMMENT: The resource comment allows to create,
retrieve, update, and delete comment objects. Comment objects
contain a textual comment message, the date of creation,
data identifying the comment’s Author, and a Target ID that
specifies the content commented on. Comments are posted in
relation to content objects (e.g., a status update) and are linked
to this content object via a Target ID. A comment is stored
within the Social Profile of the Owner of the targeted content.
As comments are usually linked to content from other users,
they need to be signed by the Author. This way, any Viewer
of the comment is able to verify its integrity and authenticity.
5) LIKE: The resource like allows to retrieve, create, or
delete like objects. Similar to comment objects, likes are posted
related to other content objects (e.g., a status update) and are
linked to this content object via a Target ID. Likes are stored
within the Social Profile of the Owner of the targeted content
and need to be signed by the Author.
6) TAG: The resource tag allows to link users to content,
indicating that the linked user is somehow related to the
content. Tag objects can be created by any user and are stored
within the Social Profile that contains the content the person
is tagged in.
7) CONVERSATION: The resource conversation com-
prises textual messages exchanged between two or more
individuals. A conversation encapsulates a list of messages,
which are broadcast by their Author to all members of the same
conversation, thus facilitating multiuser chat as well as private
conversations. Further control messages are used to control the
conversation state, e.g., users joining or leaving the conversa-
tion. This way, all participants of a conversation receive the
same messages, allowing them to synchronize the state of the
conversation between all communication participants.
VI. IMPLEMENTATION
The described protocol has been implemented in the open
source OSN Friendi.ca, effectively replacing the native DFRN
protocol. While the user interface and user experience of
Friendi.ca remains unchanged, requests to other social pro-
files hosted on compatible platforms are performed using the
SONIC protocol. Furthermore, a SONIC prototype has been
implemented using the PHP framework Laravel. For evaluation
purposes, the approach has been set up in a testbed with three
servers, of which two run the adapted Friendi.ca version and
the third the SONIC prototype. User accounts have been set up
on all three servers to evaluate the effectiveness of the SONIC
approach. Results show that the described protocol allows OSN
platforms to interact with any other OSN platform given the
assumption that all participating platforms support the SONIC
protocol. Hence, users are no longer forced to maintain user
accounts in more than one OSN and are able to create and
maintain connections to other users across platform borders.
The features supported by the SONIC protocol represent the
core featureset, which has been derived by analyzing features
and APIs of today’s popular OSN platforms. Analysis of
requests to other user accounts showed that by integrating the
SONIC protocol into Friendi.ca, the average response time or
requests between user accounts on different Friendi.ca servers
was reduced by 54.92% compared to DFRN-based requests.
At the same time, the average payload size of DFRN-based
requests (6.8KB on average) was reduced by 52.8%.
VII. CONCLUSION
With the ongoing trend towards communicating via OSNs,
there is a strong need for open protocols and standards
in this area. Yet, current OSN platforms are mostly closed
and proprietary solutions, which create well-calculated lock-in
effects to bind users to the service. The majority of existing
social APIs is not standardized and most of them offer only
limited access to the platform’s full functionality. We believe
that OSNs can only become the main communication medium
with open protocols and standards, which allow seamless inter-
platform communication. While several open solutions and
protocols have emerged over the last decade, they cover only
certain aspects of decentralization of OSN functionality, e.g.,
exchanging status messages. SONIC proposes a holistic ap-
proach that facilitates seamless connectivity between different
OSN platforms, thus building the foundation for an open
and heterogeneous Online Social Network Federation. In this
paper, we presented the architecture of the SONIC OSNF and
provided an overview of the federation protocol. The protocol
supports a core featureset of today’s popular OSN platforms,
while protocol extensions may be implemented to support
additional features. By implementing the proposed protocol,
OSN platforms can open their services and allow users to
communicate with other OSN platforms. This would solve
current problems of closed and proprietary OSN platforms
such as lock-in effects or privacy issues. Using SONIC, users
can freely choose an OSN platform of their liking and even
migrate to another platform at a later time without losing any
data or existing connections to other profiles.
ACKNOWLEDGMENT
The work described in this paper is based on results of ongoing research as
part of the research project SONIC (grant number 01IS12056). The project’s
web page is accessible at http://sonic-project.net. SONIC is funded as part of
the SoftwareCampus initiative by the German Federal Ministry of Education
and Research (BMBF) in cooperation with EIT ICT Labs Germany GmbH.
REFERENCES
[1] J. Ugander, B. Karrer, L. Backstrom, and C. Marlow, “The Anatomy
of the Facebook Social Graph,” arXiv preprint arXiv:1111.4503, 2011.
[2] A. Datta, S. Buchegger, L.-H. Vu, T. Strufe, and K. Rzadca, “De-
centralized Online Social Networks,” in Handbook of Social Network
Technologies and Applications. Springer, 2010, pp. 349–378.
[3] B. Fitzpatrick and D. Recordon, “Thoughts on the Social Graph,” 2007,
http://bradfitz.com/social-graph- problem/.
[4] W3B, “Trends im Nutzerverhalten,” 2013, http://www.fittkaumaass.de/
reports-und- studien/trends/nutzerverhalten-trends.
[5] A. Bleicher, “The Anti-Facebook,IEEE Spectrum, vol. 48, no. 6, pp.
54–82, 2011.
[6] T. Paul, A. Famulari, and T. Strufe, “A Survey on Decentralized Online
Social Networks,” Computer Networks, vol. 75, Part A, pp. 437–452,
2014.
[7] S. G¨
ond¨
or and H. Hebbo, “SONIC: Towards Seamless Interaction in
Heterogeneous Distributed OSN Ecosystems,” in Wireless and Mobile
Computing, Networking and Communications (WiMob), 2014 IEEE
10th International Conference on. IEEE, 2014, pp. 407–412.
[8] BITKOM, “Press release: Gezeitenwechsel bei Kurznachrichten,” 2014,
http://www.bitkom.org/de/presse/8477 79536.aspx.
[9] S. G¨
ond¨
or, F. Beierle, E. K¨
uc¨
ukbayraktar, H. Hebbo, S. Sharhan, and
A. K¨
upper, “Towards Migration of User Profiles in the SONIC Online
Social Network Federation,” in ICCGI. IARIA, 2015.
[10] D. Appelquist, D. Brickley, M. Carvahlo, R. Iannella, A. Passant,
C. Perey, and H. Story, “A Standards-Based, Open and Privacy-Aware
Social Web,W3C Incubator Group Report, vol. 6, 2010.
[11] S. Buchegger and A. Datta, “A Case for P2P Infrastructure for Social
Networks - Opportunities & Challenges,” in Wireless On-Demand
Network Systems and Services, 2009. WONS 2009. Sixth International
Conference on. IEEE, 2009, pp. 161–168.
[12] S. Buchegger, D. Schi¨
oberg, L.-H. Vu, and A. Datta, “PeerSoN: P2P
Social Networking: Early Experiences and Insights,” in Proceedings of
the Second ACM EuroSys Workshop on Social Network Systems. ACM,
2009, pp. 46–52.
[13] J. A. Pouwelse, P. Garbacki, J. Wang, A. Bakker, J. Yang, A. Iosup,
D. H. Epema, M. Reinders, M. R. Van Steen, and H. J. Sips, “TRIBLER:
A Social-Based Peer-to-Peer System,” Concurrency and Computation:
Practice and Experience, vol. 20, no. 2, pp. 127–138, 2008.
[14] L. A. Cutillo, R. Molva, and T. Strufe, “Safebook: A Privacy-Preserving
Online Social Network Leveraging on Real-Life Trust,Communica-
tions Magazine, IEEE, vol. 47, no. 12, pp. 94–101, 2009.
[15] Y.-J. Chang, H.-H. Liu, L.-D. Chou, Y.-W. Chen, and H.-Y. Shin, “A
General Architecture of Mobile Social Network Services,” in Con-
vergence Information Technology, 2007. International Conference on.
IEEE, 2007, pp. 151–156.
[16] C. Wilson, T. Steinbauer, G. Wang, A. Sala, H. Zheng, and B. Y.
Zhao, “Privacy, Availability and Economics in the Polaris Mobile Social
Network,” in Proceedings of the 12th Workshop on Mobile Computing
Systems and Applications. ACM, 2011, pp. 42–47.
[17] M. D¨
urr, M. Maier, and F. Dorfmeister, “Vegas - A Secure and Privacy-
Preserving Peer-to-Peer Online Social Network,” in Privacy, Security,
Risk and Trust (PASSAT), 2012 International Conference on and 2012
International Confernece on Social Computing (SocialCom). IEEE,
2012, pp. 868–874.
[18] Facebook, “The Open Graph Protocol,” 2010, http://ogp.me/.
[19] Facebook Developers, “OpenGraph,” 2013, https://developers.facebook.
com/docs/opengraph/.
[20] M. H¨
asel, “OpenSocial: An Enabler for Social Applications on the
Web,Communications of the ACM, vol. 54, no. 1, pp. 139–144, Jan.
2011.
[21] James Snell, “Activity Streams 2.0,” 2015, http://www.w3.org/TR/
activitystreams-core/.
[22] W3C, “OStatus,” 2013, http://www.w3.org/community/ostatus/.
[23] Tent.is, “Tent.io,” 2013, https://tent.io/.
[24] P. Saint-Andre, K. Smith, and R. Tronc¸on, XMPP: The Definitive Guide:
Building Real-Time Applications with Jabber Technologies. OReilly,
2009.
[25] D. Brickley and L. Miller, “FOAF Vocabulary Specification 0.98,”
Namespace document, vol. 9, 2010.
[26] H. Story, B. Harbulot, I. Jacobi, and M. Jones, “FOAF+SSL: Restful
Authentication for the Social Web,” in Proceedings of the First Work-
shop on Trust and Privacy on the Social and Semantic Web (SPOT2009),
2009.
[27] W3C, “WebID 1.0 Web Identity and Discovery,” 2013, http://dvcs.w3.
org/hg/WebID/raw-file/tip/spec/identity-respec.html.
[28] J. Smarr, “Portable Contacts 1.0 Draft C,” 2008.
[29] M. Macgirvin, “DFRN - The Distributed Friends & Relations Network,”
2011.
[30] J. Heidemann, M. Klier, and F. Probst, “Online Social Networks: A
Survey of a Global Phenomenon,Computer Networks, vol. 56, no. 18,
pp. 3866 – 3878, 2012.
[31] J. Heidemann, “Online Social Networks - Ein sozialer und technischer
¨
Uberblick,” Informatik-Spektrum, vol. 33, no. 3, pp. 262–271, 2010.
[32] V. A. Rohani and O. S. Hock, “On Social Network Web Sites: Defini-
tion, Features, Architectures and Analysis Tools,Journal of Computer
Engineering, vol. 1, pp. 3–11, 2009.
[33] A. Richter and M. Koch, “Functions of Social Networking Services,”
in Proc. Intl. Conf. on the Design of Cooperative Systems, 2008, pp.
87–98.
[34] D. M. Boyd and N. B. Ellison, “Social Network Sites: Definition, His-
tory, and Scholarship,Journal of Computer-Mediated Communication,
vol. 13, no. 1, pp. 210–230, 2007.
[35] B. Kaliski, “PKCS# 5: Password-based cryptography specification ver-
sion 2.0 (RFC 2898),” 2000.
... [10]- [21], blockchains [22]- [36], Internet of Things (IoT) [37]- [48], Online Social Networks (OSNs) [49]- [57], Mobile Ad Hoc Networks (MANETs) [58]- [67], and Vehicular Ad Hoc Networks (VANETs) [68]- [78]. ...
... The Online Social Networks (OSNs) are online platforms which connect people through social relationships with each other based on their personal or career interests, activities, backgrounds or real-life connections [95]- [98]. In the context of OSNs, the DHTs are utilized to support distributed directory services [49], [50], spam protection [51], [52], routing [53]- [56], and data dependency management [57]. ...
... At the heart of it is the ability to uniquely, globally and verifiably locate a user account and retrieve its profile content. SONIC [49] features a cross-platform communication protocol that allows different OSNs to federate. SONIC promotes a DHTbased directory service for user identification [50]. ...
Preprint
Full-text available
Several distributed system paradigms utilize Distributed Hash Tables (DHTs) to realize structured peer-to-peer (P2P) overlays. DHT structures arise as the most commonly used organizations for peers that can efficiently perform crucial services such as data storage, replication, query resolution, and load balancing. With the advances in various distributed system technologies, novel and efficient solutions based on DHTs emerge and play critical roles in system design. DHT-based methods and communications have been proposed to address challenges such as scalability, availability, reliability and performance, by considering unique characteristics of these technologies. In this article, we propose a classification of the state-of-the-art DHT-based methods focusing on their system architecture, communication, routing and technological aspects across various system domains. To the best of our knowledge, there is no comprehensive survey on DHT-based applications from system architecture and communication perspectives that spans various domains of recent distributed system technologies. We investigate the recently emerged DHT-based solutions in the seven key domains of edge and fog computing, cloud computing, blockchain, the Internet of Things (IoT), Online Social Networks (OSNs), Mobile Ad Hoc Networks (MANETs), and Vehicular Ad Hoc Networks (VANETs). In contrast to the existing surveys, our study goes beyond the commonly known DHT methods such as storage, routing, and lookup, and identifies diverse DHT-based solutions including but not limited to aggregation, task scheduling, resource management and discovery, clustering and group management, federation, data dependency management, and data transmission. Furthermore, we identify open problems and discuss future research guidelines for each domain.
... One of the major drawbacks of today's OSN landscape is that users cannot communicate freely with users of different OSN platforms and services. Being mediums for social interaction and communication, OSN platforms should allow seamless communication between and interperability with each other [35] [5]. ...
... .5.1 Related WorkServices that manage multiple users or objects require a measure of identification to distinguish between individual users or objects, where the concept of identity is defined to be a set of attributes related to an entity[169]. For this purpose, an identifier (ID) is assigned to each entity, where an identifier is a name that usually is a sequence of letters, numbers, or symbols, with the usual intent of being unique in a certain domain. ...
Thesis
Full-text available
Online Social Networks (OSN) have become an integral part of our everyday lives. We express ourselves, create and collect content such as images or videos, share content and information with our friends and colleagues, exchange messages, or keep track of what’s happening in the world. Yet, despite social communication being implicitly a distributed, decentralized phenomenon, most OSN services are built in a central, monolithic fashion, concentrating all knowledge and power in one company or organization. This contradicts the idea of the social web, as proprietary and isolated walled gardens keep users from being able to freely choose an OSN platform provider or to effectively control their privacy. In order to mitigate the problem, alternative architectures that distribute control and data to multiple independent services were proposed. Unfortunately, the implicit network effects existing in large OSN services still prevent users from migrating to alternative solutions in significant numbers. Moreover, technical protocols for facilitating holistic and seamless interoperability and furthermore data portability in OSN services do not exist. Ultimately, today’s OSN market is dominated by one single service which has been able to attract a significant amount of users, while a large number of competing services and alternative solutions exist that combine a comparably small number of users. Two main issues have been identified that contribute to the current situation of one OSN service heavily dominating the entire market, being the lack of data portability and interoperability between different OSN services. This work proposes Sonic, a solution that aims to interconnect arbitrary OSN services into one open and heterogeneous federation of OSN services. Sonic introduces an open communication protocol and data formats that are able to facilitate interconnectivity of OSN services. The proposed architecture supports core features implemented in today’s most popular OSN services and facilitates extended functionality through an extensibility framework.
... Sonic is a project that proposes a decentralized and heterogeneous ecosystem of Online Social Network (OSN) platforms [20] [21]. End users of Sonic-based OSN services remain in full control of their social profiles, identities, and data by decoupling social profiles from the services they were created in. ...
Preprint
Full-text available
Decentralized services and applications provide a multitude of advantages for their users, such as improved privacy, control, and independence from third parties. Anyhow, decentralization comes at the cost of certain disadvantages, such as increased application complexity or communication overhead. This aggravates the development and deployment of decentralized services and applications. In this paper we present Blade, a software platform that aims to ease the effort of development, deployment, and administration of decentralized services by implementing reusable solutions for recurring challenges developers are facing when designing decentralized service architectures. This includes functionality for e.g. identity management, access control, request handling, verification of authenticity and integrity, discovery, or routing. Blade implements all this functionality in a Blade server instance, which can be deployed on a lightweight device, such as a NAS, Raspberry Pi, or router at home. This allows users without expert knowledge to run a Blade instance with already existing hardware with little overhead. Blade supports polyglot Blade modules that implement extended functionality, such as interfaces, frontends, and business logic of decentralized applications, e.g. a decentralized instant messaging service or an online social network. Based on the Oracle GraalVM, Blade modules can be implemented in a variety of programming languages and utilize the functionality provided by the Blade server instance. Blade modules are published in a Ethereum-based decentralized marketplace from where they can be installed directly via the Blade instances...
... Sonic is a project that proposes a decentralized and heterogeneous ecosystem of Online Social Network (OSN) platforms [20] [21]. End users of Sonic-based OSN services remain in full control of their social profiles, identities, and data by decoupling social profiles from the services they were created in. ...
Preprint
Full-text available
Decentralized services and applications provide a multitude of advantages for their users, such as improved privacy, control, and independence from third parties. Anyhow, decentralization comes at the cost of certain disadvantages, such as increased application complexity or communication overhead. This aggravates the development and deployment of decentralized services and applications. In this paper we present Blade, a software platform that aims to ease the effort of development, deployment, and administration of decentralized services by implementing reusable solutions for recurring challenges developers are facing when designing decentralized service architectures. This includes functionality for e.g. identity management, access control, request handling, verification of authenticity and integrity, discovery, or routing. Blade implements all this functionality in a Blade server instance, which can be deployed on a lightweight device, such as a NAS, Raspberry Pi, or router at home. This allows users without expert knowledge to run a Blade instance with already existing hardware with little overhead. Blade supports polyglot Blade modules that implement extended functionality, such as interfaces, frontends, and business logic of decentralized applications, e.g. a decentralized instant messaging service or an online social network. Based on the Oracle GraalVM, Blade modules can be implemented in a variety of programming languages and utilize the functionality provided by the Blade server instance. Blade modules are published in a Ethereum-based decentralized marketplace from where they can be installed directly via the Blade instances. For identity management and discovery of endpoints, Blade relays on blockchain-based smart contracts. Identity management and discovery is implemented via an Ethereum-based registry, allowing users to create and manage their identities in a self-sovereign manner without any central entity controlling the process. This way, Blade builds a decentralized service ecosystem that supports developers of decentralized applications and services.
... Sonic is a project that proposes a decentralized and heterogeneous ecosystem of Online Social Network (OSN) platforms [14] [15]. End users of Sonic-based OSN services remain in full control of their social profiles, identities, and data by decoupling social profiles from the services they were created in. ...
Conference Paper
Full-text available
Decentralized services and applications provide a multitude of advantages for their users, such as improved privacy, control, and independence from third parties. Anyhow, decentralization comes at the cost of certain disadvantages, such as increased application complexity or communication overhead.This aggravates the development and deployment of decentralized services and applications. In this paper we present Blade, a software platform that aims to ease the effort of development and deployment of decentralized services by implementing reusable solutions for recurring challenges developers are facing when designing decentralized service architectures. Blade implements such functionality in a Blade server instance, which can be deployed on a lightweight device, such as a NAS, Raspberry Pi, or router at home. This allows users without expert knowledge to run a Blade instance with already existing hardware with little overhead. Blade supports polyglot Blade modules that implement extended functionality, such as interfaces, frontends, and business logic of decentralized applications. Blade modules are installed via a decentralized, Ethereum-based marketplace that can be accessed via the Blade instances. For identity management, Blade relays on smart contracts, which implement an Ethereum-based registry. This allows users to create and manage their identities in a self-sovereign manner without the need of a central entity.This way, Blade builds a decentralized service ecosystem that supports developers of decentralized applications and services.
... To propose a holistic solution for today's social web of isolated islands, this work discusses challenges for a decentralized and heterogeneous social web. The project SOcial Network InterConnect 1 (Sonic) aims to bring forward a heterogeneous and open federation of mutually independent OSN services, which support full interoperability based on a common set of protocols and data formats [12]. In this paper, we outline the main challenges of today's social web that allow arbitrary OSN services to connect to each other as depicted in Figure 1. ...
Conference Paper
Full-text available
Online Social Networks (OSN) have become an integral part of our everyday lives. We express ourselves, share content and information with our friends and colleagues, or exchange messages. Yet, despite social communication being implicitly a distributed, decentralized way of information exchange that does not require any central entity to supervise the process, most OSN services are built in a central, monolithic fashion. This contradicts the idea of the social web, as proprietary and isolated walled gardens keep users from being able to freely choose an OSN platform provider or to effectively control their privacy. To enable users of the social web to remain in control of their social profiles and data, solutions were proposed that allow hosting one's social profile on independent servers, which then connect to each other in a loosely coupled fashion. Unfortunately, implicit network effects existing in large OSN services prevent users from migrating to alternative solutions thus ultimately hindering alternative OSN services to succeed in the social web. In this paper, we outline the main challenges that need to be addressed in order to allow decentralized OSN services to become real alternatives to well-established services such as Facebook or Twitter. The identified main challenges are coverage of typical, standard OSN functionality, a holistic and extensible interoperability protocol, support for data portability of entire social profiles, and support for platform-independent user identification. The paper then outlines Sonic, an open architecture for an open and heterogeneous network of independent OSN services, the Online Social Network Federation (OSNF), in which the identified challenges are addressed altogether.
... Still, without an automated way to import extracted user profiles in other services, users would be still confined in the OSN platform their user profile is managed by. Hence in addition to data portability mechanisms, open protocols that facilitate seamless interoperability between different OSN services are required, allowing a user on Facebook to invite guests from Google+ to a hosted event, while discussing topics with users of VKontakte and RenRen [13]. Interoperability, once implemented on a broad scale, would give users the ability to connect and interact with each other irrespective of their social network provider [11]. ...
Chapter
Full-text available
In this chapter, the necessity for data portability and interoperability in the social web is discussed. User profi les in OSN services are bound to the OSN platform they were originally created in, while at the same time, interoperability of di fferent OSN services is not supported. While the General Data Protection Regulation (GDPR) of the EU mandates data portability for user profi les of web services, interoperability between services is required to allow users of OSN services to truly communicate in a seamless fashion.
... A lack of a thorough and detailed description of all API endpoints, including data formats, response messages, and communication flows might be the main reason causing problems and incompatibility in communication between different service platforms. Still, the implemented interoperability is limited to the use case of microblogging and thus ignores most of the elemental functionality of today's OSN services [24]. For example, creating photo albums and video collections is a feature supported by Friendica, which cannot be accessed by any other OSN service and is not covered by the protocols evaluated in this analysis. ...
Conference Paper
Full-text available
Online Social Networks (OSN) are mostly closed, proprietary services that disallow interoperability with other OSN services. In the area of decentralized OSN services, several protocols and services have been proposed that attempt to implement interoperability for distinct aspects of OSN services in heterogeneous federations of OSN services. In this work, we analyze existing protocols and implementations of interoperable OSN services. While existing protocols aim to provide interoperability between OSN services, their scope is limited to certain aspects of OSN functionality, for example dissemination of status updates or creating follower relationships. In practice, OSN services implementing such protocols show a limited support for interoperability, where most functionality cannot be used and accessed between different OSN services. This emphasizes the need for a standard implementing interoperability in the social web.
... Another recent survey describes the creation and maintenance of user profiles as the "basic functionality" of SNSs [27]. In [28], several SNSs from different categories, like general (e.g. Facebook), business oriented (e.g. ...
Conference Paper
Full-text available
Two of the defining elements of Social Networking Services are the social profile, containing information about the user, and the social graph, containing information about the connections between users. Social Networking Services are used to connect to known people as well as to discover new contacts. Current friend recommendation mechanisms typically utilize the social graph. In this paper, we argue that psychometrics, the field of measuring personality traits, can help make meaningful friend recommendations based on an extended social profile containing collected smartphone sensor data. This will support the development of highly distributed Social Networking Services without central knowledge of the social graph.
Conference Paper
Full-text available
As of today, even though there is a strong trend of Online Social Networks (OSNs) becoming the main communication medium, OSN platforms are still mostly proprietary, closed solutions, which are not capable to seamlessly communicate with each other. The research project SONIC (SOcial Network InterConnect) proposes a holistic standard for inter-platform communication to eradicate these gaps between OSN platforms. Yet, even with such a communication architecture, users are still bound to the platform they originally signed up with. We envision a mechanism that allows users to migrate their social profiles between OSN platforms at any time without losing any data or connections. To facilitate a seamless migration of a user's social profile from one OSN platform to another, we propose a standardized container format for social profile migration and a protocol for migration of the profile data. This allows users to move their social profiles to a new platform server without losing any data such as images or status messages. In order to uniquely identify social profiles across multiple platforms, a globally unique identifier (Global ID) is assigned to each profile. This way, social profiles, as well as references to such profiles can be kept intact when the location of the social profile has changed due to migration. To inform linked social profiles about the recently conducted migration of the profile, a Global Social Lookup System (GSLS) maintains a database of Social Records, which link the Global ID to the current profile location.
Conference Paper
Full-text available
Online Social Networks (OSNs) have become an important part of our everyday online lives. We communicate, share content, and organize meetings and events using OSN platforms. However, even though there is a strong trend towards OSN services to become the main communication medium, most OSN platforms are still proprietary, closed services that keep users from connecting directly and seamlessly to the services of other OSN platforms. The resulting lock-in effects are intentionally created by OSN operators, as their business models are built mostly on targeted advertisement services. We envision a truly open and decentralized ecosystem of OSN platforms, where users are not cut off from friends using other social platforms and can freely migrate from one OSN platform to another at any time without losing established relationships in the social graph. This would allow users to freely choose an OSN platform of their liking instead of being limited in their choice to the platform used by one's friends. In this paper, we give an overview about the issues addressed within the research project SONIC and present the architectural requirements as well as the architectural concepts of the proposed solution. The project proposes an decentralized and heterogeneous federation of OSN platforms connected via a communication protocol that allows different OSN platforms to seamlessly communicate with each other and gives users the ability to migrate social profiles between platforms on demand.
Article
Full-text available
Social Networking Services (SNS) are the fastest growing type of social software – both in the Internet and in company-wide Intranets. Due to the fact that SNS have emerged just recently and the development speed of the services is enormous, there exist large gaps in research about this type of service. For example, so far there has been no attempt to identify and categorize the basic functionalities of SNS. This is the goal of this contribution. Six groups of functionalities for SNS are proposed and their categorization is motivated. The identification of a distinct set of SNS functions will facilitate the modularization and integration of different social network applications.
Article
Full-text available
While highly successful, today's online social networks (OSNs) have made a conscious decision to sacrifice privacy for availabil-ity and centralized control. Unfortunately, tradeoffs in this "walled garden" architecture naturally pit the economic interests of OSN providers against the privacy goals of OSN users, a battle that users cannot win. While some alternative OSN designs preserve user control over data, they do so by de-prioritizing issues of economic incentives and sustainability. In contrast, we believe any practical alternative to today's centralized architecture must consider incen-tives for providers as a key goal. In this paper, we propose a dis-tributed OSN architecture that significantly improves user privacy while preserving economic incentives for OSN providers. We do so by using a standardized API to create a competitive provider marketplace for different components of the OSN, thus allowing users to perform their own tradeoffs between cost, performance, and privacy. We describe Polaris, a system where users leverage smartphones as a highly available identity provider and access con-trol manager, and use application prototypes to show how it allows data monetization while limiting the visibility of any single party to users' private data.
Article
Full-text available
To address privacy concerns over Online Social Networks (OSNs), we propose a distributed, peer-to-peer approach cou-pled with encryption. Extending the distributed approach by direct data exchange between user devices removes the strict connectivity requirements of web-based OSNs. In order to verify the feasibility of this approach, we designed a two-tiered architecture and protocols that recreate the core fea-tures of OSNs in a decentralized way. This paper focuses on the description of the prototype built for the P2P infrastruc-ture for social networks, as a first step without the encryp-tion part, and shares early experiences from the prototype and insights gained since first outlining the challenges and possibilities of decentralized alternatives to OSNs.
Article
Abstract Because of growing popularity of Online Social Networks (OSNs) and huge amount of sensitive shared data, preserving privacy is becoming a major issue for OSN users. While most OSNs rely on a centralized architecture, with an omnipotent Service Provider, several decentralized architectures have recently been proposed for decentralized OSNs (DOSNs). In this work, we present a survey of existing proposals. We propose a classification of previous work under two dimensions: (i) types of approaches with respect to resource provisioning devices and (ii) adopted strategies for three main technical issues for DOSN (decentralizing storage of content, access control and interaction/signaling). We point out advantages and limitations of each approach and conclude with a discussion on the impact of DOSNs on users, OSN providers and other stakeholders.
Conference Paper
Although Social Network Service (SNS) providers like Facebook and Google attempt to mitigate security and privacy-related concerns of their users, abuses and misuses of personal data still make the headlines. As centralized storage of personal data is a decisive factor for unintended information disclosure, several architectures for decentralized Online Social Networks (OSNs) have been proposed. System designs range from solutions based on a decentralized client server architecture like Diaspora to P2P systems like PeerSoN. Despite all efforts to accomplish strong decentralization, most proposals cannot achieve sufficient informational self-determination, i.e., users do not have full control over storage and dissemination of their personal data and published content. In this paper we follow a contrary approach and present Vegas, a secure and privacy-preserving P2P OSN which restricts the possibility to browse the social graph to the ego network. We show how Vegas achieves a maximum degree of security and privacy through encryption and decentralization. We present our mobile Vegas prototype and its context-dependent communication channel decision model. Finally we show how Vegas can be extended to support services like social-search and directory services in a secure and privacy-preserving way.
Article
Online social networks became a global phenomenon with enormous social as well as economic impact within a few years. Alone, the most popular online social network, Facebook, counts currently more than 850 million users worldwide. Consequently, online social networks attract a great deal of attention among practitioners as well as researchers. The goal of this article is to provide an overview of online social networks in order to contribute to a better understanding of this worldwide phenomenon. In this context, we address for example the following questions: What are the major functionalities and characteristics of online social networks? What are the users’ motives for using them and how did online social networks emerge and develop over time? What is the impact and value of online social networks from a business perspective and what are corresponding challenges and risks?