Re: unsuitable protocols and standards that block innovation

[Sahil]

Hi,

Sorry for the delayed response. I was trying to wrap my head around
this.

On Tue, Mar 12, 2024 at 06:26:09AM +0000, Martin Schanzenbach wrote:
> 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.

Thank you for your reply. I am able to make sense of this now. I
watched a talk that you had given about 3 years ago [1]. That
helped me understand this better.

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

Got it. I'll wait for Christian to share his thoughts on this. In the
meantime, I feel I should first spend some time going through
the documentation and some conference presentations available
online to understand GNUnet's architecture better. Some of the
presentations are a little old now but I think they will still serve as
a good starting point before I begin to tackle projects like this one.

On Tuesday, March 12, 2024 2:44:10 PM IST carlo von lynX wrote:
> [...]
> 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.

Understood. Thank you for the explanation.

> A XEP from 2018 that I haven't been following. Let me have a look:
> [...]
> 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.

I'll have to read up on "Multicast DNS", "IP multicast" and their history
to understand this better. 

> [...]
> Since most of XMPP is designed as a client-server-protocol, you
> are actually in a territory doing something new.

Sorry, I haven't really understood this. By "something new" are you
referring to the implementation of this XEP using the GNUnet Name
System instead of DNS? I am not entirely clear on this.

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

This is a little difficult for me to grasp. My lack of familiarity with
this and GNUnet is only adding to the difficulty. I should definitely
dive deeper into these topics before asking more questions. I hope
much of my confusion will fade away once I familiarize myself with
the topics dicussed previously in this thread.

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

Right. Martin also touched on the usefulness of having communicators for
bluetooth and wifi. That's something that I can take a look at as well.

But first, my next course of action should be to familiarize myself with
GNUnet and the topics discussed so far. I'll do some more research on
XMPP and the XEP discussed above. If I have any more questions after
that, I'll definitely post them here.

I have already learnt a great deal from these discussions. I really appreciate
it and I am ready to dive deeper. :)

On Thursday, March 14, 2024 8:46:57 AM IST you wrote:
> [...]
> I wanted to add some backstory that, in my perception, the people here who
> designed GNU Social had previously spent many years defending key user
> rights that were blatantly excluded from mainstream federated protocols,
> and failed to successfully negotiate that they be included, repeatedly for
> a long time.
> 
> GNU Social then arose as a solution that did defend these disregarded
> things.
> 
> My guess would be that some of the sticking points could simply relate to
> this old and frustrating battle, that new people may not have been exposed
> to or understand. For example, many see federation and interoperability as
> a hands-down good thing. But I expect that this crowd might want some
> concerns fully included to consider it at this point.

Got it. Thank you for your insights.

Thanks,
Sahil

[1] https://www.youtube.com/watch?v=qZYI-3Q1INI
      (Talk on GNUnet at FOSDEM, 2020)