Re: Planning to continue working on Secushare

[TheJackiMonster]

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.

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.

On Thu, 2021-09-23 at 09:41 +0200, carlo von lynX wrote:
> 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.
> 
>

signature.asc
Description: This is a digitally signed message part