On Tue, 2024-03-12 at 02:37 +0530, Sahil wrote: > Hi, > > Thank you for all your emails. I thought I would do some homework > before replying but I don't have much to contribute to this thread. > This > discussion has been quite overwhelming, and I have got a lot to > learn. > > On Friday, March 8, 2024 12:39:31 AM IST carlo von lynX wrote: > > [...] > > In GNUnet people can connect and communicate directly > > with each other, so the whole architecture of servers and > > federation no longer makes a lot of sense. > > I have understood this part. I read through the linked article as > well. I'll > have to re-read that and peruse more documentation before I can fully > understand the points covered in the thread. > > On Saturday, March 9, 2024 2:00:07 PM IST em...@msavoritias.me wrote: > > [...] > > XMPP can work fine through p2p. > > I am under the impression that XMPP can be used in p2p networks and > to establish p2p sessions via extensions such as XEP-0174 [1]. > > > Its just not being done a lot because of other reasons i can expand > > if > > needed. > > I would like to know more. Are there reasons apart from the ones > already > discussed (such as the usage of XML) which make XMPP's adoption in > the > p2p setting less than ideal, even if it works theoretically? > > On Monday, March 11, 2024 9:49:06 PM IST carlo von lynX wrote: > > [...] > > Having the GNUnet stack in a single process is on the todo list for > > GSoC. > > A Telegram-adapter would be yet another GNUnet service out of many. > > As long as it is localhost, the whole architecture is still P2P. > > [...] > > I would guess Telegram clients to be a lot more straightforward > > than > > XMPP ones, as they don't use DNS at all (they just connect to the > > cloud). > > So this point of critique applies to XMPP software much more than > > to a > > Telegram client. > > Adapting a telegram implementation would make for an interesting > project. > Assuming that this is a nice-to-have GNUnet service, I am not sure if > this is > an appropriate project to begin with as someone who is fairly new to > these > topics. > > > [...] > > A multicast routing layer has been in the plans for GNUnet since > > before > > we first came asking, which was around 2009. Research has been made > > on how to do this, but there is no implementation as yet. > > This looks very interesting. "Multicast distribution trees" is a new > topic for > me. I'll read up on this too. > > On Monday, March 11, 2024 10:03:40 PM IST Martin Schanzenbach wrote: > > Note that a large variety of standard transport protocols that > > gnunet > > runs over is what we need, not (only) the most efficient and newest > > protocol that can transport our payload. > > [...] > > So IF XMPP is widely used and adopted, and is reasonably > > performant, it > > IS a prime candidate for a gnunet transport. > > I noticed that reimplementing the SMTP transport plugin is part of > the > roadmap and it is unassigned at the moment [2]. Can I work on this > project > instead? It seems to be more beginner-friendly. It might also help > lay the > foundation to tackle projects/tasks that seem more complex. > > > Eventually, peers may want to "hide" inside HTTPS, DNS, Bluetooth, > > WiFi > > etc, ideally with traffic that looks like those protocols. > > Sorry, I haven't really understood this. By "hiding", do you mean > disguising > traffic?
Yes. The transports are not meant to provide p2p functionality. That is why it does not matter if XMPP is client-server based or not. HTTP is also client/server, but it can be used as a transport between two peers (one acting as a client, the other as the server). Transports (apart from general connectivity) serve a couple of goals, including: - resilience to network outages: e.g. Internet is down, Mesh Wifi still available). This is why "mesh"/ad hoc communicators via Bluetooth/AdHoc Wifi etc are also of particular interest. Peers are expected to run multiple transports at the same time. - Hiding in "common" Internet traffic: e.g. if two peers communicate via HTTPS (and assuming we can obfuscate the traffic patterns of the applications in GNUnet), they look like browser/web server to an attacker that may want to censor p2p traffic. The same holds for protocols such as SMTP* and XMPP. Some protocols (such as SMTP or XMPP) may come with significant overhead, but that is the price to pay to obfuscate the traffic. *To be honest I am not sure how "useful" plain SMTP actually is, considering it is commonly run on top of a TLS connection anyway. I think anything running on top of TLS is sufficiently covered with an HTTPS or QUIC connector. Christian (who filed #1923) may have more insights on this. BR > > Thanks, > Sahil > > [1] https://xmpp.org/extensions/xep-0174.html > [2] https://bugs.gnunet.org/view.php?id=1923 > >
signature.asc
Description: This is a digitally signed message part
