Re: Planning to continue working on Secushare

[carlo von lynX]

Tobias, so happy to hear that your hands-on on the matter! Everything
t3sserakt warns about is unfortunately true - after all the effort put
into those subsystems we don't know if they have a chance of delivering
what we need at any happy point in the future. Some additional thoughts
on what t3sserakt generously wrote down despite his current workload:

On Thu, Sep 23, 2021 at 07:05:57AM +0000, t3sserakt wrote:
> There was some critic about the psyc layer I can not remember correctly. 
> Something about not really being a psyc parser to use the potential of a 
> extensible text based protocol.

If I remember well, the 'multicast' code is supposed to be the place to
put multicast logic in, but it doesn't actually do so. The 'psyc' subsystem
implements some lower level routing logic of PSYC, so it is missing most
of what PSYC is otherwise about. The 'social' layer implements some of the
higher level abstractions of PSYC. Another piece of code hasn't been
integrated into the melange: 'libpsyc' implements the extensible text
parsing and rendering, but none of the semantics. All of this put together
might work out, but we know that there are holes in the implementation -
things that are simply missing. And bugs and and...

> Maybe it is not necessary for your application code to interface with 
> the social layer but with the/a psyc layer/parser.

I haven't looked at the messenger code yet, but I presume it's a server-based
round robin tool. This will not fulfil neither the privacy nor scalability
expectations of secushare, but it's more likely to be a backend that at
least starts doing its job and be replaced with more ideal code at a later
time. Simply hooking libpsyc on top of messenger should allow you to send
PSYC-encoded messages around, allowing you to use any other programming
language to actually implement semantics of any kind - which is usually a
lot easier to do than in C and is probably a bad idea to even try.

Another unresolved aspect of secushare software design is the question
whether it makes sense to feed all social data into a graph database
rather than use language-internal data structures. A properly chosen and
employed graph database might turn typical social network operations a
lot easier to implement than with a traditional imperative approach.
Having this upper layer of social modeling resolved would be very useful
even if operating on top of an interim transmission subsystem such as
gnunet-messenger.


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