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

Wed Apr 16 17:19:30 PDT 2025

+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>