Re: unsuitable protocols and standards that block innovation

[Sahil]

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?

Thanks,
Sahil

[1] https://xmpp.org/extensions/xep-0174.html
[2] https://bugs.gnunet.org/view.php?id=1923