Re: unsuitable protocols and standards that block innovation

[carlo von lynX]

Hi Sahil,

On Tue, Mar 12, 2024 at 02:37:36AM +0530, Sahil wrote:
> This looks very interesting. "Multicast distribution trees" is a new topic for
> me. I'll read up on this too.

It's the way how cloud technologies achieve scalability, and it is
the biggest failure of the free world that it let free implementations
slowly die out and surrender to corporate clouds. Back in the 90s we
had NNTP and IRC. In the 2000s we had Bittorrent. All these free and
open multicast implementations have lost traction and everything that
needs to reach many human beings is forced to go through corporate
clouds.

> 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].

A XEP from 2018 that I haven't been following. Let me have a look:

    "This specification defines how to communicate over local or wide-area 
networks using the principles of zero-configuration networking for endpoint 
discovery and the syntax of XML streams and XMPP messaging for real-time 
communication. This method uses DNS-based Service Discovery and Multicast DNS 
to discover entities that support the protocol, including their IP addresses 
and preferred ports."

    "Serverless messaging is typically restricted to a local network (or ad-hoc 
wide-area network) because of how zero-configuration networking works. It is 
impossible for clients that communicate via this serverless mode to insert 
messages into an XMPP network, which is why this kind of "mesh" is most 
accurately referred to as an XMPP-like system that exists outside the context 
of existing XMPP networks (though see the Security Considerations regarding the 
ability to "forward" messages from a serverless mesh to an XMPP network or 
vice-versa)."

So this is for smarthome appliances to find each other on a local
network and for XMPP clients interacting with people in the same LAN
using something which is very inappropriately called "Multicast DNS"
for historic reasons. It has NOTHING to do with Multicast. It's just
using a protocol called "IP Multicast" which was supposed to become
the worldwide standard for creating distribution trees in a cleaner
and more efficient way than IRC and NNTP were doing at the time, but
failed to achieve its goal, so LAN broadcasts have remained as the
only use case, which is far from what it was intended for. This
historic failure has tainted the understanding of the word "multicast"
as the majority of technology people only know it by this failed
meaning, not for what it originally stood for.

So, if you ignore the use of DNS in this XEP and have GNUnet-based
discovery instead, then you could indeed start throwing XMPP stanzas
at each other:

    "Any two entities can then negotiate a serverless connection using XML 
streams in order to exchange XMPP message and IQ stanzas."

Since most of XMPP is designed as a client-server-protocol, you
are actually in a territory doing something new. I mean, do XMPP
message and IQ stanzas really provide a lot more than what bare
XML would do? Also, isn't the industry standard in this field
called JSON, which also has its defects, as shown in the PSYC
benchmark, but it's less bad than XML?

It makes sense to implement this XEP if you're already a XMPP
client developer, not if you're wondering whether to use XMPP
at all. De facto the majority of people will continue using
Whatsapp and such, even if they're in the same LAN.

Within GNUnet instead, you can't just do worldwide broadcasts
using "Multicast DNS", but GNS should be able to do a similar
job as the one described in the XEP, indeed.

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

Probably a biggish one to start with. Not sure how easy it is to switch
off all the extra features the client expects from the server, and reduce
it to start off with the bare minimum - text-based interaction. The
Telegram protocol should be providing some kind of feature negotiation
as it can handle text-based minimal clients.

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

This should be an easy task indeed. But as Martin points out, it might
not be "useful" anymore.