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? > - 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. > 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. > 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? > 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: Of course all channels and chatrooms are derived from a generic multicast pubsub structure. That's how it should have been in any reasonable protocol. Oh wait, XMPP only started doing this quite recently, and it still doesn't know how to multicast at all. > - 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. > - Easy migration to new rooms. <- This doesnt solve it completely but it is > a nice to have also. > 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.
