Re: Braid: Synchronization for HTTP

Austin Wright <> Sun, 21 July 2019 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA0B21200B8 for <>; Sun, 21 Jul 2019 12:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QlFW3nzudKYM for <>; Sun, 21 Jul 2019 12:27:26 -0700 (PDT)
Received: from ( [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2693B1200A3 for <>; Sun, 21 Jul 2019 12:27:25 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hpHRo-0007gu-1j for; Sun, 21 Jul 2019 19:24:40 +0000
Resent-Date: Sun, 21 Jul 2019 19:24:40 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hpHRl-0007g2-PS for; Sun, 21 Jul 2019 19:24:37 +0000
Received: from ([2607:f8b0:4864:20::42b]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hpHRj-0005Xg-Rn for; Sun, 21 Jul 2019 19:24:37 +0000
Received: by with SMTP id c73so16276886pfb.13 for <>; Sun, 21 Jul 2019 12:24:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zjNM22VD/bBqvWjrM/PH2n6wIuD+0p1MN+adTyPpNnA=; b=zq0BEKMUdcyo/VFbtUbV79XXQ0Okgs6Rd4FY8CmVpTqL7dZUKYTd/oECvPst0fs4Rv keiGKx7mHlytPYVLqzLIwLDk1ULCjX4YORwyhSwcH7s26J1tXBbMul+Mc+mRWsORm2E0 FTvm7gpzzoVksaXuGOcstQcl7uJQWoKx0oFeU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zjNM22VD/bBqvWjrM/PH2n6wIuD+0p1MN+adTyPpNnA=; b=YklImzMjgEyV8t1LwnxpTkHwuxQdtDNjPcubX6OD7b1fc/634E+gDcC6Rj6HR1kNQO XvBMyJg773bpO0vs6ZStk2mC8HSz2H6j+bWDw/IwhyDGpbDvWVy/bVVN64awJwigoH3+ H18reR4UtpVZk7zp2yND7DHkC2waj8gkvbhZczgklNtYqgY1oNtUpJ+VfFx/lmt/mAX3 VUjs/z3xPIwKZfU9oCx/Zf99thr8KE78D3XOQqv9yccHkS2e7pn9+CEzIwZEAHv3sQe0 LcqNPmozQnjMXOIs7KQcKK2mcpGJ5cr4r1lSB8o882RUSqyYkygh0Lg6PYoh4lP8K5MI 2i7Q==
X-Gm-Message-State: APjAAAWR2PFkoc2hIfrCV9TnSI0xQ03x5Ak8Fo6pml7zO/vCgz+eXCfW NX/nFyrt7uOJ6fRw/cYniFA=
X-Google-Smtp-Source: APXvYqxkToFzj3CS80bmgQgpHvMtrwN+y4n8uY+lO3jzJr6JmzOCTQ+PkT4bd9y9p+G74RgbK8YQ+A==
X-Received: by 2002:a63:d315:: with SMTP id b21mr43923977pgg.326.1563737053609; Sun, 21 Jul 2019 12:24:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id a6sm33422330pjs.31.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jul 2019 12:24:13 -0700 (PDT)
From: Austin Wright <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_432993E7-FA54-46CB-B9FA-7204A6B05212"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 21 Jul 2019 12:24:09 -0700
In-Reply-To: <>
To: Michael Toomim <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Received-SPF: pass client-ip=2607:f8b0:4864:20::42b;;
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=2.333, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1hpHRj-0005Xg-Rn faf92869d3a898f2a5f89d43d2716a74
Subject: Re: Braid: Synchronization for HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/36814
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On Jul 19, 2019, at 13:45, Michael Toomim <> wrote:
> Hi all!
> I'm writing to request review for a new extension to HTTP called Braid, which gives it the ability to synchronize changing state, rather than just transfer it. Braid integrates the power of Operational Transform and CRDTs with 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 just published a first draft of the Braid protocol here: <>. Additional resources are at <>.
> As this is a new proposal, we are also looking for a home for its development. Is the HTTPWG interested in aspects of this work?
> In any case, I look forward to seeing you in Montreal! This will be my second IETF meeting, and it was fun meeting many of you in Prague.
> Michael

My personal notes on draft-toomim-braid-00:

* This seems to be written like an academic paper rather than an RFC, is this ultimately intended to be a technical specification?

* One of the examples uses a `braid:` URI. First, consider referencing “"; second, how the “braid:” scheme dereferenced differently versus “http:”? How would one point to a p2p resource?

* Does this anticipate registering “Linked JSON” as a new media type? (That would go under IANA Considerations.) What existing JSON-based hypermedia types have you considered using?

* For versioning, HTTP can represent specific versions of resources as hyperlinks. See <>, among some others.

* Could this simply be implemented as a new HTTP method? e.g. suppose this defines a SUBSCRIBE method that streams changes to the resource (using a new media type built for this purpose). Likewise, modifications would be uploaded via PATCH (using the same media type). You can also look at CoAP, which already has a SUBSCRIBE method, and a WebSockets transport.

* The Web does allow for client state, at the user-agent's discretion. If I download a webpage, I don’t expect my edits for form fields to be automatically propagated to other users, at least not until I submit the form, or otherwise opt-in. Also, bookmarks and navigation history are forms of client state too. How do I distinguish between these states that I do and do not want synchronized?

* Can this be used with hypermedia types, like HTML? It would seem strange if this were a protocol built only to support a single media type.

* Is there more to this than a standardized implementation of operational transform, for editing resources? It seems like what you’re aiming for is something like WebSockets, specialized for OT and more transparent to the client; especially the Upgrade handshake to change protocols, and a standard ECMAScript API for Web browsers. (My first impression is this aims to change the semantics of HTTP entirely, but upon further inspection, is actually much more modest.)


Austin Wright.