Re: unsuitable protocols and standards that block innovation

[MSavoritias]

On 3/15/24 15:00, carlo von lynX wrote:

> On Fri, Mar 15, 2024 at 02:32:51PM +0200, MSavoritias wrote:
> > - 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 :/
> secushare doesn't have servers in a traditional sense.
> Are you confusing with psyced from 1997?
By servers I mean a separate machine that is used to run services non 
graphically that usually needs to be always online.

For example IRC bouncer in a raspberry pi is a server and a data center 
(cloud whatever) is a server, a NAS is a server, same with serving HTTP 
sites or a blockchain. or BitTorrent seeding 24/7

what is not a server:

anything that runs some of the time in a machine that is already used by 
a person for other stuff graphically.

for example:

running services on my laptop/desktop/phone that I am already using for 
web browsing or chatting is not a server.

for example hosting your HTTP site there which sometimes goes offline 
because the machine is off :D or BitTorrent seeding sometimes because 
its not always on.

> > - 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.
> And secushare is intended to have data structures that allow for such
> things to be implemented generically: You set-up a multicast channel with
> people from your social network as subscribers, but only the intended
> recipient is invited and capable to decrypt the messages left for them.
> That social network may involve "server" nodes, that is, nodes that run
> on behalf of their owner on a permanent node. They will end up doing
> server-like jobs without requiring a different protocol or implementation
> than any other participant, and several of them provide redundancy and
> scalability in the case of one-to-many channels.

And that's where we disagree yeah.

Requiring separate machines to be bought and maintained, that will 
always deliver stuff is a non starter. for accessibility, for equality, 
for autonomy and the environment.

I see how it may be beneficial for some abstract "efficiency" scale i 
just don't think the tradeoffs are worth it.

> > 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.
> You can additionally split messages in parts or apply serious strategies
> of obfuscation, if you don't want the social network to observe who is
> leaving messages to whom. There are cryptographic means to guarantee that
> a communication is happening between people in your trusted social
> network without you being able to know which precise people are involved,
> thus we get privacy while at the same time being spam/abuse-resistant.

Actually I was thinking not only that. By splitting it you also don't 
need to get everything from one person. same with BitTorrent. so 
bandwidth is distributed.

In case of disruptions, power loss, high pings, etc.

> > 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.
> So you still have plenty of work to do. Why use an old, inefficient and
> innovation-blocking so-called "standard" when it was a wrong choice
> even back in 1999 when it got declared a standard?

I feel like your subjective feelings get in the way here.

Personally its simple I don't want to reinvent everything. Also our 
goals are radically different as I have mentioned.

I don't want scale or servers/nodes.

> > - 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
> Federation has failed us big time and it is all the reason why GNUnet exists.
By federation i mean that the room is hosted by all participants. We can 
call it distributed too.
> > 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.
> Well, that's what the social graph is good for. Secushare would like to
> have a distributed social graph, not completely transparent, but such
> that you can tell if a communication going through your node is coming
> from a trustworthy source, even if you don't know exactly who it is.
>
> Spammers then don't have much of a chance because they all come in from
> one single person in the social network which can be pointed out as the
> spam origin and eliminated.
>
> I don't see a need for digging into detailed caps for this if the general
> principle works, but I may be misjudging this.
In your example the spammer can contact other people right? That's a 
fundamental failure of the current internet architecture.

Any future architectures should make sure that the spam message doesn't 
even reach the recipient to begin with.


MSavoritias