From nam10114 at nyu.edu  Sun Apr  6 14:20:01 2025
From: nam10114 at nyu.edu (Ender Minyard)
Date: Sun, 6 Apr 2025 17:20:01 -0400
Subject: [Ndn-interest] Understanding Named Data Networking
Message-ID: <CAGM+u79gbi8F0wttAQO30vtwWRX-qt98Q9N3+HNHRyRmy2ZY4w@mail.gmail.com>

Hi,

I came across Named Data Networking in this piece of writing
<https://worrydream.com/ClimateChange/> which seemed to claim that Named
Data Networking can address the issue of excessive energy consumption. From
an initial impression, the content delivery strategy of the protocol
reminds me of IPFS CIDs
<https://docs.ipfs.tech/concepts/content-addressing/>. Is this
over-simplified understanding of Named Data Networking accurate whatsoever?

I did see that there are publications on the website, but I would like to
develop a lay person's understanding of the protocol before getting into
details. I would also like to figure out about other networking protocols
that [are/can be] designed to reduce energy consumption.

I have read the executive summary
<https://named-data.net/project/execsummary/> - if there is another
beginner-friendly resource that you would recommend, please let me know.

Thank you for your time,
Ender
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20250406/ccea3d35/attachment.htm>

From varunpatil at ucla.edu  Mon Apr  7 12:17:54 2025
From: varunpatil at ucla.edu (Varun Patil)
Date: Mon, 7 Apr 2025 12:17:54 -0700
Subject: [Ndn-interest] Understanding Named Data Networking
In-Reply-To: <CAGM+u79gbi8F0wttAQO30vtwWRX-qt98Q9N3+HNHRyRmy2ZY4w@mail.gmail.com>
References: <CAGM+u79gbi8F0wttAQO30vtwWRX-qt98Q9N3+HNHRyRmy2ZY4w@mail.gmail.com>
Message-ID: <CAGEdXQ=iQrb_zyTHqyMmOJJ30AGLx-t_Am1HWad5d1dAaMKREw@mail.gmail.com>

Hi Ender,

> From an initial impression, the content delivery strategy of the protocol reminds me of IPFS CIDs.

A key difference is IPFS CIDs are just hashes of the content, they are
not meaningful in themselves. In NDN, each data object is
*semantically* named. Importantly, the data names are used for
security - to establish trust relations between data and data
producers using well-defined naming rules.

This makes it possible to build real applications over NDN (unlike
IPFS, which is just a storage layer). But even If you're looking only
at content delivery, the design is very different from IPFS.

> I have read the executive summary - if there is another beginner-friendly resource that you would recommend, please let me know.

The NDN 101 page is still a work in progress, but is useful as a
tutorial - https://101.named-data.net/

Most of the details can be found over the many papers written over the
years. The 101 page has some pointers to these but other people here
could have specific suggestions.

Best,
Varun

On Sun, Apr 6, 2025 at 7:06?PM Ender Minyard via Ndn-interest
<ndn-interest at lists.cs.ucla.edu> wrote:
>
> Hi,
>
> I came across Named Data Networking in this piece of writing which seemed to claim that Named Data Networking can address the issue of excessive energy consumption. From an initial impression, the content delivery strategy of the protocol reminds me of IPFS CIDs. Is this over-simplified understanding of Named Data Networking accurate whatsoever?
>
> I did see that there are publications on the website, but I would like to develop a lay person's understanding of the protocol before getting into details. I would also like to figure out about other networking protocols that [are/can be] designed to reduce energy consumption.
>
> I have read the executive summary - if there is another beginner-friendly resource that you would recommend, please let me know.
>
> Thank you for your time,
> Ender
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

From hello at kyra.run  Tue Apr 15 14:14:49 2025
From: hello at kyra.run (Kyra)
Date: Tue, 15 Apr 2025 16:14:49 -0500
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
Message-ID: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>

Hello!

For wider discussion, I am cross-posting an idea I added to github here:
https://github.com/named-data-mobile/ndn-photo-app/issues/186

Average users could get so much value out of a simple and intuitive p2p
> file-syncing service that is as polished as ResilioSync
> <https://www.resilio.com/sync/>, provides revision control on arbitrary
> files like Abstract (version control for designers)
> <https://www.goabstract.com/>, but open source like LibreVault
> <https://github.com/librevault/librevault> & SyncThing
> <https://syncthing.net/>, plus backed by a distributed revision/version
> control system (DRCS/DVCS)? like SparkleShare
> <https://www.sparkleshare.org/>. This would be priceless for science,
> design, all sorts of collaborative workspaces, and especially for backups
> and data redundancy.
>
> Currently, git-annex <https://git-annex.branchable.com/> depends on Tor
> and Magic Wormhole <https://github.com/magic-wormhole/magic-wormhole> to
> share/collaborate/sync with others. There is Hypercore
> <https://docs.pears.com/building-blocks/hypercore> by Holepunch
> <https://holepunch.to/>, but since an experiment for "Distributed Git
> over Named Data Networking <https://github.com/JonnyKong/GitSync>" and
> npChat already exists, could a collaboration between Named-Data and
> git-annex
> <https://git-annex.branchable.com/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN/>
> allow for a built-in method for connections to be made for git-annex and
> set the foundation?pave the way?for the perfect file
> synchronization/sharing app?
>
> *? Although, it might be nice to use Pijul
> <https://pijul.org/manual/why_pijul.html>, which has efficint binary diffs
> <https://pijul.org/posts/2021-06-28-two-changes/> and hopefully someday
> also word-by-word diffs
> <https://discourse.pijul.org/t/fast-characterwise-and-binary-patches/32/9>
> (for example, to be the revision control system for a wiki)*


Thanks,
Kyra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20250415/9876d38b/attachment.htm>

From varunpatil at ucla.edu  Tue Apr 15 20:24:42 2025
From: varunpatil at ucla.edu (Varun Patil)
Date: Tue, 15 Apr 2025 20:24:42 -0700
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
Message-ID: <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>

Hi Kyra,

> Average users could get so much value out of a simple and intuitive p2p file-syncing service that is as polished as ResilioSync, provides revision control on arbitrary files like Abstract (version control for designers), but open source like LibreVault & SyncThing, plus backed by a distributed revision/version control system (DRCS/DVCS) like SparkleShare. This would be priceless for science, design, all sorts of collaborative workspaces, and especially for backups and data redundancy.

Yes, indeed. "Ownly" is one of the more recent NDN projects that is
trying to build parts of this, albeit there is no version control at
the moment (it is more directly intended to replace Google Docs and/or
Overleaf, so the focus is on realtime collaborative editing). But it
does, for instance, provide a p2p local-first (while supporting remote
storage/backups with NDN repo) file sync service for a group of users,
and the data can be end-to-end encrypted.

One note - since this needs a network layer change, the implementation
does require a functional NDN overlay network; currently we use the
global NDN testbed for this purpose [1]. But all of this software is
open source and it is reasonably straightforward to set up an NDN
overlay of your own, or (in the furture) peer with existing overlays
like the internet.

I'll leave some references below --
GitHub repo: https://github.com/pulsejet/ownly
A slightly outdated design paper: https://arxiv.org/pdf/2407.15234v1
The app itself: https://ownly.work

> Currently, git-annex depends on Tor and Magic Wormhole to share/collaborate/sync with others. There is Hypercore by Holepunch, but since an experiment for "Distributed Git over Named Data Networking" and npChat already exists, could a collaboration between Named-Data and git-annex allow for a built-in method for connections to be made for git-annex and set the foundation?pave the way?for the perfect file synchronization/sharing app?

I'm not familiar with the details of the GitSync experiment; others
might chime in. But I want to note that the (IMO more important)
problem that NDN solves is security in these distributed-decentralized
apps, rather than just providing a p2p transport (which is just part
of the puzzle). As for retrofitting existing applications with such a
transport, this is possible in certain cases (e.g. for apps using a
pub/sub API - replacing it with an NDN equivalent like SVS-PS [2]).
But generally speaking this is non-trivial: NDN being a data-centric
architecture has no "connections", but most existing app
implementations are (unfortunately) too intricately tied up with the
TCP/IP connection model.

