Re: unsuitable protocols and standards that block innovation

[Martin Schanzenbach]

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 email@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