Re: Open questions regarding new messenger and secushare and organization Was: Make GNUnet Great Again

[TheJackiMonster]

Hi,

On Fri, 2020-11-13 at 08:15 +0900, Martin Schanzenbach wrote:
> Hi,
> 
> tl;dr:
> - Should we move towards a monolithic gnunet.git repo which includes
> gtk/secushare again?
> - Should we instead move optional components (conversation, reclaim,
> messenger) out of gnunet.git as extensions?
> - Is "messenger" a part of "secushare"?
> 
> Long version:
> 
> I was wondering how "messenger" relates to "secushare".
> Some time ago we moved secushare and related components out of
> gnunet.git and into an extension repository [1].
> 
> Now, I do not think we have settled on an approach on how to handle
> our
> component structure. Some time ago I proposed to move most components
> out of gnunet.git into extension repos while grothoff argued that
> maybe
> we should even include gnunet-gtk in the main repo [2].
> It is unclear in general when to use gnunet-ext and when to develop a
> component in-tree.
> 
> I would like to take this opportunity to restart this discussion:
> Should we move secushare back into gnunet.git? (Is the secushare team
> even planning to maintain it?)
> Is messenger an alternative to secushare or should it be part of it?

Currently messenger is an alternative to PSYC in many ways but it's
less focused on social networking. It also doesn't provide any
relationship mappings between contacts or stores data about members of
a chat yet (it is planned to store only current names and a public key
history for functionality reasons).

The messages are also not text based to reduce size of traffic and
storage space which would be necessary to store old messages.

I think it's possible to use the messenger service in secushare for
chatting and managing groups but other tasks would still require
additional functionality (for example you could probably build
something like Instagram on top of the messenger API without adding
much but something comparable to Facebook would require more management
of resources).

> Should we move towards a more monolithic repo in general and merge
> secushare/gtk as well?

I understood secushare as an application which makes sense to put into
an own repository. But I would actually see a reason to merge parts of
gtk into the gnunet repository depending on the implementation.

Seeing GNUnet as a framework it would make sense to add in certain own
GTK components which are useful to design GUI applications or adding
functions similar to GNUNET_PROGRAM_run() but handling the
g_application_run() for GTK as well. So you could start a new
application with GTK and GNUnet context at the same time.

But I would still exclude the actual GTK applications.

> 
> I still have concerns with respect to packaging from a monolithic
> repository structure. A distribution may want to offer multiple
> gnunet
> packages for each component (reclaim, secushare, gtk) in oder to more
> efficiently handle dependencies.
> But this may be discouraged if we have a single repo as packaging
> becomes more tedious.
> Think monolithic texlive vs modular texlive packages (I think most
> distributions now have a modular package).
> OTOH, releasing tarballs for each component is also a pain for us as
> developers.

I think what's quite important if we would split components into
multiple repositories is that the documentation, handbook or something
like the how-to-use page list/mention them. So splitting the code of
the framework shouldn't result in making it harder for a developer to
find necessary parts for an application.

Otherwise I would say splitting for example the messenger service into
an extended repository would be fine because it doesn't even use the
core service (only cadet and identity currently) and it's not planned
to do so.

> 
> We probably also should not too much conflate repository structure
> and
> packaging structure.
> A monolithic repository structure could still result in modular
> packaging. But that would require clear packaging guidelines (from
> US!). Also, source distributions (gentoo et al) always require the
> (full) source tree checkout even for a small component.
> A modular repository structure would make it a lot easier for
> distribution packaging in any case.
> 
> I think I proposed a separation into a set of "core" gnunet service
> and
> extensions. But I am not so sure anymore if that is a good idea. For
> example, missing DHT block plugins of extensions in the "core"
> package
> would result in bad performance of the extension service (?).
> 
> BR
> 
> [1] https://git.gnunet.org/gnunet-secushare.git/
> [2]
>  
> https://lists.gnu.org/archive/html/gnunet-developers/2019-02/msg00002.html
> 
> 

BR
Jacki

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