The Braid Protocol: Synchronization for HTTP
draft-toomim-braid-00

Document Type Active Internet-Draft (individual)
Last updated 2019-07-08
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet-Draft                                                 M. Toomim
Expires: Jan 8, 2020                                   Invisible College
Intended status: Proposed Standard                             R. Walker
                                                       Invisible College
                                                            July 8, 2019

              The Braid Protocol: Synchronization for HTTP
                         draft-toomim-braid-00

Abstract

  Braid is a proposal for a new version of HTTP that transforms it from
  a state *transfer* protocol into a state *synchronization* protocol.
  Braid puts the power of Operational Transform and CRDTs onto the web,
  improving network performance and robustness, and enabling
  peer-to-peer web applications.
  
  At the same time, Braid creates an open standard for the dynamic
  internal state of websites.  Programmers can access state uniformly,
  whether local or on another website.  This creates a separation of UI
  from State, and allows any user to edit or choose their own UI for any
  website's state.

  We have a working prototype of the Braid, and have deployed it with
  production websites.  This memo describes the protocol, how it
  differs from prior versions of HTTP, and a plan to deploy it in a
  backwards-compatible way, where web developers can opt into the new
  synchronization features without breaking the rest of the web.




Status of this Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.
  
  Internet-Drafts are working documents of the Internet Engineering Task
  Force (IETF), its areas, and its working groups.  Note that other
  groups may also distribute working documents as Internet-Drafts.  The
  list of current Internet-Drafts is at
  http://datatracker.ietf.org/drafts/current/.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  The list of current Internet-Drafts can be accessed at
  https://www.ietf.org/1id-abstracts.html

  The list of Internet-Draft Shadow Directories can be accessed at
  https://www.ietf.org/shadow.html




Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Synchronization . . . . . . . . . . . . . . . . . . . . . . . . 7
   3.  Deployment and Upgrade Plan . . . . . . . . . . . . . . . . .  10
   4.  Proposed Changes to HTTP. . . . . . . . . . . . . . . . . . .  11
   4.1.  Linked JSON   . . . . . . . . . . . . . . . . . . . . . . .  12
   4.2.  Generalized request/response  . . . . . . . . . . . . . . .  13
   4.3.  Subscriptions   . . . . . . . . . . . . . . . . . . . . . .  14
   4.4.  Versioning  . . . . . . . . . . . . . . . . . . . . . . . .  15
   4.4.1.  Versions  . . . . . . . . . . . . . . . . . . . . . . . .  16
   4.4.2.  Patches   . . . . . . . . . . . . . . . . . . . . . . . .  17
   4.4.3.  Merge Types . . . . . . . . . . . . . . . . . . . . . . .  18
   4.4.4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . .  19
   5.  Network Messages  . . . . . . . . . . . . . . . . . . . . . .  20
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   8.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . . .  23
   9.  Author's Address  . . . . . . . . . . . . . . . . . . . . . .  23




1. Introduction

  HTTP was initially designed to transfer static pages.  If a page
  changes, it is the client's responsibility to issue another GET
  request.  This made sense when pages were static and written by hand.
  However, today's websites are dynamic, generated from databases, and
  continuously mutate as their state changes.  Now we need state
  *synchronization*, not just state *transfer*.

  Unfortunately, there is no standard way to synchronize.  Instead,
  programmers write non-standard code; wiring together custom protocols
  over WebSockets and long-polling XMLHTTPrequests with stacks of
  Javascript frameworks.  The task of connecting a UI with data is one
  that every dynamic website has to do, but there is no standard way to
  do it.




      ======= HTTP Websites =======      ====== Braid Websites ======

      Today's websites are               Braid generalizes HTTP and
      generated from multiple            REST into a uniform standard
      layers of state across             that synchronizes state
      multiple computers.  Each          within and between dynamic
      layer has a different API.         websites.

        x Non-standard state API          o Standard state API

        _Client__
       /         \ 
      :  o o o o  :   Webpage DOM          o o o o       State
      :   \|  \|  :                         \|  \|  
      :    x   x  :   HTML Templates         o   o       State
Show full document text