Replies: 2 comments
-
All is difficult to quantify. * Peer to peer discussionsAlready easy-peasy. * Basic chatOutside of a purpose built program (which would be much better from a holistic standpoint, but much more costly in development) this can be done now with Distribution Groups, but would be insecure (the data would be stored unencrypted on the server) and data intensive (there is no multicast, so for N users, each packet would be sent at least N times) so that really depends on needs. It's as secure as most services, but perhaps not worth the pain of migration. * AttachmentsTo the best of my knowledge there exists no way to do an attachment-style system without physically attaching a file to an LXM. As you can imagine, this is a problem as you'd be sending every file to every person every time. So the key would be to send an rns Resource, where interested parties can load the resource as they wanted it. This not only reduces theoretical load, but also reduces peak load, as not everyone would be receiving the file at once. * ConsensusUntil this is a superior way to do things and the majority of people are willing to convert over, it won't happen. This means that it needs to be accessible and feature complete for every need of the community. I don't think threads are essential, others may disagree. Do we need channels, mods, permissions, etc? Each of those is a major amount of work, so knowing what the community does and doesn't need is a big factor. General needsWhile basic insecure discussions can take place at this time, there's no central way to achieve everything we need with current utilities. For efficiency and security, group destinations are required, and a program designed to fulfill the rest of the needs is also required. Now, it's possible to set up a message board style system with somewhat little back-end work, but the server itself would still need to be trusted and sending new-message notifications to everyone would still be very lossy. The simplest solution to all given problems is to develop an untrusted server architecture that would blindly forward symmetrically encrypted messages to custom clients that supported resource links and the like, but this doesn't solve the data usage problem, and still requires a full client to be written. It also isn't any more secure than a single node is secure and trustworthy. Now, it's not the best, but I think we're a lot of work from having the "best" solution to this particular need. |
Beta Was this translation helpful? Give feedback.
-
If you want to talk about Reticulum on Reticulum, the Beleth Distribution Group (lxmf@3cbd8b7bb7e3e78e3ea1ef6533cbc0f8) works pretty well, and you can also ask on the nomadForum public beta which is semi-active (it announces regularly, check your announce list). |
Beta Was this translation helpful? Give feedback.
-
Especially now that we have MeshChat, could we host all discussion of Reticulum on Reticulum itself?
What would be needed for that?
Beta Was this translation helpful? Give feedback.
All reactions