[1] https://named-data.net/ndn-testbed/
[2] https://named-data.net/wp-content/uploads/2022/03/Resilient_Brokerless_Publish-Subscribe_over_NDN.pdf

Best,
Varun

On Tue, Apr 15, 2025 at 2:15?PM Kyra <hello at kyra.run> wrote:
>
>
> Hello!
>
> For wider discussion, I am cross-posting an idea I added to github here: https://github.com/named-data-mobile/ndn-photo-app/issues/186
>
>> Average users could get so much value out of a simple and intuitive p2p file-syncing service that is as polished as ResilioSync, provides revision control on arbitrary files like Abstract (version control for designers), but open source like LibreVault & SyncThing, plus backed by a distributed revision/version control system (DRCS/DVCS)? like SparkleShare. This would be priceless for science, design, all sorts of collaborative workspaces, and especially for backups and data redundancy.
>>
>> Currently, git-annex depends on Tor and Magic Wormhole to share/collaborate/sync with others. There is Hypercore by Holepunch, but since an experiment for "Distributed Git over Named Data Networking" and npChat already exists, could a collaboration between Named-Data and git-annex allow for a built-in method for connections to be made for git-annex and set the foundation?pave the way?for the perfect file synchronization/sharing app?
>>
>> ? Although, it might be nice to use Pijul, which has efficint binary diffs and hopefully someday also word-by-word diffs (for example, to be the revision control system for a wiki)
>
>
> Thanks,
> Kyra
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

From fotiou at aueb.gr  Wed Apr 16 03:18:16 2025
From: fotiou at aueb.gr (Nikos Fotiou)
Date: Wed, 16 Apr 2025 13:18:16 +0300
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
 <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
Message-ID: <9A97FEC5-A90B-4299-BFA3-56D92901773D@aueb.gr>

As a side note https://github.com/pulsejet/ownly looks amazing. I love how it ?hides? NDN from the end-user. Congratulations to the team.

Best,
Nikos

> On 16 Apr 2025, at 6:24?AM, Varun Patil via Ndn-interest <ndn-interest at lists.cs.ucla.edu> wrote:
> 
> Hi Kyra,
> 
>> Average users could get so much value out of a simple and intuitive p2p file-syncing service that is as polished as ResilioSync, provides revision control on arbitrary files like Abstract (version control for designers), but open source like LibreVault & SyncThing, plus backed by a distributed revision/version control system (DRCS/DVCS) like SparkleShare. This would be priceless for science, design, all sorts of collaborative workspaces, and especially for backups and data redundancy.
> 
> Yes, indeed. "Ownly" is one of the more recent NDN projects that is
> trying to build parts of this, albeit there is no version control at
> the moment (it is more directly intended to replace Google Docs and/or
> Overleaf, so the focus is on realtime collaborative editing). But it
> does, for instance, provide a p2p local-first (while supporting remote
> storage/backups with NDN repo) file sync service for a group of users,
> and the data can be end-to-end encrypted.
> 
> One note - since this needs a network layer change, the implementation
> does require a functional NDN overlay network; currently we use the
> global NDN testbed for this purpose [1]. But all of this software is
> open source and it is reasonably straightforward to set up an NDN
> overlay of your own, or (in the furture) peer with existing overlays
> like the internet.
> 
> I'll leave some references below --
> GitHub repo: https://github.com/pulsejet/ownly
> A slightly outdated design paper: https://arxiv.org/pdf/2407.15234v1
> The app itself: https://ownly.work
> 
>> Currently, git-annex depends on Tor and Magic Wormhole to share/collaborate/sync with others. There is Hypercore by Holepunch, but since an experiment for "Distributed Git over Named Data Networking" and npChat already exists, could a collaboration between Named-Data and git-annex allow for a built-in method for connections to be made for git-annex and set the foundation?pave the way?for the perfect file synchronization/sharing app?
> 
> I'm not familiar with the details of the GitSync experiment; others
> might chime in. But I want to note that the (IMO more important)
> problem that NDN solves is security in these distributed-decentralized
> apps, rather than just providing a p2p transport (which is just part
> of the puzzle). As for retrofitting existing applications with such a
> transport, this is possible in certain cases (e.g. for apps using a
> pub/sub API - replacing it with an NDN equivalent like SVS-PS [2]).
> But generally speaking this is non-trivial: NDN being a data-centric
> architecture has no "connections", but most existing app
> implementations are (unfortunately) too intricately tied up with the
> TCP/IP connection model.
> 
> [1] https://named-data.net/ndn-testbed/
> [2] https://named-data.net/wp-content/uploads/2022/03/Resilient_Brokerless_Publish-Subscribe_over_NDN.pdf
> 
> Best,
> Varun
> 
> On Tue, Apr 15, 2025 at 2:15?PM Kyra <hello at kyra.run> wrote:
>> 
>> 
>> Hello!
>> 
>> For wider discussion, I am cross-posting an idea I added to github here: https://github.com/named-data-mobile/ndn-photo-app/issues/186
>> 
>>> Average users could get so much value out of a simple and intuitive p2p file-syncing service that is as polished as ResilioSync, provides revision control on arbitrary files like Abstract (version control for designers), but open source like LibreVault & SyncThing, plus backed by a distributed revision/version control system (DRCS/DVCS)? like SparkleShare. This would be priceless for science, design, all sorts of collaborative workspaces, and especially for backups and data redundancy.
>>> 
>>> Currently, git-annex depends on Tor and Magic Wormhole to share/collaborate/sync with others. There is Hypercore by Holepunch, but since an experiment for "Distributed Git over Named Data Networking" and npChat already exists, could a collaboration between Named-Data and git-annex allow for a built-in method for connections to be made for git-annex and set the foundation?pave the way?for the perfect file synchronization/sharing app?
>>> 
>>> ? Although, it might be nice to use Pijul, which has efficint binary diffs and hopefully someday also word-by-word diffs (for example, to be the revision control system for a wiki)
>> 
>> 
>> Thanks,
>> Kyra
>> 
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest


From hello at kyra.run  Wed Apr 16 06:04:42 2025
From: hello at kyra.run (Kyra)
Date: Wed, 16 Apr 2025 08:04:42 -0500
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
 <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
Message-ID: <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>

On Tue, Apr 15, 2025 at 10:25?PM Varun Patil <varunpatil at ucla.edu> wrote:

> > Average users could get so much value out of a simple and intuitive p2p
> file-syncing service that is as polished as ResilioSync, provides revision
> control on arbitrary files like Abstract (version control for designers),
> but open source like LibreVault & SyncThing, plus backed by a distributed
> revision/version control system (DRCS/DVCS) like SparkleShare. This would
> be priceless for science, design, all sorts of collaborative workspaces,
> and especially for backups and data redundancy.
>
> Yes, indeed. "Ownly" is one of the more recent NDN projects that is
> trying to build parts of this, albeit there is no version control at
> the moment (it is more directly intended to replace Google Docs and/or
> Overleaf, so the focus is on realtime collaborative editing).


This sounds perfect! I've moved my ticket to their github instead:
https://github.com/pulsejet/ownly/issues/49


> But it
> does, for instance, provide a p2p local-first (while supporting remote
> storage/backups with NDN repo) file sync service for a group of users,
> and the data can be end-to-end encrypted.
>

Wow, wait?do you mention 'local-first' because you've seen me recently
share this idea for a local-first e2ee notion-alternative built on Matrix
(federated graph database synchronization protocol) for collaboration?
https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391

That was more of a pipe dream, because I don't think e2ee could be done
properly with git-annex (or a hypothetical pijul-annex) given using one
DRCS/DVCS or another as the data/revision store since the whole thing could
only be encrypted as a blob with a static decryption key, and not for each
modification in transit between peers with partial or perfect-forward
secrecy
<https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#partial-forward-secrecy>.
Maybe down the line someone can work on Matrix on top of NDN.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20250416/3b8c9edf/attachment-0001.htm>

From mixis at filts.net  Wed Apr 16 06:52:04 2025
From: mixis at filts.net (=?UTF-8?Q?Michael_Wei=C3=9F?=)
Date: Wed, 16 Apr 2025 15:52:04 +0200 (GMT+02:00)
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
 <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
 <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>
Message-ID: <2da34d58-4e27-4a72-b5e9-7e7054069674@filts.net>

