Re: Proposal: Adopt State Synchronization into HTTPbis
Kévin Dunglas <kevin@dunglas.fr> Thu, 02 November 2023 17:18 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EB0C15107F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 2 Nov 2023 10:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.655
X-Spam-Level:
X-Spam-Status: No, score=-7.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dunglas-fr.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HALEGm9aPw7f for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 2 Nov 2023 10:18:41 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07192C15107E for <httpbisa-archive-bis2Juki@ietf.org>; Thu, 2 Nov 2023 10:18:40 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1qybKU-004aGh-8c for ietf-http-wg-dist@listhub.w3.org; Thu, 02 Nov 2023 17:18:02 +0000
Resent-Date: Thu, 02 Nov 2023 17:18:02 +0000
Resent-Message-Id: <E1qybKU-004aGh-8c@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <kevin@dunglas.fr>) id 1qybKS-004aBn-Qv for ietf-http-wg@listhub.w3.org; Thu, 02 Nov 2023 17:18:00 +0000
Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <kevin@dunglas.fr>) id 1qybKQ-006fmk-Ie for ietf-http-wg@w3.org; Thu, 02 Nov 2023 17:18:00 +0000
Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-54394328f65so1993720a12.3 for <ietf-http-wg@w3.org>; Thu, 02 Nov 2023 10:17:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunglas-fr.20230601.gappssmtp.com; s=20230601; t=1698945474; x=1699550274; darn=w3.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8bMGljcimyehuY0MMm8Cqqu5ERGsdNCDJOIDTWxz6Vk=; b=GO2B5Q0swg9OHUOrXsnJoN0k+wbxcboFy7wHaZkEL/ElKtXmYpi5FiPXb3xnyLO+dG y94+216+1yEKFbQyb9M1E6dQI2m6lrXQ/dJkzXxeArSLohwwrN1HHCkzFl66+0oIre19 fT4F+Va4RTae7Ov9phuPjeBcSOlQYma23tH1dsYJNI7n7UCWw4j6fucfR/+tDOc58pG9 /OygwCOT4B84llsZmJelfzMq3nLEZ6oR08kY6ovzZvXQvTmWy5VI7e/rBAHJcTR0uhep PnLa6TFUYkThdKC6//HMTYVAzsFB16rrXr0huZH0O3DzaNl5Omx0GTRYq89BYnc+S2ZV rFOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698945474; x=1699550274; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8bMGljcimyehuY0MMm8Cqqu5ERGsdNCDJOIDTWxz6Vk=; b=cyeNVcNt9709Nk0izRS0ASnXHew23lNZKUkUg8/IZR2fj0PRoiLveo0/WMvKw7IA5M lzJvVWKMb1+ZfCpfBiRGWVMQee1m7c5h90dKfQk2qwAyYlSS7dniJSvMMYT/VkCS+thR sckVqTSwU+GnVToHdl+u1DjL7WXlYFQK1QZVU7zmDwT42w51CeuX7BA+plAPHK4goGDS hzO0fg+wD06UmmNsOIpRC4CUnUKHItSQipzmRMwKMo6IoKH7iItsbz6PpZdTm/OYbSHS qODitqnawKmtv1DDs6Sm0IUD65f97NPeE+pnEaQOESBQb9k7n+ybYr5WhWpAJRyQCI8T HUQA==
X-Gm-Message-State: AOJu0YzeAqPc5iYa7EdcVhW7mvRJbNrqg0kVDN7Oz/HdNZLZsxKXNOoT kFTZ0KML81nwkkp0TRcugn68PzzVjyAAO+z7EBEkgQ==
X-Google-Smtp-Source: AGHT+IFnb2Rbfdv0cOTbXEes6qpD1gghxsCIoWpak+WrP6+QwUEeKXyueqZ6HZ2g8RYRbjeqxMw/b7WcRkY0m+FLwOo=
X-Received: by 2002:a05:6402:3447:b0:53d:b1ca:293c with SMTP id l7-20020a056402344700b0053db1ca293cmr16383915edc.22.1698945473913; Thu, 02 Nov 2023 10:17:53 -0700 (PDT)
MIME-Version: 1.0
References: <2F6DB48A-D17C-47DF-B1BC-EAC0791D23AE@gmail.com>
In-Reply-To: <2F6DB48A-D17C-47DF-B1BC-EAC0791D23AE@gmail.com>
From: Kévin Dunglas <kevin@dunglas.fr>
Date: Thu, 02 Nov 2023 18:17:42 +0100
Message-ID: <CADU7aotpp4Zt0MuhFdiJaH1Gaoh5t1ykAb-UzzTW6uCgjHj59w@mail.gmail.com>
To: Michael Toomim <toomim@gmail.com>
Cc: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="000000000000773c2f06092e914c"
Received-SPF: pass client-ip=2a00:1450:4864:20::531; envelope-from=kevin@dunglas.fr; helo=mail-ed1-x531.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=kevin@dunglas.fr domain=dunglas-fr.20230601.gappssmtp.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_WL=-1, WEIRD_PORT=0.001
X-W3C-Scan-Sig: titan.w3.org 1qybKQ-006fmk-Ie a2233655c79b1e3863b1d630d1eb7c85
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Proposal: Adopt State Synchronization into HTTPbis
Archived-At: <https://www.w3.org/mid/CADU7aotpp4Zt0MuhFdiJaH1Gaoh5t1ykAb-UzzTW6uCgjHj59w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51548
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
As the main author of the Mercure specification (up-to-date spec: https://mercure.rocks/spec, older I-D: https://www.ietf.org/archive/id/draft-dunglas-mercure-06.html), I support this goal. Our previous attempt to "promote" the Mercure spec as a RFC didn't get much feedback ( https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0020.html), so we are in the process of submitting the spec as independent submission. We would be glad to work with the Baid and the PREP team to get a single set of standards instead. Best regards, On Wed, Nov 1, 2023 at 3:11 AM Michael Toomim <toomim@gmail.com> wrote: > At IETF 118 I will present a proposal to adopt State Synchronization work > into HTTPbis: > > Braid-HTTP: > https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http [1] > > > HTTP currently provides State *Transfer* of a document between client and > server. This made sense in 1992 when the web was mostly static, and pages > were written by hand. Caching was simple. However, today's pages are > dynamic, use Javascript and Ajax, and users expect realtime updates. > Today's web needs robust State *Synchronization*; not just Transfer. > > We have an opportunity to add State Synchronization to the WWW in a robust > & general way. Four simple extensions (below) transform HTTP into a > general-purpose State Synchronization protocol—keeping simple cases simple, > while also enabling the most advanced distributed synchronization (OT and > CRDT) algorithms. These support multiple writers, making simultaneous > edits, over arbitrary network conditions (offline or online), while > guaranteeing consistency with peer-to-peer merge-semantics. HTTP can become > a general-purpose Distributed State Abstraction: a protocol that guarantees > your local cache of state is always editable, and always up-to-date. > > We first discussed this idea at IETF 104 and 105 in Prague and Montreal. > It received great enthusiasm and feedback, which was incorporated into > draft 02 in March 2020. We tested this draft extensively over the past few > years in the braid.org group, against a variety of algorithms, apps, and > browsers, and last week we published draft 03, which I feel confident is a > general and performant approach to state synchronization, supporting every > known CRDT and OT algorithm (!), and fitting easily into today's web. > > But adopting this won't be a monolithic project like WebRTC. The approach > we propose is actually to spiff up three aspects of existing HTTP: > > 1. Subscriptions (sse) > 2. Version History (etag, max-age) > 3. Patch Formats (PATCH) > > ...and then to tie them together with one new concept: > > 4. the Merge-Type header > > The first three improvements will be useful on their own. In fact, there > are already efforts underway to improve them: > > - *Subscriptions* are being proposed in PREP [2] and Mercure [3] to > address limitations in SSE and WebSub. > - *Patch Formats* are being extended for Byte-Range-Patch [4], which > needs a generalized Content-Range header. > - Resumeable Uploads [5] needs to send a series of *Patches* (called > parts), until the *Version* on the server is complete. > - HTTP Cache Invalidation API [6] proposes a standard for servers to > push updates to the CDNs that *Subscribe* to their state. > > These improvements are needed for State Synchronization too. By adopting > the higher-level goal of State Synchronization, we gain a unified > perspective, to generalize these disparate efforts into a more powerful and > elegant HTTP. We will address the above use-cases, and enable a broad array > of new ones. > > We verified this framework with a number of implementations in the > braid.org group over the last few years. > > - Protocol implementations: braid-http [7], braid-protocol [8], wai-braid > [9] > - Algorithm integrations: sync9 [10], diamond-types [11], automerge/yjs > [12], sharedb [13], shelf [14] > - Browser extension: braid-chrome [15] > - Applications: PeeryView.org [16], Simple Braid Chat [17], Braid Wiki > [18] > - Developer APIs: statebus [19], redwood [20] > > I'm making a demo video to make these more concrete. It will appear on > this thread soon. > > Separately, I am IETF-Dispatching the idea of forming a general State > Synchronization group. (Email thread here. > <https://mailarchive.ietf.org/arch/msg/dispatch/wCrAiHwWvlK9netFi71nz3FF7Aw/>) > I believe the Braid-HTTP draft is ready for standardization, but this > general group could take on any further issues that are too abstract for > HTTPbis. > > In summary, I am proposing that HTTPbis adopt the general goal of > supporting State *Synchronization* (not just Transfer) in HTTP, which > entails making general extensions for (1) Subscriptions, (2) Version > History, and (3) Patch Formats, and then offering a (4) Merge-Type to tie > it all together. These will make for a very powerful upgrade. > > I kindly request feedback on this idea! See the draft [1] for details. > > Michael > > References: > [1] https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http > [2] > https://datatracker.ietf.org/doc/draft-gupta-httpbis-per-resource-events > [3] https://datatracker.ietf.org/doc/draft-dunglas-mercure/ > [4] > https://datatracker.ietf.org/meeting/117/materials/slides-117-httpapi-byte-range-patch-00 > [5] https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/ > [6] https://datatracker.ietf.org/doc/draft-nottingham-http-invalidation/ > [7] https://www.npmjs.com/package/braid-http > [8] https://github.com/josephg/braid-protocol > [9] https://github.com/braid-org/wai-braid > [10] https://braid.org/sync9 > [11] https://github.com/josephg/diamond-types > [12] https://braid.org/automerge > [13] https://braid.org/demo/interoperate > [14] https://braid.org/algorithms/shelf > [15] https://github.com/braid-org/braid-chrome > [16] https://peeryview.org/about > [17] Simple Braid Chat: http://invisible.college:3007 > [18] Antimatter Wiki: > https://github.com/braid-org/braidjs/tree/master/antimatter_wiki and > https://wickie.invisible.college > [19] https://stateb.us/ > [20] https://github.com/brynbellomy/redwood >
- Proposal: Adopt State Synchronization into HTTPbis Michael Toomim
- Re: Proposal: Adopt State Synchronization into HT… Kévin Dunglas
- Re: Proposal: Adopt State Synchronization into HT… Watson Ladd