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.
