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

[Varun Patil]

> 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