Re: unsuitable protocols and standards that block innovation

[carlo von lynX]

On Thu, Mar 14, 2024 at 01:26:18PM +0530, Sahil wrote:
> Sorry for the delayed response. I was trying to wrap my head around
> this.

That's the most noble thing to say and all the reason why
asynchronous messaging was invented in the first place.   :)

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

A lot about GNUnet and related projects hasn't changed dramatically
in the past fifteen years. We had our vision laid out even before
Snowden and suddenly became relevant, so there are many worthwhile
videos from around that time. Here's some stuff:

    
https://media.ccc.de/v/34c3-ChaosWest-6-privacy_oriented_distributed_networking_for_an_ethical_internet_including_50_subsystems_of_gnunet
    
https://media.ccc.de/v/34c3-ChaosWest-7-scalable_and_privacy_respectful_distributed_systems_our_chance_to_avoid_cloud_computing
    
https://media.ccc.de/v/34c3-ChaosWest-1-three_ways_to_enhance_metadata_protection_beyond_tor_secushare_org
 
    https://youtu.be/H7TVRYN6Vhk

The one on scalability discusses multicast technologies. I had a
business doing scalable chat systems before Zuckerberg used ruthless
methods to gain market dominance.

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

No, I was thinking of things such as chatrooms and broadcast
channels. How do you implement those if you don't have a server
in your toolset? secushare contains much thoughtwork on how to
do these things while reducing dependencies on certain servers
to stay up. If you use this XEP to connect two clients to each
other, what can they do? Just send stickers at each other? It's
a bit meager an earning.

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

Have a look, it's especially dramatic when embedding binary data:
https://psyc.eu/libpsyc/bench/benchmark.html#sec-3

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

Not sure how well existing libraries abstract involved headaches away.
When it comes to dealing with radio and its protocol implementations
you might find yourself spending a lot of time dealing with glitches
and things that should be working according to the docs, but don't.
But once it works it is obviously very useful to have. The way any
GNUnet node should be able to work with any other should at least
avoid the whole pairing business. Ideally simply flicking bluetooth or
wifi on should allow your locally running GNUnet node to exchange
traffic with other nodes in the vicinity, in theory.

On Thu, Mar 14, 2024 at 10:12:20AM +0200, MSavoritias wrote:
> To add to this, XMPP is designed to be extensible so adding a GNS XEP (These
> are standard extensions of XMPP) is not a big problem. Like websockets, p2p,
> quic, or jingle (which is where webrtc came from and is native to XMPP for
> multimedia streams) also did before.

For completeness I should mention that I was involved with the
implementation of one of the first Jingle/WebRTC libraries
together with my former employee Philipp Hancke.

> And outside of that xmpp gives you many benefits even if you dont use DNS or
> servers. Mainly because you are going to encounter problems that have
> already been solved by XMPP. Like:
> 
> - How do I deliver offline messages

It expects that an XMPP server exists and will not go down
or become unreachable randomly. In GNUnet/secushare we
intend to use distributed storages and strategies for that,
so that chatrooms and mailboxes exist in a "cloud" of
distributed nodes, not in a replicated database on corporate
servers.

> - How do I share sticker packs
> 
> - How do I make calls and do multimedia stream negotiation
> 
> - How do I do group chats

Again, same server storage problem. So if you consider that
all the server-based functionality isn't working, what's
staying is the 1:1 stuff. Is it worth all the disadvantages?

> among others.
> 
> What I would probably be looking to implement something with XMPP and Gnunet
> (and I am already looking in) is using Spritely to actually handle the the
> security and distributed nature of things. Stuff like capabilities, message
> passing and network backends (which gnunet can be implemented as).
> 
> Spritely as in: https://spritely.institute/

If this stuff actually works and solves some problems, this could be
a useful thing to bring to GNUnet. It's not the first of its kind
and the usefulness of actual mobile code rather than shared
specifications isn't endless, but for some purposes it may work out.

First time I heard of such an approach was in 1990. BuGless suggested
we should have a mobile programming language for chatroom conference
control so that the way the chatroom works can travel across the
network in form of a programm rather than a specification. The idea
was radical and fascinating, but having protocols and configurations
always ended up being good enough or better for all purposes.

Also reminds me of Ethereum's idea of doing DAOs, a method to me best
known for its bugs: a DAO hardly ever does what the original author
intended it to do. In real life the author remains legally responsible
and can fix the bugs, in Ethereum anyone who invested in the DAO now
has to deal with whichever consequences.

So 34 years later I'm still excited to see if such an approach will
lead somewhere...