Re: [icnrg] This view on web3has some interesting ties to ICN

Joerg Ott <ott@in.tum.de> Tue, 11 January 2022 09:37 UTC

Return-Path: <ott@in.tum.de>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DCE3A20AD for <icnrg@ietfa.amsl.com>; Tue, 11 Jan 2022 01:37:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbQ_XCc4yVL8 for <icnrg@ietfa.amsl.com>; Tue, 11 Jan 2022 01:37:52 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3573A20AA for <icnrg@irtf.org>; Tue, 11 Jan 2022 01:37:51 -0800 (PST)
Received: from mailrelay1.rbg.tum.de (mailrelay1.in.tum.de [131.159.254.14]) by mail-out1.informatik.tu-muenchen.de (Postfix) with ESMTP id C2EFB2400E0; Tue, 11 Jan 2022 10:37:48 +0100 (CET)
Received: by mailrelay1.rbg.tum.de (Postfix, from userid 112) id C059146A; Tue, 11 Jan 2022 10:37:48 +0100 (CET)
Received: from mailrelay1.rbg.tum.de (localhost [127.0.0.1]) by mailrelay1.rbg.tum.de (Postfix) with ESMTP id 959ED1D7; Tue, 11 Jan 2022 10:37:48 +0100 (CET)
Received: from mail.in.tum.de (mailproxy.in.tum.de [IPv6:2a09:80c0::78]) by mailrelay1.rbg.tum.de (Postfix) with ESMTPS id 9387C1D4; Tue, 11 Jan 2022 10:37:48 +0100 (CET)
Received: by mail.in.tum.de (Postfix, from userid 112) id 90D944A05E9; Tue, 11 Jan 2022 10:37:48 +0100 (CET)
Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 8D2914A0586; Tue, 11 Jan 2022 10:37:45 +0100 (CET) (Extended-Queue-bit xtech_eg@fff.in.tum.de)
Message-ID: <af517675-482a-ab2d-c8ae-a10cf501e673@in.tum.de>
Date: Tue, 11 Jan 2022 10:37:44 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
Content-Language: en-US
To: "David R. Oran" <daveoran@orandom.net>, Dirk Kutscher <ietf@dkutscher.net>
Cc: icnrg <icnrg@irtf.org>
References: <FDAFD852-1109-4A49-9840-4C76716A8ECA@orandom.net> <08289530-AE53-4797-923D-2E49B1F7F9D8@dkutscher.net> <0BA97ECA-A99D-4594-A8E5-83B02D348539@orandom.net>
From: Joerg Ott <ott@in.tum.de>
In-Reply-To: <0BA97ECA-A99D-4594-A8E5-83B02D348539@orandom.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/5uXCBIEn2b9LBCjFtocz9-f57oE>
Subject: Re: [icnrg] This view on web3has some interesting ties to ICN
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jan 2022 09:37:55 -0000

Good start into the new year indeed.

I agree on Dave's "thorny", however, Dirk pointed especially to being
able to build local services.

We spent quite some time (with our liberouter and related work) on
designing local services where you actually do get back to your local
trust circles (the 5-25 people Dave mentioned) because you derive trust
from knowing people (even though trusting somebody doesn't automatically
translate into trusting somebody's service building/ops capabilities,
but let's leave that aside for a moment).

This allows ICNs (and related ideas) to help with building local
applications for which you would otherwise get a cloud instance from
some of usual cloud providers (who would also manage those for you).
This comes with the usual caveat of a distributed system that something
somewhere fails and your service stops working.

Especially for everything in-home or in-neighborhood uses there could be
alternatives, e.g., based on ICNs -- whenever it's not about global
reach, large numbers of followers, and so on.  Here, one could argue
that you could get trust somewhat organized (to be demonstrated as soon
as more than one household gets involved).

But you'd still need to get the infrastructure to store data and run
services on nevertheless, to be operated, e.g., by the members of your
local community network.  This appears to be another obstacle if you
wanted to overcome dependencies on the cloud and Internet connectivity.
There is probably a bit of a continuum to be explored on how much you
do locally and how much you rely on generic cloud (or edge) services.

And need to compete on the convenience of the cloud, including backups,
some notion of who is responsible and the corresponding "service level
agreements" as another practicality.

The market for most service designs today, such as IoT, seems to favor
cloud-based solutions.  Maybe for cost, simplicity of operating most
functions in controlled environment, not unlikely for data.  For web3-
style design of such services, (how) could ICN et al. provide a
competitive appeal to those designing them?

Jörg

On 10.01.22 22:28, David R. Oran wrote:
> Lots to unpack here, but I wanted to react to one particular piece since 
> it seems the basis for a lot of recent optimism about ICN for edge 
> applications, like IoT and localized multi-media such as some AR/VR.
> 
> On 10 Jan 2022, at 15:14, Dirk Kutscher wrote:
> 
>     Unlike most web3 systems, you can really build autonomous
>     application in local networks, i.e., operate in a decentralized way.
>     Moreover you can build systems accessing named data without location
>     notion at all, not only for files or web objects, but for any kind
>     of data and service.
> 
> 
> You might be able to build it, but some of the things that rapidly raise 
> themselves as thorny issues are:
> 
>   *
> 
>     you need to do a “leap of faith” enrollment on every single
>     participant in order to get the local trust root installed. This
>     might be somewhat sidestepped with key pinning to the application
>     code but then:
> 
>   *
> 
>     how do you install/update the application when the participant
>     enters the local trust zone with no root key or an expired one?
> 
>   *
> 
>     I’m increasingly convinced that a first order deterrent to this kind
>     of decentralization is the very small number of entities any
>     individual is able to assess trust in. I suspect it’s somewhere
>     between 5 and 25; not thousands or millions. Sure, I don’t want to
>     be forced to trust just one or two financial institutions, or just
>     my national government bureaucracy, or the small set of
>     Google/Microsoft/Amazon/Alibaba, etc. but how to I navigate
>     assessing a giant number of trust roots? It seems at least
>     superficially that web-of-trust approaches should work swimmingly
>     well here, but we have 30 years of abject failure (e.g. PGP/GPG) in
>     getting these adopted and maintained in practice.
> 
>   *
> 
>     If you find the point above modestly convincing, then current proven
>     and reasonably efficient K-out-of-N keying schemes for enabling
>     modestly-sized trusted intermediary sets, and Byzantine fault
>     tolerant agreement protocols for distributed databases seem quite
>     sufficient for all these use cases.
> 
> Nice New Year ICN discussion topic, no?
> 
> 
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg