Taxonomy
- SNS: Social Networking Services.
- OSN: Online Social Networks.
- DSN: Decentralized Social Networks.
- MSN: Mobile Social Networks.
- MetaSN: Meta Social Network.
All services that help people to socialize are regarded as Social Networking Services (SNS). What does it mean by socialize? I don't think there is an agreement among people. However, there are to at least two problems to look at:
- Information acquisition and dissemination.
- Connection (friendship) maintenance.
We address the first problem in SNSApi as a start. In this view, many services can be regarded as SNS if they are used a "social way". Technically, the differences of those services come in four ways:
- whether links/ relationships between different parties are declared explicitly beforehand or implicitly established dynamically;
- whether the information flow is uni- or bi-directional;
- whether a user is allowed to read and/ or write from/ into the information sharing channel;
- whether user authentication and/ or authorization are required.
With the above parameterization, we can even cast Email, RSS and SQLite into SNS. Note that the previous narrow-sense SNS may only refer to OSN. From the end-user's point of view, those services do not have much technical difference. In a word, we just want to find a place to read or write messages. Whether this message is a status update, a blog post, or an email depends on the concrete service that is used.
The SNSApi philosophy is to change from service-centric network to user-centric network.
What does service-centric mean? Here are some examples:
- Go to Facebook to talk with close friends.
- Go to Twitter to share recent news.
- Go to LinkedIn to connect to professionals.
- ...
Before you join that network, you already had some prior perception of it. More precisely, the service provider and the general public already had some prior perception of it. Now the confusing part is, why should I, as a normal user, go to difference places just for different purposes? Because all my friends behave in this way? That is the crazy part of service-centric networks. This is not only the problem of centralized services, but also the problem of decentralized ones. Those stand-alone DSN are basically saying: come here, we have better privacy control and better functionality. While the statement is true, you can not directly move there because your friends do not. That is the problem of service-centric networks. Users suffer from data fragmentation or relationship fragmentation.
As a normal user, what I want is fairly simple -- Get me a unified way to access those services. What's the benefit?
- Easier inter-operation
- More and better UI/ UE
- Secure your data -- you don't want to lose everything when someone block your account
Again, user-centric services are the future.
In short, a meta social network is the network of social networks. SNSApi can be a powerful building block in realizing a meta social network.
We envision that federation will be the ultimate solution to MetaSN. However, too early federation development does not give us many benefits. The reason is: why should those big brothers implement your federation protocol? Let's step back a little and avoid arguing the business side. What's the immediate things that can be done to achieve a MetaSN?
The answer is: you, I, and everyone -- the users.
Even prior to the Open API's era, we were constantly forwarding information from Twitter to Facebook, or the other way around. Look at those manual copy and paste functions. They indeed stitch those social networks together. Looking from the higher level (can we call it Human Layer, which is above Application Layer?), that is alrady a MetaSN.
What's the problem of this MetaSN formed on Human Layer (HL)? Obviously, it's not efficient. Forwarding a status on Twitter is just one click away. Forwarding a status from Twitter to Facebook is one copy-and-paste away. Besides, you always lose meta information (e.g. status ID) during the manual operations.
Towards this end, we have to address the unification problem -- from the user point of view. We also envisioned that cross-platform socialization will be the future.
Roughly speaking, any services/ tools that executes in a decentralized manner is a (part of/ component of) DSN. There are many dimensions of decentralization. I can not afford a thorough survey here. Just to name a few:
- Server-based: Diaspora
- Fully decentralized: PrPl
- Federation protocol: OStatus
They are all ways to go decentralization. There are even some heterogeneous systems, e.g. use a cloud backend as a part; use the celluar infrastructure.
It's worth to note Mobile Social Network (MSN). Running a Facebook App on your iPhone is not what we mean by MSN here. One prominent factor of MSN is the adoption of opportunistic networking. For example, Musubi uses BlueTooth to talk with friends upon each encounter. Related works are Delay Tolerant Networks (DTN). When applied to human movement constraints, it's also called Pocket Swtiching Network (PSN). When applied to vehicles, it's also called Vehicular Network (VNet).
While DSN covers a large scope, I think the ultimate setting is:
- In terms of communication technology, opportunistic networking is used.
- In terms of social networking technology, federation protocol is used. There will be more than one federation protocols. Bottom line is that they enable bilateral conversation between different sites.
As is said in previous sections, we have to do something more practical before jumping towards there. By the way, I think the landscape of SNS in the future will be:
- Majority of the users still live on ordinary OSN. There are two fundamental reasons. They are not aware of those problems or they just do not care.
- Minority of the users move to many different platforms due to better privacy policy, richer functionality, etc.
With this observation, we come again to the point that cross-platorm socialization will be the main stream in a long time.
- platform:
one abstraction of SNSApi compatible interfaces and data structures.
For example,
TwitterStatusis a platform. In Python's words, "platform" is a class. - channel:
one instantiation of a platform.
In Python's words, "channel" is the object instantiated by a class.
e.g.
ch = TwitterStatus()gives a channel to access statuses on twitter. Obviously, one platform can be instantiated with multiple configurations, e.g. operate multiple accounts on Twitter. - plugin:
The implementation of platforms.
It comes in form of Python scripts under
snsapi/pluginorsnsapi/plugin_trial. One plugin may contain several platforms. For example, inrenren.py, we haveRenrenStatus,RenrenBlog, andRenrenShare. Platforms for the same OSN share similar building blocks. It's beneficial to group them together.