Re: Semantics of GNUNET_PSYC_OP_AUGMENT, GNUNET_PSYC_OP_DIMINISH, and GNUNET_PSYC_OP_UPDATE.

[Tobias Platen]

I just saw that there is 
enum GNUNET_PSYC_Type
{
  GNUNET_PSYC_TYPE_DATA = 0,
  GNUNET_PSYC_TYPE_NUMBER,
  GNUNET_PSYC_TYPE_LIST,
  GNUNET_PSYC_TYPE_DICT
};

My next plan is to build a test gui application,
that only uses psycstore. One that runs on GNU/Linux based smartphones.

Tobias

On Mon, 2022-01-24 at 15:22 +0100, carlo von lynX wrote:
> On Sun, Jan 23, 2022 at 09:03:36AM +0100, Tobias Platen wrote:
> > I had a quick look at the gnunet psycstore, which is part of the
> > musticast implementation. ASSIGN is already implemented,
> 
> Thank you for taking a look. Oh yes, I find it should really
> be called musticast rather than multicast..  ;)
> 
> > GNUNET_PSYC_OP_SET is clear as it does nothing.
> > GNUNET_PSYC_OP_AUGMENT,
> > GNUNET_PSYC_OP_DIMINISH, and GNUNET_PSYC_OP_UPDATE are currently
> > unimplemented in the database code. As those depend on type of data
> > stored in the db, I guess that should be done in the application.
> > From
> > the psycstore point of view all state variables are blobs. So type
> > information is needed to implement those in the psycstore.
> 
> Correct. If the psycstore has no idea what's inside, it can
> not append new data to a hash or array, or simply sum up an int.
> 
> Also GNUNET_PSYC_OP_SET is intended for variables that are only
> local to that specific message, so there's nothing to persist in
> psycstore, which AFAIR only contains the current view of the
> channel state (which is enough for most PSYC applications and
> needed to produce social media profiles etc in secushare).
> 
> More advanced applications would want to have a complete history
> of all the messages that came in, whereby not the implementation
> of AUGMENT/DIMINISH/ASSIGN and SET are happening there, but only
> the fact that such operations where part of the message. In that
> context it is correct to also store GNUNET_PSYC_OP_SET ops.
> 
> And even more advanced application would maybe want to be able
> to access the state the way it was at any given time, allowing
> features like.. hey, how did Frankie's profile look like three
> years ago? - but so far it's not a priority. Also, GDPR compliance
> might also require to retroactively eliminate parts of the
> history. Right now I'm not sure whether GDPR applies also to the
> exchanges between private persons, as in GNUnet no companies
> are involved. If that is so, then I would happily advertise it
> as a software that can only be used among common citizen - not
> suitable for capitalization.
> 
> Don't remember what GNUNET_PSYC_OP_UPDATE was about, as it is
> not defined in the PSYC spec. Also, I question whether it is a
> good idea to do a binary encoding of the PSYC protocol on the
> wire if PSYC was specifically designed to combine the strengths
> of binary and text-based in its syntax - exactly with the
> purpose of no longer having to roll out a new version of GNUnet
> just because secushare has added some new features. If we're
> only talking about internal representation, then it's fine. Just
> consider that one of the strengths in the text-based syntax is
> that it can be parsed in place without memcpy operations (as
> implemented in libpsyc and not yet included in GNUnet), so you
> could be filling those structs with pointers to the buffer where
> the PSYC message already resides.
> 
> Again, thanks for taking a look. Having scalable multicast
> distribution trees with state storage would be a breakthrough
> to allow us to do all those typical cloud applications in GNUnet
> rather than in the cloud.
> 
>