Re: unsuitable protocols and standards that block innovation

On 3/15/24 13:34, carlo von lynX wrote:

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

Not really it doesn't. Delivering offline messages doesn't require 
servers from XMPP or servers in the first place.

To expand:

- XMPP uses the XEP 0313 which is basically a protocol to retrieve 
messages. Where these messages stored is left as an exercise to the 
reader although most people use servers including secushare it seems 
which made my interest in the project less :/

- Now how to deliver messages while the sender or recipient is offline 
have been solved already by i2pbote or bitmessage. Without requiring 
servers or nodes. Couple that with a network of consent and you can have 
your social circle/contacts to keep messages for you until they are 
delivered to their intended recipient.

Also stuff like ERIS which partitions the message and sends it so that 
one can person can have the whole message is an additional help here.

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

MIX or MUC don't have to be in a server. If you read the XEPs basically 
all they require you to do is put an identifier and have the group chat 
somewhere. that can be anywhere.

And with MIX it becomes even easier since its basically a PubSub node. 
If the group chat node goes online you can solve it multiple ways:

- Have federated rooms. Which already exists for MUC and MIX was built 
with the intention to have federated rooms. <- This is what i intend to 
do with rooms being a DID identifier probably

- Easy migration to new rooms. <- This doesnt solve it completely but it 
is a nice to have also.

>> 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...
>
Spritely is involved in the standardization of Ocaps together with some 
other projects.

One of the problems I am looking to solve with it is basically networks 
of consent. Every request having object capabilities and needed 
authorization first before reaching another person.

To basically eliminate the spam waves we have in the current network due 
to it being permission less and making spam really easy to happen.


MSavoritias