Re: Planning to continue working on Secushare

[carlo von lynX]

On Thu, Sep 23, 2021 at 10:29:02AM +0200, TheJackiMonster wrote:
> Because the messenger service was mentioned I thought I could try to
> clarify. I'm unsure if it's the proper back-end for secushare but
> technically speaking you can just think of it as layer on top of CADET
> to form groups using a shared secret without necessary centralization.
> 
> The latency and stability is not really optimized yet. The groups are
> still using a circular topology to exchange messages. But there
> shouldn't be huge bugs currently. Privacy should also not be a problem
> with this service if you were using CADET previously. I've designed as
> much as possible to be opt-in or optional like identity names, egos and
> hosting.

Wow, alright, I confused this with the chat client-server tool that my
dear colleagues of secushare had prototyped.

The circular topology of end points *does* satisfy the secushare
expectations on privacy and metadata privacy in particular AFAICT,
so that's very cool.

Also, it partially satisfies the wish for scalability in the sense
that Twitter or Netflix use case still aren't feasible, but the much
needed use case of having billions of small private chatrooms should
actually work out this way. That's suuuuper cool.

The social networking model of secushare would at best want to use
hundreds of such small groups per person - each time a certain social
action has a certain expected list of recipients rather than another.

secushare was conceived to achieve this with hundreds of multicast
distribution trees layered on top of gnunet, as they would also
satisfy those large participant use cases like a thousand people
watching a video stream - but for more social use cases a ring
topology might actually be fully sufficient.

Open issues remain whether depending on the latency of each and
every member in a group can render the UX impracticable or if it
actually works most of the time - also if nodes dropping out can
quickly be replaced, allowing for rings to heal. And the cost it
has to set up new groups, considering that for optimal routing
we would want many of them. This is worth researching and somewhat 
similar to the issues when dealing with multicast trees, just simpler.

> So it's not really server-based because every member of a group can
> opt-in to host. However peer-id and port have to be exchanged
> externally. That's pretty much the reason I'm working on the chat
> library to provide a simple API for messaging applications abstracting
> the last pieces of networking.
> 
> If PSYC will be used it would probably make sense adding a new kind of
> message to the messenger service for it. So you could use the service
> parsing those messages only. Also other applications could easily drop
> those as well.

Sounds like you're absolutely heading in the right direction
and if Tobias comes up with a social networking GUI that makes
use of your infrastructure you guys may be heading for a
terrific killer app for GNUnet.


-- 
  E-mail is public! Talk to me in private using encryption:
   //  http://loupsycedyglgamf.onion/LynX/
  //    irc://loupsycedyglgamf.onion:67/lynX
 //    https://psyced.org/LynX/