Hi there, thank you for reviving this list. I really enjoy following your discussions.

As a matrix operator, I can see some pitfalls, and I think the federated design of matrix is a little challenging. I too am pondering, what a better design would look like.

I'd rather reduce the Home Server to a rendezvous point.

At least with synapse, the state-groups-state-table tends to grow faster than Moore drops storage costs, even though some constant factors can be trimmed.

I have a hunch, that something along the lines of STARKs, SNARGs, SNARKS, or whatever flavor of succinct, recursive proof system, can be a great fit for ledger systems, but the math is way over my head.

Just wanted to get that out there, since, apparently, I have a whole lot to follow up on.

Have a fantastic time:)

From lixia at cs.ucla.edu  Wed Apr 16 08:00:10 2025
From: lixia at cs.ucla.edu (Lixia Zhang)
Date: Wed, 16 Apr 2025 08:00:10 -0700
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
 <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
 <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>
Message-ID: <9284117D-0ECE-4779-AE29-F087566F29C8@cs.ucla.edu>


> On Apr 16, 2025, at 6:04?AM, Kyra <hello at kyra.run> wrote:
> 
> ......
>> But it
>> does, for instance, provide a p2p local-first (while supporting remote
>> storage/backups with NDN repo) file sync service for a group of users,
>> and the data can be end-to-end encrypted.
> 
> Wow, wait?do you mention 'local-first' because you've seen me recently share this idea for a local-first e2ee notion-alternative built on Matrix (federated graph database synchronization protocol) for collaboration? https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391

the above link gave me an error "Idea Not Found"

