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/
