Re: Semantics of GNUNET_PSYC_OP_AUGMENT, GNUNET_PSYC_OP_DIMINISH, and GNUNET_PSYC_OP_UPDATE.

[carlo von lynX]

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.