Re: [Din] Fwd: [arch-d] RFC 9518 - Centralization, Decentralization, and Internet Standards

Bumblefudge <bumblefudge@learningproof.xyz> Tue, 23 January 2024 20:06 UTC

Return-Path: <bumblefudge@learningproof.xyz>
X-Original-To: din@ietfa.amsl.com
Delivered-To: din@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7763C14F711 for <din@ietfa.amsl.com>; Tue, 23 Jan 2024 12:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Level:
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 BXrkC-f-wr24 for <din@ietfa.amsl.com>; Tue, 23 Jan 2024 12:06:49 -0800 (PST)
Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51911C14F5F3 for <din@irtf.org>; Tue, 23 Jan 2024 12:06:49 -0800 (PST)
Date: Tue, 23 Jan 2024 20:06:30 +0000
To: din@irtf.org
From: Bumblefudge <bumblefudge@learningproof.xyz>
Message-ID: <7d030d9d-0e45-42cd-be66-8cd0165927c1@learningproof.xyz>
Feedback-ID: 85909410:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_RNtSMvPz4e7DYwRFoHm9p55U1utRdbvqRMyjvgfiFg"
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/fgI5_M3lli5ZNZzpOH-GEigjoGo>
Subject: Re: [Din] Fwd: [arch-d] RFC 9518 - Centralization, Decentralization, and Internet Standards
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
List-Unsubscribe: <https://mailman.irtf.org/mailman/options/din>, <mailto:din-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din/>
List-Post: <mailto:din@irtf.org>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Subscribe: <https://mailman.irtf.org/mailman/listinfo/din>, <mailto:din-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2024 20:06:53 -0000

Dear Eliot:

Thanks for this email, sorry I missed it in the holiday shuffle.

>  Are there interchange standards for "Social Networking" that would allow one to pull up tent and move? For instance, there is a bit of a discussion about Nazis on Substack. Here's one view.https://ianbetteridge.substack.com/p/substack-and-platform-risk.

https://ianbetteridge.com/2023/12/22/substack-and-platform-risk/
Looks like Ian deplatformed himself! Good on him.

ActivityPub would be the most ambitious attempt yet, I think, to publish and implement such a standard, but in some ways it's a bit incomplete qua standard because there were still a lot of rough edges and TBDs in the specifications when the WG spun down in 2019, and only now is there work underway to bootstrap community conformance tooling. That said, Discourse and Wordpress rolling out partial ActivityPub support goes a long way, regardless of what happens with Big Blue. I'm involved to some degree in those conformance/standards-finishing efforts over in W3C so happy answer questions in DM or in a format interesting to this group? References:
https://socialhub.activitypub.rocks/t/guide-for-activitypub-users/509
https://www.w3.org/TR/activitypub/#specification-profiles

> What can we take from the combination of Mark's points around
    governance and federation?  Are there federation governance models
    that can be used to reduce "lock in" for a particular function?

This is probably the trillion-dollar question, and I wonder if mapping protocols directly to outcomes is skipping too many steps. One historical detail often overlooked in the both excessively hagiographical or excessively skeptical histories of the evolution of cryptocurrency is that hashcash, in some ways the kernel that became PoW and other blockchain consensus mechanisms, was invented as a spam-protection system layered onto email to protect federation from excess traffic as described in that paragraph of RFC 9518. So while email spam incentivized the closed platforms of email, it also inspired later protocols to defend themselves from these business incentivizes by incorporating currency into themselves. Not a silver bullet, to be sure (indeed, now we have entire blockchains devoted to spam!), but a necessary part of the conversation, I would think...

Thanks,
__bumblefudge