idnits 2.17.1 draft-toomim-braid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1716 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '0' on line 619 looks like a reference -- Missing reference section? '3' on line 633 looks like a reference -- Missing reference section? '1' on line 630 looks like a reference -- Missing reference section? '5' on line 636 looks like a reference -- Missing reference section? '2' on line 632 looks like a reference -- Missing reference section? '4' on line 635 looks like a reference -- Missing reference section? '6' on line 638 looks like a reference -- Missing reference section? '1a' on line 657 looks like a reference -- Missing reference section? '1b' on line 664 looks like a reference -- Missing reference section? '2a' on line 663 looks like a reference -- Missing reference section? '2b' on line 646 looks like a reference -- Missing reference section? '3a' on line 668 looks like a reference -- Missing reference section? '3b' on line 678 looks like a reference -- Missing reference section? '4a' on line 676 looks like a reference -- Missing reference section? '4b' on line 654 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft M. Toomim 2 Expires: Jan 8, 2020 Invisible College 3 Intended status: Proposed Standard R. Walker 4 Invisible College 5 July 8, 2019 7 The Braid Protocol: Synchronization for HTTP 8 draft-toomim-braid-00 10 Abstract 12 Braid is a proposal for a new version of HTTP that transforms it from 13 a state *transfer* protocol into a state *synchronization* protocol. 14 Braid puts the power of Operational Transform and CRDTs onto the web, 15 improving network performance and robustness, and enabling 16 peer-to-peer web applications. 18 At the same time, Braid creates an open standard for the dynamic 19 internal state of websites. Programmers can access state uniformly, 20 whether local or on another website. This creates a separation of UI 21 from State, and allows any user to edit or choose their own UI for any 22 website's state. 24 We have a working prototype of the Braid, and have deployed it with 25 production websites. This memo describes the protocol, how it 26 differs from prior versions of HTTP, and a plan to deploy it in a 27 backwards-compatible way, where web developers can opt into the new 28 synchronization features without breaking the rest of the web. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering Task 36 Force (IETF), its areas, and its working groups. Note that other 37 groups may also distribute working documents as Internet-Drafts. The 38 list of current Internet-Drafts is at 39 http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 https://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 https://www.ietf.org/shadow.html 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Synchronization . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3. Deployment and Upgrade Plan . . . . . . . . . . . . . . . . . 10 56 4. Proposed Changes to HTTP. . . . . . . . . . . . . . . . . . . 11 57 4.1. Linked JSON . . . . . . . . . . . . . . . . . . . . . . . 12 58 4.2. Generalized request/response . . . . . . . . . . . . . . . 13 59 4.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 14 60 4.4. Versioning . . . . . . . . . . . . . . . . . . . . . . . . 15 61 4.4.1. Versions . . . . . . . . . . . . . . . . . . . . . . . . 16 62 4.4.2. Patches . . . . . . . . . . . . . . . . . . . . . . . . 17 63 4.4.3. Merge Types . . . . . . . . . . . . . . . . . . . . . . . 18 64 4.4.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 19 65 5. Network Messages . . . . . . . . . . . . . . . . . . . . . . 20 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 68 8. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 23 69 9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 23 70 1. Introduction 72 HTTP was initially designed to transfer static pages. If a page 73 changes, it is the client's responsibility to issue another GET 74 request. This made sense when pages were static and written by hand. 75 However, today's websites are dynamic, generated from databases, and 76 continuously mutate as their state changes. Now we need state 77 *synchronization*, not just state *transfer*. 79 Unfortunately, there is no standard way to synchronize. Instead, 80 programmers write non-standard code; wiring together custom protocols 81 over WebSockets and long-polling XMLHTTPrequests with stacks of 82 Javascript frameworks. The task of connecting a UI with data is one 83 that every dynamic website has to do, but there is no standard way to 84 do it. 86 ======= HTTP Websites ======= ====== Braid Websites ====== 88 Today's websites are Braid generalizes HTTP and 89 generated from multiple REST into a uniform standard 90 layers of state across that synchronizes state 91 multiple computers. Each within and between dynamic 92 layer has a different API. websites. 94 x Non-standard state API o Standard state API 96 _Client__ 97 / \ 98 : o o o o : Webpage DOM o o o o State 99 : \| \| : \| \| 100 : x x : HTML Templates o o State 101 : /| /| : /| /| 102 : x x x x : JS Models o o o o State 103 \ | | | | / | | | | 104 | | | | | | | | 105 o o o o - http:// - o o o o - braid:// - 106 / | | | | \ | | | | 107 : x x x x : Views o o o o State 108 : | \| | : | \| | 109 : x x x : Controllers o o o State 110 : \ / \| : \ / \| 111 : x x : Models o o State 112 : \ / : \ / 113 \.... x ../ Database o State 114 Server 116 Today's programmers have to On the braid, each piece of 117 learn each API, and wire them state (o) has a URL; whether 118 together, making sure that public, or internal to a 119 changes to shared state client or server. Any state 120 synchronize across all can be a function of other 121 layers and computers. state, and dynamically 122 recomputes when its 123 dependencies change. Braid 124 guarantees the network will 125 synchronize. 127 As the web becomes more dynamic and data-driven, the complexity of the 128 non-standard Javascript stack grows, and an increasing amount of data 129 is inaccessible to the open web. The result is a web which is open on 130 the surface, but closed internally: websites can link to each other's 131 *pages*, but cannot easily share each other's internal *state*. 133 We can solve this by generalizing HTTP into a *synchronization* 134 protocol, which replaces the complex Javascript stack, while providing 135 new features, and making website internal state accessible anywhere 136 desired, and realtime synchronized by default. 138 We have a working prototype of the Braid protocol, and have deployed 139 it with production websites. The prototype is implemented as a 140 polyfill library, which adds Braid features to existing browsers and 141 servers. 143 This document describes the new protocol, how it differs from prior 144 versions of HTTP, and a plan to deploy it in a backwards-compatible 145 way, where web developers can opt into the new synchronization 146 features without breaking the rest of the web. 148 2. Synchronization 150 Braid incorporates the abilities of Operational Transform and CRDTs. 151 These are approaches to solving *synchronization*. 153 Synchronization is a problem that occurs whenever two or more 154 computers or threads access the same state. Synchronization code is 155 tricky to write, and can result in clobbers, corruptions, or race 156 conditions. 158 This is a challenging problem, which has seen a number of partial 159 attempts in HTTP, such as e-tags, cache control, PATCH, JSON-diff, and 160 SSE. 162 Luckily, a set of maturing synchronization technologies (such as 163 Operational Transform and CRDTs) can now automate and encapsulate 164 synchronization within a library. They can synchronize arbitrary JSON 165 data structures across an arbitrary set of computers that make 166 arbitrary mutations, and consistently merge their edits into a valid 167 result, without a central server, in the face of arbitrary network 168 delays and dropouts. In other words, it is now possible to interact 169 with state stored anywhere on a network as if it is a local variable, 170 and program as if it is already downloaded and always up-to-date. 172 Unfortunately, each synchronizer implements a different protocol, with 173 a different set of features and tradeoffs. Braid proposes a common 174 language for synchronizers, so that they can interoperate, and 175 implements it as an extension to HTTP. 177 This lets multiple synchronizers interoperate, if they agree on a way 178 to consistently resolve ambiguities -- a *merge type*. We have run 179 tests that succesfully interoperate a CRDT and OT system over the 180 common Braid protocol. 182 When applying synchronization to the web, we see the power of 183 synchronization manifest in these concrete ways: 185 - Caches update automatically and instantly, because servers promise 186 to push changes to their subscribers. This obsoletes the 187 `cache-control` and `refresh` headers, and the `max-age` 188 heuristic. Users never need to force-clear their cache. 190 - Updates go over the network as diffs, which can be much smaller 191 than the resources they modify, significantly reducing network 192 usage. 194 - Web apps get an offline mode for free. Edits from multiple 195 clients merge automatically once they come online. Network 196 failures recover transparently. 198 - *Reload* buttons in browsers become unnecessary, and can be 199 removed for braid sites. Browsers automatically discover and 200 display the most recent version on their own. 202 - Web apps require roughly 70% less code to build (in our 203 experiments), because programmers do not need web frameworks or 204 custom logic to wire together a stack of server-state and 205 client-state. This work is automated by the protocol. 207 - Every