World Library  
Flag as Inappropriate
Email this Article

Google Wave Federation Protocol

Article Id: WHEBN0023002283
Reproduction Date:

Title: Google Wave Federation Protocol  
Author: World Heritage Encyclopedia
Language: English
Subject: Instant messaging, Apache Wave, Profanity (instant messaging client), Kik Messenger, ChatON
Collection:
Publisher: World Heritage Encyclopedia
Publication
Date:
 

Google Wave Federation Protocol

The Wave Federation Protocol (formerly Google Wave Federation Protocol) is an open protocol, extension of the Extensible Messaging and Presence Protocol (XMPP) that is used in Apache Wave. It is designed for near real-time communication between the computer supported cooperative work wave servers.

Overview

Still currently in development, the Wave Federation Protocol is an open protocol that is intended to parallel the openness of the email protocol so waves may succeed email as the dominant form of Internet communication.[1][2][3][4][5]

Availability

Since the protocol is open, anyone can become a wave provider and share waves with others. Like IM, FTP, etc. In this model, Google Wave is one of many wave providers.[4][5]

Java source code for the "Google Wave Federation Prototype Server" was released in a Mercurial repository in July 2009 under the Apache License 2.0.[6][7]

Framework

Some features of Extensible Messaging and Presence Protocol inherited by the wave federation protocol are the discovery of IP addresses and port numbers, using Domain Name System (DNS) SRV records, and TLS authentication and encryption of connections. The XMPP transport encrypts operations at a transport level. So, it only provides cryptographic security between servers connected directly to each other. An additional layer of cryptography provides end-to-end authentication between wave providers using cryptographic signatures and certificates, allowing all wavelet providers to verify the properties of the operation. Therefore, a downstream wave provider can verify that the wave provider is not spoofing wavelet operations. It should not be able to falsely claim that a wavelet operation originated from a user on another wave provider or that it was originated in a different context. This addresses the situation where two users from different, trustworthy wave providers are participants of a wavelet that is hosted on a malicious provider. The protocol requires each participant to sign its user's operations with its own certificate. The signatures of all the operations forwarded by the host will be evaluated by the participants. This is to stop malicious hosts from altering or spoofing the contents of the messages from the user of other services. All the signatures and verifications are done by the wave providers, not the client software of the end users.[4][5]

All waves and wavelets (child waves) are identified by a globally unique wave id, which is a domain name and an id string. The domain name identifies the wave provider where the wave originated. Waves and wavelets are hosted by the wave provider of the creator. Wavelets in the same wave can be hosted by different wave providers. However, user data is not federated; i.e., not shared with other wave providers. Private reply wavelets are also possible, of which other participants have no knowledge or access. If a private wavelet is sent between users on the same wave provider, it's not federated regardless of where the parent wave is hosted.[4][5]

Concurrent federation

A wave provider operates a wave service on one or more networked servers. The central pieces of the wave service is the wave store, which stores wavelet operations, and the wave server, which resolves wavelet operations by operational transformation and writes and reads wavelet operations to and from the wave store. Typically, the wave service serves waves to users of the wave provider which connect to the wave service frontend. For the purpose of federation, the wave service shares waves with participants from other providers by communicating with these wave provider's servers. Copies of wavelets are distributed to all wave providers that have participants in a given wavelet. Copies of a wavelet at a particular provider can either be local or remote. We use the term to refer to these two types of wavelet copies (in both cases, we are referring to the wavelet copy, and not the wavelet). A wave view can contain both local and remote wavelet copies simultaneously.[4][5]

The originating wave server is responsible for the hosting and the processing of wavelet operations submitted by local participants and by remote participants from other wave providers. The wave server performs concurrency control by ordering the submitted wavelet operations relative to each other using operational transformation. It also validates the operations before applying them to a local wavelet.[4][5]

Remote wavelets are hosted by other providers, cached and updated with wavelet operations that the local provider gets from the remote host. When a local participant submits a wavelet operation to a remote wavelet, the wave server forwards the operation to the wave server of the hosting provider. Then the transformed and applied operation is echoed back and applied to the cached copy.[4][5]

Wave services use federation gateways and a federation proxy components to communicate and share waves with other wave providers. Federation gateways communicate local wavelet operations, push new local wavelet operations to the remote wave providers of any other participants, fulfill requests for old wavelet operations, and process wavelet operations submission requests. A Federation proxy communicates remote wavelet operations and is the component of a wave provider that communicates with the federation gateway of remote providers. It receives new wavelet operations pushed to it from other providers, requests old wavelet operations, and submits wavelet operations to other providers.[4][5]

See also

References

  1. ^ Video on YouTube
  2. ^ "Google Wave Federation Protocol". Google. 
  3. ^ Hachman, Mark (2009-05-28). "Google Reinvents Email, Docs with Google Wave". www.pcmag.com. Retrieved 2009-06-02. 
  4. ^ a b c d e f g h http://www.waveprotocol.org/whitepapers/google-wave-architecture
  5. ^ a b c d e f g h http://www.waveprotocol.org/whitepapers/internal-client-server-protocol
  6. ^ http://googlewavedev.blogspot.com/2009/07/google-wave-federation-protocol-and.html
  7. ^ https://code.google.com/p/wave-protocol/

External links

  • Google Wave Federation Protocol Home Page
  • Draft Protocol Spec
  • Protocol Whitepapers
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and USA.gov, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for USA.gov and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
 
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
 
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.
 


Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.