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

[Davide Pesavento]

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