Facebook: relevant content on this site

Instant Messaging: Past, Present and Future

Talat Chaudhri — Fri, 08 Mar 2013 11:22:57 +0000

A brief history...

Instant messaging has been around on the Internet for longer than the World Wide Web. In its earliest, purest (and, it's probably fair to say, crudest) form, it was possible to use the Unix command line tool write to output a message to another user's terminal, provided that they had previously typed mesg y (i.e. messaging yes), or indeed to directly echo or even cat the contents of a file to another terminal. Surprisingly, there was also a tool for real-time typing to the other terminal, which eventually settled on a split-screen approach. (Far more recently, this was, one of the supposed "killer" features of Google Wave before its development was abandoned - yet it had existed in a simpler form many years before.) While the original write and talk utilities have been gradually improved so that they can talk to users on different servers - and, for example, provide security over the Secure Sockets Layer (SSL) - they were never a user-friendly tool for the non-technical user. They are still installed by default on some Unix/Linux distributions but are little used even by developers, given the huge variety of more modern, scalable technologies.

What was not provided by these early utilities was the ability to have anything but the crudest control over who could chat with you. Once you had typed mesg y, anybody on that server could contact you until you typed mesg n (i.e. messaging no). In addition, giving somebody else control over your terminal was a major security issue. Even so, the modern concept of contact lists (i.e. friends) and presence information (e.g. available, busy, offline etc) were also missing. You can still tell, although only by user name, who is logged into the same Unix/Linux server as you by typing simply who into the terminal.

The next great step in the history of instant messaging was Internet Relay Chat (IRC). This essentially provides command-line chat rooms, which can be made at least somewhat more user-friendly through graphical user interface (GUI) tools such as mIRC, as well as private messages to individuals. While it is not particularly obvious how to indicate presence, amongst the myriad other commands that are available, all of the functions that one would expect in modern instant messaging are available. It was later made available over SSL, which provides basic security from snooping. However, IRC remains susceptible to netsplits, takeover wars from hackers, denial-of-service attacks, and one is not automatically guaranteed a unique identifier or nick if it has already been used on that server by another user or if the server does not allow a nickserv (nickname registration server). Despite all these failings and its consequent decline in popularity, IRC remains popular with developer communities because of its relative simplicity, in addition to a certain retro chic.

The MSN era and beyond

Instant messaging came to the ordinary user through a myriad of mutually non-interoperable commercial protocols, each with their own Graphical User Interface (GUI) provided by the company in question and many spin-off open source replacements. The underlying technology behind these protocols was not published, but they effectively supplied what would now be called an Application Programming Interface (API), stating how developers could write tools that could communicate with their servers. One could not simply run one's own server because the underlying technology was proprietary. Many of these are still in use, for example AIM, Yahoo Instant Messaging etc, and perhaps the largest, Microsoft's MSN or later Windows Live Messenger, has only just been retired through a merger with Skype. (This has, as a side effect, removed the ability of MSN users to chat with users of Yahoo Instant Messaging, as this is not possible in Skype.) For most users, all that has changed since those days is the gradual migration to new tools such as Skype, which adds voice and video chat, and Facebook chat, which is merely convenient because of the critical mass of contacts who are already on Facebook. Similarly, Google Talk offers IM services to anybody who already has a Google account and uses GMail for web-based email. Both Facebook and Google Talk have later added audio and video chat. Together, these dominate the market because they are attached to the most widely used Internet services and are accessible to ordinary, non-technical users. In the case of Facebook and Google Talk, there is the added advantage of access via the Web without downloading any dedicated software.

Open Standards

Both Google Talk and Skype are particularly interesting because, unknown to the bulk of their users, they implement the open standard XMPP (also known as Jabber), although Skype is not fully compliant with the roster system that enables one to have contacts across different XMPP servers. The reason for this is, of course, that they only want Facebook users to chat with other Facebook users rather than enable chat with other XMPP users, which would naturally include competitors such as Google Talk that also implement the protocol. However, the competition for instant messaging does not seem to be as fierce as it was, and the competitors have formed agreements: Facebook chat is now integrated into Skype despite Facebook offering competition in audio and video chat tools from its own Web site. This may be because the free service is effectively a loss leader: it does not provide the commercial income directly, since the service is free. Instead, Skype market additional paid services such as providing Skype Out (calling landline or mobile telephones), providing users with external telephone numbers and voicemail services, group video chat and so on; similarly, Facebook make their revenue through advertising on their site, which is attractive because of the free social networking tools, including instant messaging, audio and video chat. It appears to be in everybody's interest to cooperate to some degree.

Google stands out among the other commercial players in allowing its users to chat to other XMPP users who have accounts on different servers, either commercial, free or privately operated. One can talk to Google Talk users (or any other XMPP users) using a free account with jabber.org or even run one's own server (as one could with IRC) using ejabberd or similar open source XMPP server software. However, audio and video chat is limited to users with Google accounts, providing the incentive to prefer their all-in-one, one-stop shop approach to Internet services, which is convenient for most users. The development of open source extensions to XMPP has been slow. It is still difficult to find XMPP servers that deploy Jingle, the extension for audio and video chat, which is considerably harder to do effectively than merely installing an XMPP server, which is the work of an hour or two.

While XMPP is the de facto standard for modern IM, both for open source and increasingly commercial services, it is not without criticism. It is verbose, relying on XML, which can be an issue where bandwidth is an issue. This is a small problem for IM services but a much larger one, for example, when audio and video streams are added: it does not support binary data streams natively. It is designed for a federation network run on a number of servers and its network vulnerability, while not as high as IRC, remains a structural issue. It uses massive unicasting and does not support multicasting, which is a minor efficiency issue in chat rooms but becomes much more of a problem for group audio and video streaming. It is possible to directly substitute a newer, although relatively little known protocol called PSYC, an interserver that supports XMPP and IRC natively, which alleviates most of these problems. It takes about an hour or two to set up the psyced server, about the same as a basic IRC or XMPP server. This does, however, retain the federation approach: in future iterations of the protocol, an entirely re-engineered Peer-to-Peer (P2P) approach is under development. Being an open source project of interest mostly to technical users, development has been relatively slow. This lows XMPP and IRC to interoperate seamlessly, in addition to enabling fine control over notifications to and from other systems, friendcasting, multicasting, news federation, interoperability with microblogging systems such as Twitter and so on, via programmable chatrooms.

Voice Over IP

Coming to the same market from a diametrically opposed perspective is the SIP standard for Voice Over Internet Protocol (VOIP), which began as an audio service and later developed both IM and video services in addition. This is widely used in the commercial sector: for example Vonage in the UK. There are open source varieties that can be deployed by anybody, albeit with some technical difficulty, such as Asterisk and FreeSwitch. These only cost where they connect to the Public Telephone Service Network (PTSN) that provides ordinary landline telephony, but they also enable low-cost, in-house management of telephone extensions, voicemail and related services, as well as making telephony available through computer terminals as well as telephones. One can manage distributed calling, effectively enabling call centres, using this free technology, which can be installed even on a home server. While most people would not have a particular reason to go to such effort, the entry costs to setting up complex systems have been radically reduced to the point where they would now be affordable for small organisations who can rely either on voluntary contributions of development effort or who can outsource the work cheaply.

Why is this important?

Technologies such as XMPP may not be of immediate interest to the average Internet user, either in the HE sector or more widely. However, they underlie so many of the Internet services that we may use on a daily basis that issues such as interoperability of services via open standards are worth knowing about, at the very least in order to gain an understanding of the relative difficulty of providing such services and the costs involved. Given that more and more reliance is being put on an increasingly small group of major providers of Internet services by vast numbers of ordinary users, the consequences for privacy and management of personal information are potentially immense. There is an intense debate going on about whether services taking a federated approach, relying on a network of servers, or a peer-to-peer approach, is the best way (or even a feasible way) to mitigate against these risks is relevant to many other technologies, of which instant messaging is only one: the most significant of these may be social networking. For most people, social networking is vastly more important than, for example, darknet services and/or file sharing, which currently account for the large bulk of peer-to-peer services in widespread use. Indeed, it is social networking, that typically gathers together a number of pre-existing technologies together for convenience with the core microblogging service, that best highlights the widely differing approaches to the future of the architecture of Internet services.

“The path to academic personal identifiers…

Ben O'Steen — Fri, 15 Jul 2011 11:43:00 +0000

… is littered with the wrecks and remains of many failed projects.”

The varied attempts to start, maintain or promote a single identifier scheme for academics, whether applied locally or internationally, can arguably be described as being a mix of successes and abject failures. I do not wish to dwell on what a failure is in this respect, but wish to simply define it as being a scheme that is not seen to be a necessary part of an academic’s ‘life’ – that of research, producing outputs, self-promotion, discovery of work and communicating with their collegues and the wider world.

It is far more instructive to look at the schemes that have worked in academia, and also at schemes which a broader section of the population have adopted. The first case that is most instructive is that of RePEc -

RePEc (Research Papers in Economics) is a collaborative effort of hundreds of volunteers in 74 countries to enhance the dissemination of research in economics. The heart of the project is a decentralized database of working papers, journal articles and software components. All RePEc material is freely available. Participation in RePEc as a provider only involves the cost of your time in preparing and maintaining metadata describing your publications.

Why is RePEc an important service to consider?

The service(s) were created and later shaped due to the needs of its community by volunteers – started by Thomas Krichel in 1993 (in every practical sense), the team has grown over the years.
It is a great example of a ‘bottom-up‘ (from the authors/peer group) service, not a ‘top-down’ service (institutional/publishing org driven.)
Being a product of the community, there is a great deal of trust in the services. The barrier to interaction with the site is low.
It has provided community-policed freedom for Economists to create and garden their own profiles for a number of years - http://authors.repec.org - the service now has over 25,000 author profiles, added primarily by the authors themselves and it is loosely labelled an Author ‘CV’ on the front page of the RePEc website.
- “The RePEc Author Service aims to link economists with their research output in the RePEc bibliographic database.” (more info)
It allows the community of economists to communicate their ideas and discover each other’s related research in a better manner than would be possible without it.
It allows the community to self-promote and compare one author’s output to another’s, based on their profiles and citations.

These are the key points that I think have contributed to making RePEc and its collection of services a success – it addresses the real needs of a community who trust it, who can freely add to and correct information about themselves and it allows them to communicate better, to self-promote and compare themselves to their peers and to discover further related research with greater ease.

Why are the publisher’s not fulfilling this role? One of the key pieces of research currency used by Economists is the Working paper – a paper that by its very nature is subject to revision, alteration and hopefully, amelioration. Unlike some other subjects, it is seen to be important for this ‘imperfect’ work to be scrutinised in a more public manner than other academic cultures might tolerate. A Work (used in the FRBR sense) whose contents will shift from the time of first publication, such that many versions of it may exist, are an anathema to conventional fire-and-forget publishing, where what is published may be retracted or given an errata, but its structure and findings are not expected to change.

Some may refer to this sort of output as ‘grey literature’ – I will give the most current (Prague Definition 2010) below:

“Grey literature stands for manifold document types produced on all levels of government, academics, business and industry in print and electronic formats that are protected by intellectual property rights, of sufficient quality to be collected and preserved by library holdings or institutional repositories, but not controlled by commercial publishers i.e., where publishing is not the primary activity of the producing body.”

Under this definition, working papers do fall into this category, although RePEc does not limit authors to listing only these forms of outputs. I consider the lack of a limit here to provide a greater sense of ownership to the community and another aspect that a successful service would likely emulate.

The fact that RePEc can be considered to be ‘owned’ by a community lends trust to its brand, but that is by no means the only way to garner the trust of a community. It’s actions and developments have won the trust of its community over the years. It is perfectly feasible for a publisher or private entity to produce a service which has similar success in this area. For example, consider the SSRN (Social Science Research Network).

SSRN

Like RePEc, the SSRN was created and shaped due to the needs of its community but in this case, the organisation behind it is privately owned.
It is focussed on the needs of authors and many of its services, if not all of them, are designed to be used by those within the research peer-group
- A somewhat subjective example is from their site’s navigation banner - http://www.ssrn.com/hen/index.html - there are options for ‘Top Papers’ and ‘Top Authors’ but nothing for ‘Top Institution’.
There is a great deal of trust in the services, as the SSRN spend a lot of effort validating, amending and checking the outputs of its services. While the ethereal nature of ‘download statistics’ may be familiar to many of those who run and administer websites, it is treated with great reverence by the users of the SSRN as the organisation expends great time and effort filtering and heavily examining downloads to render this insubstantial statistic less so. It is the appearance of solidity and formality with which the services are delivered that contributes towards the trust of the community.
It allows the community of economists to communicate their ideas and discover each other’s related research in a better manner than would be possible without it.
It allows the community to self-promote and compare one author’s output to another’s, based on their profiles and citations.
It also responds to criticism and errors within its service rapidly, as it is something that it takes pride in.

Many of the points here, mesh with those from RePEc, including the key (IMHO) ones of trust, comparison amongst peers, self-promotion and discovery. It has more limits than RePEc (contributions to the service are less free in the sense of ‘libre‘) but these same limits provide extra trust in the information provided by the service; an air that the information within is policed well and hard to falsify.

Let’s now consider a fundamentally similar service, similar in all of the above, but it is focus is not academic, and it is free only in the sense of it being ‘gratis’ and absolutely not ‘libre’

Facebook

Like RePEc, Facebook was created and shaped due to the needs of a community but it can be stated quite clearly that the community that it primarily serves are not those of its users. A quick glance at their current terms and conditions (or Rights and Responsibilities) can justify that assertion. Look at point 2, subsection 1 for a legal bombshell of a statement that should worry any user uploading personal videos or pictures to the site.
- As people tend to blank out when they are presented with T&C legalese, I’ll copy the pertinent section here: …. photos and videos (“IP content”), …: you grant us [opt-out, not opt-in] a non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to use any IP content that you post on or in connection with Facebook (“IP License”)
It is focussed on the needs of users as it gained venture capitol based primarily on numbers of users – a ‘potential’ source of profit, rather than profitability in of itself. The organisation had a drive to gain and retain users, and had to do so by offering useful services.
There is ironically still a great deal of trust in the services they provide – in my opinion, this is because it is a mainstream service whose privacy transgressions and related reports which would erode that trust are never truly treated to mainstream media coverage.
- For example, tabloid newspapers make the UK population aware when the UK government or related bodies lose ‘CDs of valuable data‘ by running frontpage-level story campaigns over the course of days without any information on whether that data is being misused, but I have yet to find stories reported with similar intensity or visibility about the times Facebook openly attempted to sell personal data, finding articles from the Independent, Guardian and the Telegraph, individual articles that I doubt made the front pages of any of those.
- (As an aside, the irony of this Facebook group “We sue facebook if they sell our personal data!”(sic.) provides ample material to mull the issue of trust over: http://www.facebook.com/group.php?gid=52991492388 )
Even though the users’ should assess whether they should trust it, Facebook does allow the community of users to communicate and discover each other in a better manner than would be possible without it.
It allows the community to self-promote and socially compare based on their profiles.

Let’s now move swiftly on to consider an arguable failure in this realm – Thomson-Reuters’ ResearcherID:

ResearcherID

It was created primarily due to the needs of a publisher, who needed to keep track of researchers, who published which paper, co-authors and so on. This is actually a direct need of authors as well, but it is a hard notion to convey as each subject area seems to have its own coping mechanisms and acceptable losses when it comes to citations, metrics and the like.
It tried to focus on the needs of the users as well, but without the drive from a community that already existed, it was unclear what its focus is. This is perhaps a compromise between the publisher’s desire to make it as widely applicable as possible, and the individual desire to make it relevant to their own, personal community.
As this was a product by a publishing business, targeted at no specific community, the service inherited much of the same level of trust that the publishing business has within the wider academic community. That is to say, no-one trusted it to remain open and freely reusable without the threat of a hefty subscription introduced at some point later on. Thomson-Reuters own surveys confirmed that the primary reason ResearcherID was under-used was due to a lack of trust, both longterm and short term, in the service.
Without many profiles in the system, it never reached a tipping-point - it wasn’t a useful service to use in order to communicate and discover other researchers in your field of work.
Likewise, the ability to self-promote and compare was never tested, as there simply was not a great enough use of this service to do so.

The key failings of the ResearcherID service was that it did not target any community successfully, instead targeting all academic communities, and that it lacked its users’ trust in the service.

What does this mean for ORCID?

Although ORCID is technically a ‘child’ of the ResearcherID project, it does so with the knowledge of its parent failure and hopefully, as a project, will strive to correct this. While Thomson-Reuters play a part in the ORCID project, they are actively trying to relegate themselves to be no more influential in the proceedings and discussions that of any of the members of the boards administering and plotting out the direction for ORCID.

As a member of the Technical Advisory Group for ORCID, you can be sure that the aspects of trust and of community involvement will be at the forefront of any discussions I have with that group.