[Din] Re: an AT protocol BOF at IETF 124

Lixia Zhang <lixia@cs.ucla.edu> Sat, 25 October 2025 02:15 UTC

Return-Path: <lixia@cs.ucla.edu>
X-Original-To: din@mail2.ietf.org
Delivered-To: din@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 1C7F07BED141 for <din@mail2.ietf.org>; Fri, 24 Oct 2025 19:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cs.ucla.edu
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkSTiqbrK4Ef for <din@mail2.ietf.org>; Fri, 24 Oct 2025 19:15:20 -0700 (PDT)
Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 73C8B7BED132 for <din@irtf.org>; Fri, 24 Oct 2025 19:15:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 0660E3C0149F3; Fri, 24 Oct 2025 19:15:19 -0700 (PDT)
Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id LMkf5Sz4_-B1; Fri, 24 Oct 2025 19:15:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id CF4103C0149F0; Fri, 24 Oct 2025 19:15:18 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu CF4103C0149F0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1761358518; bh=y6c8C0wFu9HBNF7tK/JxrWeABlsBLAJpcT7PMm71qu8=; h=From:Message-Id:Mime-Version:Date:To; b=f48ts3279fdhxZ22A3zmXaAow/r+jCEz+U505IQey9BVusXlX+eUOQtaY6jFV5cTA ZSW/gMXGfemSsRIrFZOjdXQwLkkxP+DgrKY2EzkaFkxmz02mI7kwMm/lvedBu/BVbp UTdyJEOeSJK16hdpzeqJAm91rKTa4aC9pUS8/xsTSQsZWt7/GdNbb4HjZlSX25vOZV WXjyqYm9izBCOExOdsvQ0dYU/Vyp4G8tqtCZ1+B770pFiLEJbPq2TUoa2NkCfYmiN3 35gcrJJGMq+v36Sh4JBOYH73bFdkLUWdiY0Kjg128B/G6r2PeJ3iIov0r1lG5J449L zcxBobSwV6sOA==
X-Virus-Scanned: amavis at mail.cs.ucla.edu
Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 6vU8XEoFl61P; Fri, 24 Oct 2025 19:15:18 -0700 (PDT)
Received: from smtpclient.apple (unknown [76.91.6.91]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 8FCDC3C0149EB; Fri, 24 Oct 2025 19:15:18 -0700 (PDT)
From: Lixia Zhang <lixia@cs.ucla.edu>
Message-Id: <D9247DF1-CFB7-40F2-9D11-185D2D8CD182@cs.ucla.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FB081C7-393F-41C3-A13F-CBDCE0F41128"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Date: Fri, 24 Oct 2025 19:15:07 -0700
In-Reply-To: <8fc282e2-16fb-4d06-b676-695852c3269a@app.fastmail.com>
To: Jon Crowcroft <jon.crowcroft=40cl.cam.ac.uk@dmarc.ietf.org>
References: <7949CF12-5352-42F7-91D8-57EB8E270B02@cs.ucla.edu> <8fc282e2-16fb-4d06-b676-695852c3269a@app.fastmail.com>
X-Mailer: Apple Mail (2.3826.700.81)
Message-ID-Hash: HDUJVPICRJWZU4GQ3RXMMZMCZFPKVNCL
X-Message-ID-Hash: HDUJVPICRJWZU4GQ3RXMMZMCZFPKVNCL
X-MailFrom: lixia@cs.ucla.edu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-din.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "din@irtf.org" <din@irtf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Din] Re: an AT protocol BOF at IETF 124
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/EOAViWkJNDrn24LdtlIEIr_f78o>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Owner: <mailto:din-owner@irtf.org>
List-Post: <mailto:din@irtf.org>
List-Subscribe: <mailto:din-join@irtf.org>
List-Unsubscribe: <mailto:din-leave@irtf.org>


> On Oct 24, 2025, at 2:29 AM, Jon Crowcroft <jon.crowcroft=40cl.cam.ac.uk@dmarc.ietf.org> wrote:
> 
> I guess the work in MIMI is also kind of related...

Hi Jon, I agree that MIMI is kind of related. 
Maybe we could discuss ATP as a specific design first, then apply what we learn from this first study to other related protocols?

Lixia

> On Fri, Oct 24, 2025, at 7:22 AM, Lixia Zhang wrote:
>> DINRG folks,
>> 
>> In case you have not noticed, an AT protocol BOF has been scheduled at IETF 124; I attached the BOF description below. Since Bluesky as a decentralized social app is built on the AT Protocol, this BOF should be highly relevant to DIN's interest.
>> 
>> A mailing list has also been set up for this BOF, people may be interested in joining the conversation: https://mailarchive.ietf.org/arch/browse/atp/ 
>> 
>> FYI, Lixia
>> ====================
>> Name: Authenticated Transfer BOF
>> Description: Self-Certifying data structures make it possible to efficiently synchronize public content across organizational boundaries, while preserving authenticity. These techniques have found broad adoption in some areas (such as software code versioning with git), but for the most part not in traditional web publishing or social web applications. On the social web today, authority and authenticity remain rooted in specific network locations and service providers, not network identities controlled by individuals or organizations.
>> 
>> Authenticated Transfer (AT) is a collection of protocol components which together provide a generic framework for interoperable social web applications, using self-certifying network data. The framework includes several components which could be in-scope for the IETF, as well as other components which are likely not. It builds on existing IETF technologies including CBOR, OAuth, HTTP, WebSockets, and DNS. The overall framework includes a schema system, but does not specify application-specific document formats.
>> 
>> This BoF is to discuss developing a narrowly-defined subset of protocol components within the IETF: the public repository data structure, wire serialization format, and public synchronization mechanism.
>> 
>> This follows a successful side-meeting at IETF 123 in Madrid, and many conversations with individuals over the years. The goal of this non-working-group-forming BoF is to open the topic to the entire IETF community for feedback, share experiences from early experimentation and implementation, and address as many chartering and scope questions as possible. This BoF would be followed on by a formal WG-forming BoF, possibly in an interim meeting.
>> 
>> _______________________________________________
>> Din mailing list -- din@irtf.org <mailto:din@irtf.org>
>> To unsubscribe send an email to din-leave@irtf.org <mailto:din-leave@irtf.org>
>> 
> 
> _______________________________________________
> Din mailing list -- din@irtf.org
> To unsubscribe send an email to din-leave@irtf.org