gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Open questions regarding new messenger and secushare and organizatio


From: Martin Schanzenbach
Subject: Re: Open questions regarding new messenger and secushare and organization Was: Make GNUnet Great Again
Date: Sun, 15 Nov 2020 19:59:52 +0900
User-agent: Evolution 3.38.1 (3.38.1-1.fc33)

Hi,

the point why making a distinction between an unmaintained component
and a maintained component is the following:

The key architecture components of GNUnet are:

- core
- transport / TNG
- NAT
- DHT
- GNS
- Cadet

Basically all services will in one way or another rely on almost all of
the above. Including secushare, fs, messenger and others.
The issue is that developer resources are extremely scarce and should
be focussed on the first group and making it functional and reliable
before they are invested into the second. GNUnet (as you surely also
know) carries a LOT of technological debt in the form of components
where the original maintainer is now AWOL.

So, if due to a lack of maintenance of the developers responsible for a
"higher-level" service gnunet.git fails to build from source, we must
avoid another developer having to invest time to fix the issue.
Even if that developer was the cause of the issue due to a change in
the base components!
This concept holds true for other components as well. For example, rps,
regex, consensus, reclaim, fs.
If any of those components become ballast (i.e. FTBFS) they will be
moved into an external repo. Experimental components must AT LEAST
build.

This is why moving the existing secushare code back hinges on
maintenance by the secushare crew. If that is not realistic for
whatever reason. I am very reluctant to incorporating it again. Hence
this thread. The correct term then would be "abandonware", not
vaporware.

Regarding the "vaporware" claim: Yes, by definition GNUnet is vaporware
because it has been in development for decades. Partly because higher-
level services were developed in parallel to the lower-lever services.
Further, developer resources are extremely scarce atm to a point where
development is proceeding at snails pace.
But, as t3ss said, I urge you to consider why you are "lured into
writing much code" for secushare on one side and on the other are
waiting for transport/cadet to be usable until you can contine.
Wouldn't it make sense to help with transport/cadet instead of waiting
in order to achieve this goal?

Anyone is invited to help with the transport rewrite. Even just reading
the API and looking at the existing source code helps. t3ss, grothoff
and I will surely help with any questions on the mailing list. It is
the first step towards a contribution.
The task is very difficult and any help is appreciated.
It may not be as exciting as writing a new application or usable
service, but it is what it is and there is a lot to learn.

BR
Martin 

On Sun, 2020-11-15 at 11:14 +0100, t3sserakt wrote:
>  
> 
>  
>  
> On 15.11.20 10:13, carlo von lynX wrote:
>  
>   
> On Fri, Nov 13, 2020 at 12:36:21PM +0100, Christian Grothoff wrote:
>  
> >  
> > >  
> > > - Is "messenger" a part of "secushare"?
> > >  
> >  
> > In my view, it's a fresh attempt to build something that might be
> > considered part of / become part of the secushare vision. That
> > said, I
> > think its premature given that messenger clearly is still evolving,
> > and
> > secushare remains largely vaporware
> > (Secushare-people: do correct me if I am wrong here).
> >  
>  
> Well, GNUnet remains largely vaporware and each time we tried to get
> a minor thing working in secushare we ran into fundamental issues on
> the GNUnet level that needed addressing first… your public
> announcement
> for 0.14 still provides no guarantees that CADET, core and transport
> will do their jobs - although nearly nothing can be built on top
> while
> that isn't the case.
> 
>  
> >  
> > That's the key point: if someone maintains it, it can come back.
> >  
>  
> How can you expect that we maintain a project that would be a kind
> of Facebook replacement if the replacement for HTTPS still isn't
> reliably working? On the contrary, since you lured us into writing so
> much code for a dysfunctional framework underneath, I consider it
> your social reponsibility to keep the code up to date through *your*
> API changes, and not us! *You* should maintain secushare! And do the
> best to motivate us to come back and work for you. We invested years
> into YOUR project and you call US vaporware after all of that?
>   
>  
> As someone started joining secushare before working on GNUnet I like
> to remember everybody here that in the end it makes no difference to
> distinguish between secushare or GNUnet being vaporware, because we
> all want to fix the same problem! 
>  
>  
> Calling secushare vapoware is not wrong, but it was no good idea to
> do so, without to be clear about the reasons for that! 
>  
>  
> From the release 0.14.0 news item:
>  
> "only suitable for early adopters with some reasonable pain
> tolerance"
>  
> It is not only users, but also developers who need to have pain
> tolerance, because this is no sprint but a marathon to get things
> working. Our main problem is still resources, because it is not easy
> to find developers with the needed expertise and pain tolerance who
> want to work as a volunteer or for less money they could get working
> for some company with a lot of money.
>  
> So please - I can understand all the frustration, but we should go on
> together and work on those details that are needed to fix right now.
>  
> Happy hacking!
>  
> t3ss
>  
>  

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]