<html><head></head><body><div dir="ltr"><div dir="ltr"><br/></div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Apr 16, 2025 at 2:13 PM Davide Pesavento via Ndn-interest <<a href="mailto:ndn-interest@lists.cs.ucla.edu">ndn-interest@lists.cs.ucla.edu</a>> wrote:<br/></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Apr 16, 2025 at 1:50 PM Varun Patil via Ndn-interest<br/>
> 1/ I'm not very familiar with the Matrix protocol but (from vague<br/>
> memory) my understanding is that the homeserver has more control power<br/>
> than ideal. Granted that it is possible to run your own server, this<br/>
> practically never happens as the app scales - inevitably leading back<br/>
> to a centralized control point.<br/></blockquote><div><div><br/></div><div>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. </div><div><br/></div><div>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: <a href="https://matrix.org/blog/2020/06/02/introducing-p2p-matrix/" target="_blank">https://matrix.org/blog/2020/06/02/introducing-p2p-matrix/</a></div><br/><div>Videos on those here: <br/>* Matrix federation explained <a href="https://fosdem.org/2025/schedule/event/fosdem-2025-5016-demystifying-federation-in-matrix/" target="_blank">https://fosdem.org/2025/schedule/event/fosdem-2025-5016-demystifying-federation-in-matrix/</a> alt: <a href="https://youtu.be/qeUP-uNKpn4" target="_blank">https://youtu.be/qeUP-uNKpn4</a></div><div>* P2P Matrix <a href="https://archive.fosdem.org/2020/schedule/event/dip_p2p_matrix/" target="_blank">https://archive.fosdem.org/2020/schedule/event/dip_p2p_matrix/</a> alt: <a href="https://youtu.be/nZBKzQzH2NA" target="_blank">https://youtu.be/nZBKzQzH2NA</a></div></div><div><br/></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> But the ideal outcome is that users can easily pay for this<br/>
> infrastructure from a choice of multiple providers, without these<br/>
> providers having any control power whatsoever (and allow<br/>
> multi-homing). <br/></blockquote><div><br/></div><div>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? <br/></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 3/ I do like the idea of doing this *inside* the browser, but I expect<br/>
> this to be a much harder direction to push for. […] Ownly heavily<br/>
> relies on WebAssembly and OPFS for the local-first bits; these<br/>
> features have broad browser support.<br/></blockquote><div><br/></div><div>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 <a href="https://www.inkandswitch.com/peritext/#adding-control-characters-to-plain-text">https://www.inkandswitch.com/peritext/#adding-control-characters-to-plain-text</a></div><div><br/></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > That was more of a pipe dream, because I don't think e2ee could be done properly with git-annex ...<br/>
><br/>
> Generally speaking I expect some trade-offs here. Forward secrecy<br/>
> makes sense for point-to-point connections but it gets iffy when we're<br/>
> talking about this kind of application. For instance there may be a<br/>
> *legitimate* reason to decrypt previously exchanged data now (e.g. a<br/>
> new person joining a group that has previously uploaded files).<br/>
<br/>
I don't think this has anything to do with the "type" of communication<br/>
(group vs. point-to-point). It is entirely dependent on the use<br/>
case/application. I see forward secrecy as a spectrum rather than a<br/>
binary thing. How frequently you ratchet your state (assuming a<br/>
ratchet-based protocol) determines the "amount" of forward secrecy<br/>
that you get. […] In the example of secure (group) messaging, both<br/>
allowing and not allowing new participants to access past history are<br/>
valid use cases.<br/></blockquote><div><br/></div><div>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. <br/></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> We may<br/>
> need a re-definition of what forward secrecy means / is trying to<br/>
> achieve in this context.<br/>
><br/>
> As for exchanging deltas, this is an application layer requirement.<br/>
> Not sure, but I imagine this should technically be possible with any<br/>
> kind of diffing algorithm - for Ownly we use Y.js CRDT (though the<br/>
> hard problem it solves is automated conflict resolution).<br/>
><br/>
> > I'd rather reduce the Home Server to a rendezvous point.<br/>
><br/>
> This may be in line with what I was referring to above.<br/>
> Note that in NDN, the packet forwarder (e.g. NFD) takes up part of<br/>
> this job - a pure network rendezvous point.<br/>
><br/>
> > 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.<br/>
> > 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.<br/>
><br/>
> (High level comment) One of the questions is *what* goes onto a<br/>
> ledger. NDN arguably still needs a ledger, but only for<br/>
> identities/certificates - all other application data is effectively<br/>
> and provably connected using name-based relations. The key ideas -<br/>
> structured and semantically meaningful naming conventions and rules<br/>
> that bind different names together.<br/>
><br/>
> > At NDN Community meeting tomorrow (<a href="https://ndncomm2025.named-data.net/program.html" rel="noreferrer" target="_blank">https://ndncomm2025.named-data.net/program.html</a>), the first talk will be the design of Ownly<br/>
><br/>
> I believe the remote registration is still open, if anyone interested<br/>
> to join. I'll leave pointer below.<br/>
> <a href="https://ndncomm2025.named-data.net/registration.html" rel="noreferrer" target="_blank">https://ndncomm2025.named-data.net/registration.html</a><br/>
><br/>
> Best,<br/>
> Varun<br/>
><br/>
> On Wed, Apr 16, 2025 at 8:00 AM Lixia Zhang via Ndn-interest<br/>
> <<a href="mailto:ndn-interest@lists.cs.ucla.edu" target="_blank">ndn-interest@lists.cs.ucla.edu</a>> wrote:<br/>
> ><br/>
> ><div id="lark-mail-quote-df1d754fec7916e7c0162d8bb9e7e4b4"><br/>
> > > On Apr 16, 2025, at 6:04 AM, Kyra <hello@kyra.run> wrote:<br/>
> > ><br/>
> > > ......<br/>
> > >> But it<br/>
> > >> does, for instance, provide a p2p local-first (while supporting remote<br/>
> > >> storage/backups with NDN repo) file sync service for a group of users,<br/>
> > >> and the data can be end-to-end encrypted.<br/>
> > ><br/>
> > > 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? <a href="https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391" rel="noreferrer" target="_blank">https://connect.mozilla.org/t5/ideas/concept-mapping-graph-view-of-tabs-bookmarks-amp-notes/idi-p/37391</a><br/>
> ><br/>
> > the above link gave me an error "Idea Not Found"<br/>
> ><br/>
> > 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"<br/>
> > (see <a href="https://datatracker.ietf.org/meeting/118/session/dinrg" rel="noreferrer" target="_blank">https://datatracker.ietf.org/meeting/118/session/dinrg</a> for the talk slides and recording)<br/>
> ><br/>
> > > 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.<br/>
> ><br/>
> > I dont know Matrix, it sounds like one of the decentralized app efforts. AT NDN Community meeting tomorrow (<a href="https://ndncomm2025.named-data.net/program.html" rel="noreferrer" target="_blank">https://ndncomm2025.named-data.net/program.html</a>), 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.<br/>
> ><br/>
> > Lixia<br/>
> ><br/>
> > _______________________________________________<br/>
> > Ndn-interest mailing list<br/>
> > <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br/>
> > <a href="https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br/>
> _______________________________________________<br/>
> Ndn-interest mailing list<br/>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br/>
> <a href="https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br/>
_______________________________________________<br/>
Ndn-interest mailing list<br/>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br/>
<a href="https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">https://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br/>
</div></blockquote></div></div></body></html>