[Ndn-interest] Version-controlled file-syncing/sharing (collaboration with git-annex?)

Wed Apr 16 18:56:19 PDT 2025

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>