About the mentioning of 'local-first': that's been a well-known concept for some time now.  e.g. at IETF 118 (Nov'23) DIN RG meeting, Martin Kleppmann gave a greate talk on "Local-First Software"
(see https://datatracker.ietf.org/meeting/118/session/dinrg for the talk slides and recording)

> That was more of a pipe dream, because I don't think e2ee could be done properly with git-annex (or a hypothetical pijul-annex) given using one DRCS/DVCS or another as the data/revision store since the whole thing could only be encrypted as a blob with a static decryption key, and not for each modification in transit between peers with partial or perfect-forward secrecy. Maybe down the line someone can work on Matrix on top of NDN.

I dont know Matrix, it sounds like one of the decentralized app efforts. AT NDN Community meeting tomorrow (https://ndncomm2025.named-data.net/program.html), the first talk will be the design of Ownly followed by a handson, and the 2nd session is a panel discussion on what it takes to develop truly decentralized apps.

Lixia


From hello at kyra.run  Wed Apr 16 09:47:43 2025
From: hello at kyra.run (Kyra)
Date: Wed, 16 Apr 2025 11:47:43 -0500
Subject: [Ndn-interest] Matrix (chat/discussion) community
Message-ID: <CAOs69ojxv=tDxD-XpG5za7j8zyHvh0svYfxCyersD7ZpAB=fkw@mail.gmail.com>

Hello all,

Would anyone be interested in joining a Matrix space for devs and users of
NDN and the projects built on it? If there is an existing Slack community,
it is possible to bridge the two together, which I could also help with!

https://matrix.to/#/!RkDNVxRnwLVkyePTSc:matrix.org

Best,
Kyra

Forking from previous discussion "Version-controlled file-syncing/sharing
(collaboration with git-annex?)":
http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2025-April/003070.html

On Wed, Apr 16, 2025 at 10:00?AM Lixia Zhang <lixia at cs.ucla.edu> wrote:

>
> > On Apr 16, 2025, at 6:04?AM, Kyra <hello at kyra.run> wrote:
> > idea for a local-first e2ee notion-alternative built on Matrix
> (federated graph database synchronization protocol) for collaboration?
> https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391
>
> the above link gave me an error "Idea Not Found"
>

Oops, it must've been under moderation again due to an edit I made, but
it's online again (and also visible on https://archive.today as well as
https://web.archive.org/

(see https://datatracker.ietf.org/meeting/118/session/dinrg for the talk
> slides and recording)
>

Ah, thank you! Very cool


> I dont know Matrix, it sounds like one of the decentralized app efforts.


Yes, it  is a federated graph database resolution protocol, currently
focused primarily on realtime chat similar to Slack, Teams, and Discord. It
has wide institutional backing, used by Mozilla, France (Tchap), Gitter,
Germany (TI-Messenger), Sweden (Tele2), United Nations (ICC),
BigBlueButton, Ridgeline International, NATO (NI2CE), and openDesk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20250416/2dfdd003/attachment.htm>

From varunpatil at ucla.edu  Wed Apr 16 10:49:32 2025
From: varunpatil at ucla.edu (Varun Patil)
Date: Wed, 16 Apr 2025 10:49:32 -0700
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <9284117D-0ECE-4779-AE29-F087566F29C8@cs.ucla.edu>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
 <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
 <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>
 <9284117D-0ECE-4779-AE29-F087566F29C8@cs.ucla.edu>
Message-ID: <CAGEdXQn2mqG_w0Db3ME+2Vzrw-YCpqPoLC6wxeqpSXAoSJtXEQ@mail.gmail.com>

> As a side note https://github.com/pulsejet/ownly looks amazing. I love how it ?hides? NDN from the end-user. Congratulations to the team.

Thank you! Indeed our focus recently has been on end-user usability;
IMO NDN is now sufficiently mature to develop "real" applications, but
we need more concrete steps in this direction (kudos to Xinyu for
getting the effort started).

> Wow, wait?do you mention 'local-first' because you've seen me recently share this idea for a local-first e2ee notion-alternative built on Matrix (federated graph database synchronization protocol) for collaboration?

Interesting proposal.

1/ I'm not very familiar with the Matrix protocol but (from vague
memory) my understanding is that the homeserver has more control power
than ideal. Granted that it is possible to run your own server, this
practically never happens as the app scales - inevitably leading back
to a centralized control point.

2/ Ownly tries for a different direction - it still needs
infrastructure but the infrastructure is *untrusted* (e.g. NDN repo -
just a data store without gatekeeping functions). Note that this is
still very much a work in progress/research - for instance we still
(at least partially) rely on the testbed NDNCERT instance for
bootstrapping user identity.

But the ideal outcome is that users can easily pay for this
infrastructure from a choice of multiple providers, without these
providers having any control power whatsoever (and allow
multi-homing). As a direct analogy, this would be like your ISP - you
do rely on them and not run your own fibers, but it is always possible
to switch - and your ISP has no control on what you do.

3/ I do like the idea of doing this *inside* the browser, but I expect
this to be a much harder direction to push for. It is likely (much)
easier to build the application over the web platform, which already
supports a variety of these use cases - for instance Ownly heavily
relies on WebAssembly and OPFS for the local-first bits; these
features have broad browser support.

> That was more of a pipe dream, because I don't think e2ee could be done properly with git-annex ...

Generally speaking I expect some trade-offs here. Forward secrecy
makes sense for point-to-point connections but it gets iffy when we're
talking about this kind of application. For instance there may be a
*legitimate* reason to decrypt previously exchanged data now (e.g. a
new person joining a group that has previously uploaded files). We may
need a re-definition of what forward secrecy means / is trying to
achieve in this context.

As for exchanging deltas, this is an application layer requirement.
Not sure, but I imagine this should technically be possible with any
kind of diffing algorithm - for Ownly we use Y.js CRDT (though the
hard problem it solves is automated conflict resolution).

> I'd rather reduce the Home Server to a rendezvous point.

This may be in line with what I was referring to above.
Note that in NDN, the packet forwarder (e.g. NFD) takes up part of
this job - a pure network rendezvous point.

> At least with synapse, the state-groups-state-table tends to grow faster than Moore drops storage costs, even though some constant factors can be trimmed.
> I have a hunch, that something along the lines of STARKs, SNARGs, SNARKS, or whatever flavor of succinct, recursive proof system, can be a great fit for ledger systems, but the math is way over my head.

(High level comment) One of the questions is *what* goes onto a
ledger. NDN arguably still needs a ledger, but only for
identities/certificates - all other application data is effectively
and provably connected using name-based relations. The key ideas -
structured and semantically meaningful naming conventions and rules
that bind different names together.

> At NDN Community meeting tomorrow (https://ndncomm2025.named-data.net/program.html), the first talk will be the design of Ownly

I believe the remote registration is still open, if anyone interested
to join. I'll leave pointer below.
https://ndncomm2025.named-data.net/registration.html

Best,
Varun

On Wed, Apr 16, 2025 at 8:00?AM Lixia Zhang via Ndn-interest
<ndn-interest at lists.cs.ucla.edu> wrote:
>
>
> > On Apr 16, 2025, at 6:04?AM, Kyra <hello at kyra.run> wrote:
> >
> > ......
> >> But it
> >> does, for instance, provide a p2p local-first (while supporting remote
> >> storage/backups with NDN repo) file sync service for a group of users,
> >> and the data can be end-to-end encrypted.
> >
> > Wow, wait?do you mention 'local-first' because you've seen me recently share this idea for a local-first e2ee notion-alternative built on Matrix (federated graph database synchronization protocol) for collaboration? https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391
>
> the above link gave me an error "Idea Not Found"
>
> About the mentioning of 'local-first': that's been a well-known concept for some time now.  e.g. at IETF 118 (Nov'23) DIN RG meeting, Martin Kleppmann gave a greate talk on "Local-First Software"
> (see https://datatracker.ietf.org/meeting/118/session/dinrg for the talk slides and recording)
>
> > That was more of a pipe dream, because I don't think e2ee could be done properly with git-annex (or a hypothetical pijul-annex) given using one DRCS/DVCS or another as the data/revision store since the whole thing could only be encrypted as a blob with a static decryption key, and not for each modification in transit between peers with partial or perfect-forward secrecy. Maybe down the line someone can work on Matrix on top of NDN.
>
> I dont know Matrix, it sounds like one of the decentralized app efforts. AT NDN Community meeting tomorrow (https://ndncomm2025.named-data.net/program.html), the first talk will be the design of Ownly followed by a handson, and the 2nd session is a panel discussion on what it takes to develop truly decentralized apps.
>
> Lixia
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

From davidepesa at gmail.com  Wed Apr 16 12:12:00 2025
From: davidepesa at gmail.com (Davide Pesavento)
Date: Wed, 16 Apr 2025 15:12:00 -0400
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <CAGEdXQn2mqG_w0Db3ME+2Vzrw-YCpqPoLC6wxeqpSXAoSJtXEQ@mail.gmail.com>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
 <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
 <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>
 <9284117D-0ECE-4779-AE29-F087566F29C8@cs.ucla.edu>
 <CAGEdXQn2mqG_w0Db3ME+2Vzrw-YCpqPoLC6wxeqpSXAoSJtXEQ@mail.gmail.com>
Message-ID: <CADfzvvbqAPuNSiscWBUX+LLutDS6MBsF91DD0pt=CeJK7MbP_w@mail.gmail.com>

On Wed, Apr 16, 2025 at 1:50?PM Varun Patil via Ndn-interest
<ndn-interest at lists.cs.ucla.edu> wrote:
>
> > As a side note https://github.com/pulsejet/ownly looks amazing. I love how it ?hides? NDN from the end-user. Congratulations to the team.
>
> Thank you! Indeed our focus recently has been on end-user usability;
> IMO NDN is now sufficiently mature to develop "real" applications, but
> we need more concrete steps in this direction (kudos to Xinyu for
> getting the effort started).
>
> > Wow, wait?do you mention 'local-first' because you've seen me recently share this idea for a local-first e2ee notion-alternative built on Matrix (federated graph database synchronization protocol) for collaboration?
>
> Interesting proposal.
>
> 1/ I'm not very familiar with the Matrix protocol but (from vague
> memory) my understanding is that the homeserver has more control power
> than ideal. Granted that it is possible to run your own server, this
> practically never happens as the app scales - inevitably leading back
> to a centralized control point.
>
> 2/ Ownly tries for a different direction - it still needs
> infrastructure but the infrastructure is *untrusted* (e.g. NDN repo -
> just a data store without gatekeeping functions). Note that this is
> still very much a work in progress/research - for instance we still
> (at least partially) rely on the testbed NDNCERT instance for
> bootstrapping user identity.
>
> But the ideal outcome is that users can easily pay for this
> infrastructure from a choice of multiple providers, without these
> providers having any control power whatsoever (and allow
> multi-homing). As a direct analogy, this would be like your ISP - you
> do rely on them and not run your own fibers, but it is always possible
> to switch - and your ISP has no control on what you do.
>
> 3/ I do like the idea of doing this *inside* the browser, but I expect
> this to be a much harder direction to push for. It is likely (much)
> easier to build the application over the web platform, which already
> supports a variety of these use cases - for instance Ownly heavily
> relies on WebAssembly and OPFS for the local-first bits; these
> features have broad browser support.
>
> > That was more of a pipe dream, because I don't think e2ee could be done properly with git-annex ...
>
> Generally speaking I expect some trade-offs here. Forward secrecy
> makes sense for point-to-point connections but it gets iffy when we're
> talking about this kind of application. For instance there may be a
> *legitimate* reason to decrypt previously exchanged data now (e.g. a
> new person joining a group that has previously uploaded files).

I don't think this has anything to do with the "type" of communication
(group vs. point-to-point). It is entirely dependent on the use
case/application. I see forward secrecy as a spectrum rather than a
binary thing. How frequently you ratchet your state (assuming a
ratchet-based protocol) determines the "amount" of forward secrecy
that you get. So if you need to make past communication more readily
(and efficiently) available, then either ratchet less frequently or
store more past states. This of course makes a future compromise more
catastrophic. It's a tradeoff, like many things, but it should be
driven by the application use case or the specific context in which it
is being used. In the example of secure (group) messaging, both
allowing and not allowing new participants to access past history are
valid use cases.

> We may
> need a re-definition of what forward secrecy means / is trying to
> achieve in this context.
>
> As for exchanging deltas, this is an application layer requirement.
> Not sure, but I imagine this should technically be possible with any
> kind of diffing algorithm - for Ownly we use Y.js CRDT (though the
> hard problem it solves is automated conflict resolution).
>
> > I'd rather reduce the Home Server to a rendezvous point.
>
> This may be in line with what I was referring to above.
> Note that in NDN, the packet forwarder (e.g. NFD) takes up part of
> this job - a pure network rendezvous point.
>
> > At least with synapse, the state-groups-state-table tends to grow faster than Moore drops storage costs, even though some constant factors can be trimmed.
> > I have a hunch, that something along the lines of STARKs, SNARGs, SNARKS, or whatever flavor of succinct, recursive proof system, can be a great fit for ledger systems, but the math is way over my head.
>
> (High level comment) One of the questions is *what* goes onto a
> ledger. NDN arguably still needs a ledger, but only for
> identities/certificates - all other application data is effectively
> and provably connected using name-based relations. The key ideas -
> structured and semantically meaningful naming conventions and rules
> that bind different names together.
>
> > At NDN Community meeting tomorrow (https://ndncomm2025.named-data.net/program.html), the first talk will be the design of Ownly
>
> I believe the remote registration is still open, if anyone interested
> to join. I'll leave pointer below.
> https://ndncomm2025.named-data.net/registration.html
>
> Best,
> Varun
>
> On Wed, Apr 16, 2025 at 8:00?AM Lixia Zhang via Ndn-interest
> <ndn-interest at lists.cs.ucla.edu> wrote:
> >
> >
> > > On Apr 16, 2025, at 6:04?AM, Kyra <hello at kyra.run> wrote:
> > >
> > > ......
> > >> But it
> > >> does, for instance, provide a p2p local-first (while supporting remote
> > >> storage/backups with NDN repo) file sync service for a group of users,
> > >> and the data can be end-to-end encrypted.
> > >
> > > Wow, wait?do you mention 'local-first' because you've seen me recently share this idea for a local-first e2ee notion-alternative built on Matrix (federated graph database synchronization protocol) for collaboration? https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391
> >
> > the above link gave me an error "Idea Not Found"
> >
> > About the mentioning of 'local-first': that's been a well-known concept for some time now.  e.g. at IETF 118 (Nov'23) DIN RG meeting, Martin Kleppmann gave a greate talk on "Local-First Software"
> > (see https://datatracker.ietf.org/meeting/118/session/dinrg for the talk slides and recording)
> >
> > > That was more of a pipe dream, because I don't think e2ee could be done properly with git-annex (or a hypothetical pijul-annex) given using one DRCS/DVCS or another as the data/revision store since the whole thing could only be encrypted as a blob with a static decryption key, and not for each modification in transit between peers with partial or perfect-forward secrecy. Maybe down the line someone can work on Matrix on top of NDN.
> >
> > I dont know Matrix, it sounds like one of the decentralized app efforts. AT NDN Community meeting tomorrow (https://ndncomm2025.named-data.net/program.html), the first talk will be the design of Ownly followed by a handson, and the 2nd session is a panel discussion on what it takes to develop truly decentralized apps.
> >
> > Lixia
> >
> > _______________________________________________
> > Ndn-interest mailing list
> > Ndn-interest at lists.cs.ucla.edu
> > https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

From akdemir at atu.edu.tr  Wed Apr 16 17:18:56 2025
From: akdemir at atu.edu.tr (Alper Kamil Demir)
Date: Thu, 17 Apr 2025 03:18:56 +0300
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <9284117D-0ECE-4779-AE29-F087566F29C8@cs.ucla.edu>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
 <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
 <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>
 <9284117D-0ECE-4779-AE29-F087566F29C8@cs.ucla.edu>
Message-ID: <CAB2GbmpiAR+Mf+hZgT5g6a2CWoq+2prf65HWtTxNpwr7kmprRw@mail.gmail.com>

Lixia Zhang via Ndn-interest <ndn-interest at lists.cs.ucla.edu>, 16 Nis 2025
?ar, 18:00 tarihinde ?unu yazd?:

>
> > On Apr 16, 2025, at 6:04?AM, Kyra <hello at kyra.run> wrote:
> >
> > ......
> >> But it
> >> does, for instance, provide a p2p local-first (while supporting remote
> >> storage/backups with NDN repo) file sync service for a group of users,
> >> and the data can be end-to-end encrypted.
> >
> > Wow, wait?do you mention 'local-first' because you've seen me recently
> share this idea for a local-first e2ee notion-alternative built on Matrix
> (federated graph database synchronization protocol) for collaboration?
> https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391
>
> the above link gave me an error "Idea Not Found"
>

It worked for me.

>
> About the mentioning of 'local-first': that's been a well-known concept
> for some time now.  e.g. at IETF 118 (Nov'23) DIN RG meeting, Martin
> Kleppmann gave a greate talk on "Local-First Software"
> (see https://datatracker.ietf.org/meeting/118/session/dinrg for the talk
> slides and recording)
>
> > That was more of a pipe dream, because I don't think e2ee could be done
> properly with git-annex (or a hypothetical pijul-annex) given using one
> DRCS/DVCS or another as the data/revision store since the whole thing could
> only be encrypted as a blob with a static decryption key, and not for each
> modification in transit between peers with partial or perfect-forward
> secrecy. Maybe down the line someone can work on Matrix on top of NDN.
>
> I dont know Matrix, it sounds like one of the decentralized app efforts.
> AT NDN Community meeting tomorrow (
> https://ndncomm2025.named-data.net/program.html), the first talk will be
> the design of Ownly followed by a handson, and the 2nd session is a panel
> discussion on what it takes to develop truly decentralized apps.
>

Thank you very much for your pointers, my professor..


>
> Lixia
>
Could you give me the link for remote participation. I am also joining a
remote hackathon. Good luck to everyone.
Alper


>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>

-- 
**?Uyar?: Bu e-posta mesaj? ki?iye ?zel olup, gizli
bilgiler i?eriyor 
olabilir. E?er bu e-posta mesaj? size yanl??l?kla ula?m??sa,
i?eri?ini 
hi?bir ?ekilde kullanmay?n?z ve ekli dosyalar? a?may?n?z. Bu durumda
l?tfen 
e-posta mesaj?n? g?nderen kullan?c?ya haber veriniz ve t?m elektronik ve
yaz?l? kopyalar?n? siliniz. Adana Alparslan T?rke? Bilim ve Teknoloji
?niversitesi, bu e-posta mesaj?n?n i?eri?i ile ilgili olarak hi?bir 
hukuksal
sorumlulu?u kabul etmez.?**
**
**
**?Di****sclaimer: T****his 
e-mail message is personal and may contain confidential information. If 
this e-mail message reaches you by mistake, do not use its contents in any 
way and do not open the attached files. In this case, please notify the 
user who sent the e-mail message and delete all electronic and written 
copies. Adana Alparslan T?rke? Science and Technology University does not 
accept any legal responsibility for the content of this e-mail message."**
**
**

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20250417/cb6dfda6/attachment.htm>

From akdemir at atu.edu.tr  Wed Apr 16 17:19:30 2025
From: akdemir at atu.edu.tr (Alper Kamil Demir)
Date: Thu, 17 Apr 2025 03:19:30 +0300
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <CAGEdXQn2mqG_w0Db3ME+2Vzrw-YCpqPoLC6wxeqpSXAoSJtXEQ@mail.gmail.com>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
 <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
 <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>
 <9284117D-0ECE-4779-AE29-F087566F29C8@cs.ucla.edu>
 <CAGEdXQn2mqG_w0Db3ME+2Vzrw-YCpqPoLC6wxeqpSXAoSJtXEQ@mail.gmail.com>
Message-ID: <CAB2GbmqCSgmsDS8v_j0+hmYTtK4-A-KP6=thBVskNkUXF0Eq=A@mail.gmail.com>

+1
The best,
a

Varun Patil via Ndn-interest <ndn-interest at lists.cs.ucla.edu>, 16 Nis 2025
?ar, 20:50 tarihinde ?unu yazd?:

> > As a side note https://github.com/pulsejet/ownly looks amazing. I love
> how it ?hides? NDN from the end-user. Congratulations to the team.
>
> Thank you! Indeed our focus recently has been on end-user usability;
> IMO NDN is now sufficiently mature to develop "real" applications, but
> we need more concrete steps in this direction (kudos to Xinyu for
> getting the effort started).
>
> > Wow, wait?do you mention 'local-first' because you've seen me recently
> share this idea for a local-first e2ee notion-alternative built on Matrix
> (federated graph database synchronization protocol) for collaboration?
>
> Interesting proposal.
>
> 1/ I'm not very familiar with the Matrix protocol but (from vague
> memory) my understanding is that the homeserver has more control power
> than ideal. Granted that it is possible to run your own server, this
> practically never happens as the app scales - inevitably leading back
> to a centralized control point.
>
> 2/ Ownly tries for a different direction - it still needs
> infrastructure but the infrastructure is *untrusted* (e.g. NDN repo -
> just a data store without gatekeeping functions). Note that this is
> still very much a work in progress/research - for instance we still
> (at least partially) rely on the testbed NDNCERT instance for
> bootstrapping user identity.
>
> But the ideal outcome is that users can easily pay for this
> infrastructure from a choice of multiple providers, without these
> providers having any control power whatsoever (and allow
> multi-homing). As a direct analogy, this would be like your ISP - you
> do rely on them and not run your own fibers, but it is always possible
> to switch - and your ISP has no control on what you do.
>
> 3/ I do like the idea of doing this *inside* the browser, but I expect
> this to be a much harder direction to push for. It is likely (much)
> easier to build the application over the web platform, which already
> supports a variety of these use cases - for instance Ownly heavily
> relies on WebAssembly and OPFS for the local-first bits; these
> features have broad browser support.
>
> > That was more of a pipe dream, because I don't think e2ee could be done
> properly with git-annex ...
>
> Generally speaking I expect some trade-offs here. Forward secrecy
> makes sense for point-to-point connections but it gets iffy when we're
> talking about this kind of application. For instance there may be a
> *legitimate* reason to decrypt previously exchanged data now (e.g. a
> new person joining a group that has previously uploaded files). We may
> need a re-definition of what forward secrecy means / is trying to
> achieve in this context.
>
> As for exchanging deltas, this is an application layer requirement.
> Not sure, but I imagine this should technically be possible with any
> kind of diffing algorithm - for Ownly we use Y.js CRDT (though the
> hard problem it solves is automated conflict resolution).
>
> > I'd rather reduce the Home Server to a rendezvous point.
>
> This may be in line with what I was referring to above.
> Note that in NDN, the packet forwarder (e.g. NFD) takes up part of
> this job - a pure network rendezvous point.
>
> > At least with synapse, the state-groups-state-table tends to grow faster
> than Moore drops storage costs, even though some constant factors can be
> trimmed.
> > I have a hunch, that something along the lines of STARKs, SNARGs,
> SNARKS, or whatever flavor of succinct, recursive proof system, can be a
> great fit for ledger systems, but the math is way over my head.
>
> (High level comment) One of the questions is *what* goes onto a
> ledger. NDN arguably still needs a ledger, but only for
> identities/certificates - all other application data is effectively
> and provably connected using name-based relations. The key ideas -
> structured and semantically meaningful naming conventions and rules
> that bind different names together.
>
> > At NDN Community meeting tomorrow (
> https://ndncomm2025.named-data.net/program.html), the first talk will be
> the design of Ownly
>
> I believe the remote registration is still open, if anyone interested
> to join. I'll leave pointer below.
> https://ndncomm2025.named-data.net/registration.html
>
> Best,
> Varun
>
> On Wed, Apr 16, 2025 at 8:00?AM Lixia Zhang via Ndn-interest
> <ndn-interest at lists.cs.ucla.edu> wrote:
> >
> >
> > > On Apr 16, 2025, at 6:04?AM, Kyra <hello at kyra.run> wrote:
> > >
> > > ......
> > >> But it
> > >> does, for instance, provide a p2p local-first (while supporting remote
> > >> storage/backups with NDN repo) file sync service for a group of users,
> > >> and the data can be end-to-end encrypted.
> > >
> > > Wow, wait?do you mention 'local-first' because you've seen me recently
> share this idea for a local-first e2ee notion-alternative built on Matrix
> (federated graph database synchronization protocol) for collaboration?
> https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391
> >
> > the above link gave me an error "Idea Not Found"
> >
> > About the mentioning of 'local-first': that's been a well-known concept
> for some time now.  e.g. at IETF 118 (Nov'23) DIN RG meeting, Martin
> Kleppmann gave a greate talk on "Local-First Software"
> > (see https://datatracker.ietf.org/meeting/118/session/dinrg for the
> talk slides and recording)
> >
> > > That was more of a pipe dream, because I don't think e2ee could be
> done properly with git-annex (or a hypothetical pijul-annex) given using
> one DRCS/DVCS or another as the data/revision store since the whole thing
> could only be encrypted as a blob with a static decryption key, and not for
> each modification in transit between peers with partial or perfect-forward
> secrecy. Maybe down the line someone can work on Matrix on top of NDN.
> >
> > I dont know Matrix, it sounds like one of the decentralized app efforts.
> AT NDN Community meeting tomorrow (
> https://ndncomm2025.named-data.net/program.html), the first talk will be
> the design of Ownly followed by a handson, and the 2nd session is a panel
> discussion on what it takes to develop truly decentralized apps.
> >
> > Lixia
> >
> > _______________________________________________
> > Ndn-interest mailing list
> > Ndn-interest at lists.cs.ucla.edu
> > https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>

-- 
**?Uyar?: Bu e-posta mesaj? ki?iye ?zel olup, gizli
bilgiler i?eriyor 
olabilir. E?er bu e-posta mesaj? size yanl??l?kla ula?m??sa,
i?eri?ini 
hi?bir ?ekilde kullanmay?n?z ve ekli dosyalar? a?may?n?z. Bu durumda
l?tfen 
e-posta mesaj?n? g?nderen kullan?c?ya haber veriniz ve t?m elektronik ve
yaz?l? kopyalar?n? siliniz. Adana Alparslan T?rke? Bilim ve Teknoloji
?niversitesi, bu e-posta mesaj?n?n i?eri?i ile ilgili olarak hi?bir 
hukuksal
sorumlulu?u kabul etmez.?**
**
**
**?Di****sclaimer: T****his 
e-mail message is personal and may contain confidential information. If 
this e-mail message reaches you by mistake, do not use its contents in any 
way and do not open the attached files. In this case, please notify the 
user who sent the e-mail message and delete all electronic and written 
copies. Adana Alparslan T?rke? Science and Technology University does not 
accept any legal responsibility for the content of this e-mail message."**
**
**

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20250417/ce94fc2b/attachment-0001.htm>

From akdemir at atu.edu.tr  Wed Apr 16 17:21:17 2025
From: akdemir at atu.edu.tr (Alper Kamil Demir)
Date: Thu, 17 Apr 2025 03:21:17 +0300
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <CADfzvvbqAPuNSiscWBUX+LLutDS6MBsF91DD0pt=CeJK7MbP_w@mail.gmail.com>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
 <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
 <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>
 <9284117D-0ECE-4779-AE29-F087566F29C8@cs.ucla.edu>
 <CAGEdXQn2mqG_w0Db3ME+2Vzrw-YCpqPoLC6wxeqpSXAoSJtXEQ@mail.gmail.com>
 <CADfzvvbqAPuNSiscWBUX+LLutDS6MBsF91DD0pt=CeJK7MbP_w@mail.gmail.com>
Message-ID: <CAB2Gbmra-VV1X+pLiSJFNycGmPewHMecebq25hQWuK_F5psYmA@mail.gmail.com>

Davide,
I am done with  NDN over Contiki NG. Is it a good idea to win the hackathon
together?
Alper

Davide Pesavento via Ndn-interest <ndn-interest at lists.cs.ucla.edu>, 16 Nis
2025 ?ar, 22:12 tarihinde ?unu yazd?:

> On Wed, Apr 16, 2025 at 1:50?PM Varun Patil via Ndn-interest
> <ndn-interest at lists.cs.ucla.edu> wrote:
> >
> > > As a side note https://github.com/pulsejet/ownly looks amazing. I
> love how it ?hides? NDN from the end-user. Congratulations to the team.
> >
> > Thank you! Indeed our focus recently has been on end-user usability;
> > IMO NDN is now sufficiently mature to develop "real" applications, but
> > we need more concrete steps in this direction (kudos to Xinyu for
> > getting the effort started).
> >
> > > Wow, wait?do you mention 'local-first' because you've seen me recently
> share this idea for a local-first e2ee notion-alternative built on Matrix
> (federated graph database synchronization protocol) for collaboration?
> >
> > Interesting proposal.
> >
> > 1/ I'm not very familiar with the Matrix protocol but (from vague
> > memory) my understanding is that the homeserver has more control power
> > than ideal. Granted that it is possible to run your own server, this
> > practically never happens as the app scales - inevitably leading back
> > to a centralized control point.
> >
> > 2/ Ownly tries for a different direction - it still needs
> > infrastructure but the infrastructure is *untrusted* (e.g. NDN repo -
> > just a data store without gatekeeping functions). Note that this is
> > still very much a work in progress/research - for instance we still
> > (at least partially) rely on the testbed NDNCERT instance for
> > bootstrapping user identity.
> >
> > But the ideal outcome is that users can easily pay for this
> > infrastructure from a choice of multiple providers, without these
> > providers having any control power whatsoever (and allow
> > multi-homing). As a direct analogy, this would be like your ISP - you
> > do rely on them and not run your own fibers, but it is always possible
> > to switch - and your ISP has no control on what you do.
> >
> > 3/ I do like the idea of doing this *inside* the browser, but I expect
> > this to be a much harder direction to push for. It is likely (much)
> > easier to build the application over the web platform, which already
> > supports a variety of these use cases - for instance Ownly heavily
> > relies on WebAssembly and OPFS for the local-first bits; these
> > features have broad browser support.
> >
> > > That was more of a pipe dream, because I don't think e2ee could be
> done properly with git-annex ...
> >
> > Generally speaking I expect some trade-offs here. Forward secrecy
> > makes sense for point-to-point connections but it gets iffy when we're
> > talking about this kind of application. For instance there may be a
> > *legitimate* reason to decrypt previously exchanged data now (e.g. a
> > new person joining a group that has previously uploaded files).
>
> I don't think this has anything to do with the "type" of communication
> (group vs. point-to-point). It is entirely dependent on the use
> case/application. I see forward secrecy as a spectrum rather than a
> binary thing. How frequently you ratchet your state (assuming a
> ratchet-based protocol) determines the "amount" of forward secrecy
> that you get. So if you need to make past communication more readily
> (and efficiently) available, then either ratchet less frequently or
> store more past states. This of course makes a future compromise more
> catastrophic. It's a tradeoff, like many things, but it should be
> driven by the application use case or the specific context in which it
> is being used. In the example of secure (group) messaging, both
> allowing and not allowing new participants to access past history are
> valid use cases.
>
> > We may
> > need a re-definition of what forward secrecy means / is trying to
> > achieve in this context.
> >
> > As for exchanging deltas, this is an application layer requirement.
> > Not sure, but I imagine this should technically be possible with any
> > kind of diffing algorithm - for Ownly we use Y.js CRDT (though the
> > hard problem it solves is automated conflict resolution).
> >
> > > I'd rather reduce the Home Server to a rendezvous point.
> >
> > This may be in line with what I was referring to above.
> > Note that in NDN, the packet forwarder (e.g. NFD) takes up part of
> > this job - a pure network rendezvous point.
> >
> > > At least with synapse, the state-groups-state-table tends to grow
> faster than Moore drops storage costs, even though some constant factors
> can be trimmed.
> > > I have a hunch, that something along the lines of STARKs, SNARGs,
> SNARKS, or whatever flavor of succinct, recursive proof system, can be a
> great fit for ledger systems, but the math is way over my head.
> >
> > (High level comment) One of the questions is *what* goes onto a
> > ledger. NDN arguably still needs a ledger, but only for
> > identities/certificates - all other application data is effectively
> > and provably connected using name-based relations. The key ideas -
> > structured and semantically meaningful naming conventions and rules
> > that bind different names together.
> >
> > > At NDN Community meeting tomorrow (
> https://ndncomm2025.named-data.net/program.html), the first talk will be
> the design of Ownly
> >
> > I believe the remote registration is still open, if anyone interested
> > to join. I'll leave pointer below.
> > https://ndncomm2025.named-data.net/registration.html
> >
> > Best,
> > Varun
> >
> > On Wed, Apr 16, 2025 at 8:00?AM Lixia Zhang via Ndn-interest
> > <ndn-interest at lists.cs.ucla.edu> wrote:
> > >
> > >
> > > > On Apr 16, 2025, at 6:04?AM, Kyra <hello at kyra.run> wrote:
> > > >
> > > > ......
> > > >> But it
> > > >> does, for instance, provide a p2p local-first (while supporting
> remote
> > > >> storage/backups with NDN repo) file sync service for a group of
> users,
> > > >> and the data can be end-to-end encrypted.
> > > >
> > > > Wow, wait?do you mention 'local-first' because you've seen me
> recently share this idea for a local-first e2ee notion-alternative built on
> Matrix (federated graph database synchronization protocol) for
> collaboration?
> https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391
> > >
> > > the above link gave me an error "Idea Not Found"
> > >
> > > About the mentioning of 'local-first': that's been a well-known
> concept for some time now.  e.g. at IETF 118 (Nov'23) DIN RG meeting,
> Martin Kleppmann gave a greate talk on "Local-First Software"
> > > (see https://datatracker.ietf.org/meeting/118/session/dinrg for the
> talk slides and recording)
> > >
> > > > That was more of a pipe dream, because I don't think e2ee could be
> done properly with git-annex (or a hypothetical pijul-annex) given using
> one DRCS/DVCS or another as the data/revision store since the whole thing
> could only be encrypted as a blob with a static decryption key, and not for
> each modification in transit between peers with partial or perfect-forward
> secrecy. Maybe down the line someone can work on Matrix on top of NDN.
> > >
> > > I dont know Matrix, it sounds like one of the decentralized app
> efforts. AT NDN Community meeting tomorrow (
> https://ndncomm2025.named-data.net/program.html), the first talk will be
> the design of Ownly followed by a handson, and the 2nd session is a panel
> discussion on what it takes to develop truly decentralized apps.
> > >
> > > Lixia
> > >
> > > _______________________________________________
> > > Ndn-interest mailing list
> > > Ndn-interest at lists.cs.ucla.edu
> > > https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> > _______________________________________________
> > Ndn-interest mailing list
> > Ndn-interest at lists.cs.ucla.edu
> > https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>

-- 
**?Uyar?: Bu e-posta mesaj? ki?iye ?zel olup, gizli
bilgiler i?eriyor 
olabilir. E?er bu e-posta mesaj? size yanl??l?kla ula?m??sa,
i?eri?ini 
hi?bir ?ekilde kullanmay?n?z ve ekli dosyalar? a?may?n?z. Bu durumda
l?tfen 
e-posta mesaj?n? g?nderen kullan?c?ya haber veriniz ve t?m elektronik ve
yaz?l? kopyalar?n? siliniz. Adana Alparslan T?rke? Bilim ve Teknoloji
?niversitesi, bu e-posta mesaj?n?n i?eri?i ile ilgili olarak hi?bir 
hukuksal
sorumlulu?u kabul etmez.?**
**
**
**?Di****sclaimer: T****his 
e-mail message is personal and may contain confidential information. If 
this e-mail message reaches you by mistake, do not use its contents in any 
way and do not open the attached files. In this case, please notify the 
user who sent the e-mail message and delete all electronic and written 
copies. Adana Alparslan T?rke? Science and Technology University does not 
accept any legal responsibility for the content of this e-mail message."**
**
**

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20250417/ce7450e4/attachment.htm>

From hello at kyra.run  Wed Apr 16 18:56:19 2025
From: hello at kyra.run (Kyra)
Date: Wed, 16 Apr 2025 20:56:19 -0500
Subject: [Ndn-interest] Version-controlled file-syncing/sharing
 (collaboration with git-annex?)
In-Reply-To: <CADfzvvbqAPuNSiscWBUX+LLutDS6MBsF91DD0pt=CeJK7MbP_w@mail.gmail.com>
References: <CAOs69oj7FA2yFAyiy5zfYekEkEQqS8sas2XEtko=v79c0-w3mQ@mail.gmail.com>
 <CAGEdXQnhAevqHfOoJUS+30PML3WgQknTAUrXaD-bBPwTZs9MFw@mail.gmail.com>
 <CAOs69ojGkYGc3MfPN8edyQKfyUgd=pNG_1S17Ws7n1Nw98kq1w@mail.gmail.com>
 <9284117D-0ECE-4779-AE29-F087566F29C8@cs.ucla.edu>
 <CAGEdXQn2mqG_w0Db3ME+2Vzrw-YCpqPoLC6wxeqpSXAoSJtXEQ@mail.gmail.com>
 <CADfzvvbqAPuNSiscWBUX+LLutDS6MBsF91DD0pt=CeJK7MbP_w@mail.gmail.com>
Message-ID: <CAOs69ohsyD2fj-mMQ8gYHEEEagb2ifF1mOJSQRdNBpxAT5bjCQ@mail.gmail.com>

On Wed, Apr 16, 2025 at 2:13?PM Davide Pesavento via Ndn-interest <
ndn-interest at lists.cs.ucla.edu> wrote:

> On Wed, Apr 16, 2025 at 1:50?PM Varun Patil via Ndn-interest
> > 1/ I'm not very familiar with the Matrix protocol but (from vague
> > memory) my understanding is that the homeserver has more control power
> > than ideal. Granted that it is possible to run your own server, this
> > practically never happens as the app scales - inevitably leading back
> > to a centralized control point.
>

Its true, you would have to trust your homeserver or run your own for total
control, although this differs from most basic types of federation like
email because all federated servers mirror the graph of all channels their
users belong to. Your server could meddle with events before they hit the
network, but matrix doesn't fall prey to 51% sybil attacks. It uses a
hash-linked directed acyclic graph (DAG) to ensure byzantine
fault-tolerance against an arbitrary number of bad actors.

There are hopeful performance improvements to be gained, possibly by
implementing random gossiping if security can be preserved for the DAG's
integrity, plus an ongoing effort to work towards multi-homed accounts for
fully peer-to-peer Matrix where the client and the server are one and the
same: https://matrix.org/blog/2020/06/02/introducing-p2p-matrix/

Videos on those here:
* Matrix federation explained
https://fosdem.org/2025/schedule/event/fosdem-2025-5016-demystifying-federation-in-matrix/
alt: https://youtu.be/qeUP-uNKpn4
* P2P Matrix https://archive.fosdem.org/2020/schedule/event/dip_p2p_matrix/
alt: https://youtu.be/nZBKzQzH2NA

> But the ideal outcome is that users can easily pay for this
> > infrastructure from a choice of multiple providers, without these
> > providers having any control power whatsoever (and allow
> > multi-homing).
>

NDN does seem like the ideal backbone, but how would it be possible to
maintain end-to-end encryption between multiple peers/collaborators while
correctly handling history, like conversations or document edits, which are
local-first and so therefore may arrive in different orders?


> > 3/ I do like the idea of doing this *inside* the browser, but I expect
> > this to be a much harder direction to push for. [?] Ownly heavily
> > relies on WebAssembly and OPFS for the local-first bits; these
> > features have broad browser support.
>

You are definitely right?I have no real attachment to baking this into a
browser but I figured it made sense as an appeal to Mozilla. I see Ownly
uses Yjs but this has some limitations for text-formatting that are
addressed by Peritext
https://www.inkandswitch.com/peritext/#adding-control-characters-to-plain-text

> > That was more of a pipe dream, because I don't think e2ee could be done
> properly with git-annex ...
> >
> > Generally speaking I expect some trade-offs here. Forward secrecy
> > makes sense for point-to-point connections but it gets iffy when we're
> > talking about this kind of application. For instance there may be a
> > *legitimate* reason to decrypt previously exchanged data now (e.g. a
> > new person joining a group that has previously uploaded files).
>
> I don't think this has anything to do with the "type" of communication
> (group vs. point-to-point). It is entirely dependent on the use
> case/application. I see forward secrecy as a spectrum rather than a
> binary thing. How frequently you ratchet your state (assuming a
> ratchet-based protocol) determines the "amount" of forward secrecy
> that you get. [?] In the example of secure (group) messaging, both
> allowing and not allowing new participants to access past history are
> valid use cases.
>

Exactly, and having the option to share or not share history is an
expectation most users or at least chat-community admins fully expect to
have. If it isn't possible to handle this with NDN alone, maybe
collaborative documents where history can't be hidden would make sense to
handle natively, while conversations depend on Matrix as an added layer.


> > We may
> > need a re-definition of what forward secrecy means / is trying to
> > achieve in this context.
> >
> > As for exchanging deltas, this is an application layer requirement.
> > Not sure, but I imagine this should technically be possible with any
> > kind of diffing algorithm - for Ownly we use Y.js CRDT (though the
> > hard problem it solves is automated conflict resolution).
> >
> > > I'd rather reduce the Home Server to a rendezvous point.
> >
> > This may be in line with what I was referring to above.
> > Note that in NDN, the packet forwarder (e.g. NFD) takes up part of
> > this job - a pure network rendezvous point.
> >
> > > At least with synapse, the state-groups-state-table tends to grow
> faster than Moore drops storage costs, even though some constant factors
> can be trimmed.
> > > I have a hunch, that something along the lines of STARKs, SNARGs,
> SNARKS, or whatever flavor of succinct, recursive proof system, can be a
> great fit for ledger systems, but the math is way over my head.
> >
> > (High level comment) One of the questions is *what* goes onto a
> > ledger. NDN arguably still needs a ledger, but only for
> > identities/certificates - all other application data is effectively
> > and provably connected using name-based relations. The key ideas -
> > structured and semantically meaningful naming conventions and rules
> > that bind different names together.
> >
> > > At NDN Community meeting tomorrow (
> https://ndncomm2025.named-data.net/program.html), the first talk will be
> the design of Ownly
> >
> > I believe the remote registration is still open, if anyone interested
> > to join. I'll leave pointer below.
> > https://ndncomm2025.named-data.net/registration.html
> >
> > Best,
> > Varun
> >
> > On Wed, Apr 16, 2025 at 8:00?AM Lixia Zhang via Ndn-interest
> > <ndn-interest at lists.cs.ucla.edu> wrote:
> > >
> > >
> > > > On Apr 16, 2025, at 6:04?AM, Kyra <hello at kyra.run> wrote:
> > > >
> > > > ......
> > > >> But it
> > > >> does, for instance, provide a p2p local-first (while supporting
> remote
> > > >> storage/backups with NDN repo) file sync service for a group of
> users,
> > > >> and the data can be end-to-end encrypted.
> > > >
> > > > Wow, wait?do you mention 'local-first' because you've seen me
> recently share this idea for a local-first e2ee notion-alternative built on
> Matrix (federated graph database synchronization protocol) for
> collaboration?
> https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391
> > >
> > > the above link gave me an error "Idea Not Found"
> > >
> > > About the mentioning of 'local-first': that's been a well-known
> concept for some time now.  e.g. at IETF 118 (Nov'23) DIN RG meeting,
> Martin Kleppmann gave a greate talk on "Local-First Software"
> > > (see https://datatracker.ietf.org/meeting/118/session/dinrg for the
> talk slides and recording)
> > >
> > > > That was more of a pipe dream, because I don't think e2ee could be
> done properly with git-annex (or a hypothetical pijul-annex) given using
> one DRCS/DVCS or another as the data/revision store since the whole thing
> could only be encrypted as a blob with a static decryption key, and not for
> each modification in transit between peers with partial or perfect-forward
> secrecy. Maybe down the line someone can work on Matrix on top of NDN.
> > >
> > > I dont know Matrix, it sounds like one of the decentralized app
> efforts. AT NDN Community meeting tomorrow (
> https://ndncomm2025.named-data.net/program.html), the first talk will be
> the design of Ownly followed by a handson, and the 2nd session is a panel
> discussion on what it takes to develop truly decentralized apps.
> > >
> > > Lixia
> > >
> > > _______________________________________________
> > > Ndn-interest mailing list
> > > Ndn-interest at lists.cs.ucla.edu
> > > https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> > _______________________________________________
> > Ndn-interest mailing list
> > Ndn-interest at lists.cs.ucla.edu
> > https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20250416/ac57fe32/attachment-0001.htm>

From hello at kyra.run  Tue Apr 22 17:29:10 2025
From: hello at kyra.run (Kyra)
Date: Tue, 22 Apr 2025 19:29:10 -0500
Subject: [Ndn-interest] Understanding Named Data Networking
Message-ID: <CAOs69og4HoXGufvi6sgp0mN8jQFkMWq3yzHUvb4uZJc2M8Wvgw@mail.gmail.com>

On Mon, Apr 7, 2025 at 2:17?PM Varun Patil via Ndn-interest <
ndn-interest at lists.cs.ucla.edu> wrote:

> From an initial impression, the content delivery strategy of the protocol
reminds me of IPFS CIDs.

A key difference is IPFS CIDs are just hashes of the content, they are
not meaningful in themselves. In NDN, each data object is
*semantically* named. Importantly, the data names are used for
security - to establish trust relations between data and data
producers using well-defined naming rules.


It could be valuable to provide some pages comparing NDN to different
protocols / architectures:

   - IP, of course
   - IPFS, which people have mentioned a few times on this list in the past
   - CCNx (I thought NDN was the successor, but IETF still seems to be
   discussing CCNx on their ICN Research Group discussion list?)

This could be in the form of a table of features, or just a written
explanation.


P.S. Did anyone reply to anything or send messages over the weekend? It
looked like the mailing list server went down



On Sun, Apr 6, 2025 at 7:06?PM Ender Minyard via Ndn-interest
<ndn-interest at lists.cs.ucla.edu> wrote:
>
> Hi,
>
> I came across Named Data Networking in this piece of writing which seemed
to claim that Named Data Networking can address the issue of excessive
energy consumption. From an initial impression, the content delivery
strategy of the protocol reminds me of IPFS CIDs. Is this over-simplified
understanding of Named Data Networking accurate whatsoever?
>
> I did see that there are publications on the website, but I would like to
develop a lay person's understanding of the protocol before getting into
details. I would also like to figure out about other networking protocols
that [are/can be] designed to reduce energy consumption.
>
> I have read the executive summary - if there is another beginner-friendly
resource that you would recommend, please let me know.
>
> Thank you for your time,
> Ender
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20250422/0078285a/attachment.htm>