Abstract
We present an instant messaging system, powered by the Social Linked Data Platform (SoLiD). Data is distributed accross personal storage servers. Using web stanadrds the user is able to control where the data resides, who can see what, and maintain privacy.
Keywords
Introduction
Realtime communications on the web have come to rely almost exclusively on data silos with messages going through trusted third parties. While this works well enough in most cases it suffers from the weakness that the user is not fully in control of their own data and not able to use it in highly connected scenarios to created unexpected reuse. We present an instant messaging system powered by Social Linked Data (SoLiD), in order to, better distribute data, protect privacy and allow next generation applications, which can be accessible by both human and machine.
Non-Functional Requirements
Decentralization
As much of the system as possible should be decentralized in line with web design principles [1]. This includes, identity, accounts, payment providers, wallets and messaging. This is achieved by giving anything of note a URI. That allows any domain to host any aspect of the system. The app is 100% client side and only relies on commodoty storage as a backend, via linked data platform.
Accessibility
Accessiblity and ARIA guidelines are a goal of the project, so that as many people and possible can use messaging
Security
Work is done on security, in particular the tools used are Web Access Control, and TLS. More tools can be added over time.
Conceptual Design
Instant messages occur within a SIOC Space. Spaces can be sub divided in different ways, single, daily, friends or friendsdaily. A single user daily container is also set up by default in order to act as a personal diary or journal. Presence is stored at the root of the container. The display is shown for a given user on a given date. The default date is today's date. If there are no messages in today's date, the last known date is used.
Authentication is provided via WebID and access control via WebACL. Integration with bots are permissible via ACLs. Linked data is used for discovery where possible, including a seeAlso from the webID, and if not, taken from query string parameters. Once authenticated the user is cached in localstorage.
Messages are expanded to show images, audio and video when matched. Friends are added to a roster by following FOAF : knows relations in the WebID. Facebook open graph protocol is also leveraged when appropriate. The chat system can also perform basic commands such as PUT and PATCH to a URI. Data is stored in /chat/ area of the ldpc and /chat/diary/ for the diary. It is also possible to 'like' a post by clicking on a heart icon.Container Types
- single a single container without sub divisions, where all content is stored in a single location
- daily a container with one sub container per day
- friends a container with one sub container per friend
- friendsdaily a root which is divided by both friends and then date
Discovery
Discovery is the process of finding out more information using pointers, in order for the app to render the items it needs. Discovery is initially seeded via the webid login widget, which returns the user's webid, and query string parameters which sets the app state. Query string parameters are optional. From a person a roster is pulled in via the foaf : knows relation. A special help room is hard coded and added to the roster. One level of seeAlso is added to check for other data, some of which may be private. Storage is found using the pim : storage relation. In our case the storage must have a websocket in the Updates-Via header to allow realtime communications. If no such header is found we fall back to a well known default location, which is normally the ldpc root plus "chat/". All current settings can be found by clicking the settings icon.
Presence
Presence is recorded and retrieved from from a location, found in the the query string variable, "presenceURI". The format of presence file is:
:user http://rdfs.org/sioc/ns#last_activity_date "date" .
Commands
Two commands are avaialable, /put and /patch. The format is
/put [uri] [data]
/patch [uri] [data]
This enables generic data writing via the command line. A templating system could be an extension of this. As such the chatbox could be considered a command line for the web, much as the shell is a command line for UNIX.
Components
As far as possible this project aims to reuse web standards and work done by the W3C. The main items followed are SoLiD, W3C Design Issues, WebID, Linked Data, Linked Data Platform, HTML5, RESTful principles and Websockets
SoLiD
SoLiD is the social linked data platform. SoLiD was designed from the ground up to be modular and openly extensible. It relies as much as possible on existing W3C standards. RDF, LDP, Websockets, WebID, WebID-TLS, WebID-RSA, WebAccessControl
Web Components
Three web components are used in this work. The first is a login widget to obtain a WebID from a user. The second is a roster which contains a list of all your friends, and their presence. The third is a chat component which displays instant messages and micro blog posts. The polymer framework is selected for this work.
Implementation
An implementation of this work is available on github as free software under the MIT license. A demo is available at webid.im.
Conclusions
In this article, we have discussed a way to improve realtime communications on the web using Linked Data. Data is distributed accross the web under the conrol of the user, enabling better privacy and unexpected reuse. Future work includes caching and realtime streaming data, integrations with other apps and more authentication methods.
Acknowledgements
We would like to extend our thanks to those individuals and groups working to bring the Web to its full potential. A special thanks to Andrei Sambra, and the team at MIT DIG for feedback and all their work.
References
- Principles of Design http://www.w3.org/DesignIssues/Principles.html