[Top][All Lists]

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

Re: [GNUnet-developers] Contribute to groupchat. was (Re: Hello! (brief

From: Marcos Marado
Subject: Re: [GNUnet-developers] Contribute to groupchat. was (Re: Hello! (brief introduction and lots of questions))
Date: Thu, 27 Jun 2019 22:02:34 +0100


On Thu, Jun 27, 2019, 15:57 t3sserakt <address@hidden> wrote:
Hi Marcos,

welcome and cool you are interested in helping with groupchat.

Submitting a patch in Mantis is not the way it used to be, but your
contribution was valuable.

Did you read here Be
careful, because the information in the C Tutorial, if you follow the
is partially outdated.

Many years ago :-) So, from what I read in there, patch submissions should do done by sending each patch to this mailing list, OK. Good to know that it applies to all gnunet related projects and not just the core parts of GNUnet. 

Do you like to help implementing new functionality?

You can see a few changes I've made already in
and a few personal notes of things I was planning to do in

But as I thought more about it, I think groupchat doesn't make much sense as it is.

We are right now changing the groupchat code a bit, and tomorrow we will
make a plan how we like to go on with groupchat.

If you are interested we can keep you informed about those plan in
detail. High level information will be communicated over the mailing list.

Please keep me updated!

In the meantime, my idea on why ir doesn't make much sense as it is:
* Currently we have one binary that works as both server or client. While that's OK, there's really no reason why should this be the case: the work of the server is inherently and radically different from the work of the client;
* The client is, in fact, nothing more that something that connects via cadet to a peer and a port, and then sends and recieves text. More generally, it isn't really a groupchat client but a sort of "netcat for gnunet". Making a gnunetcat would have several advantages: not only it could be used to connect to a groupchat peer/port, but it can also be used to connect to any other server available via cadet, same way.
* Left with just the server, I quickly ended up with the feeling that contributing to it would be a lot like reinventing the wheel. Why? Well, the server has two attributes: it is a text based chat server (like a talker, or any other MU*), and it is available via CADET. So, (a) why doing a groupchat should have to mean writing an entire talker, just because we want a talker that is available via CADET?, and (b) does this mean we'd be tempted to write an whole server to the next thing we want (mail, or whatever)? It seems to me more reasonable for us to, instead, write a sort of 'tcpserver' for cadet (cadetserver, why not): basicly a binary that tunnels between cadet "connections" and a local binary... or, really, a TCP server.

IE, I'd like to be able to have, instead of groupchat, something like this:
cadetserver $(gnunet-peerinfo -s) welcome localhost 8888

gnunetcat $SERVER_PEERID welcome

And, of course, instead of having to implement an entire talker server, you can be running any of the free software alternatives for one on your server's TCP port 8888.

This would also let you, of course, run any other TCP server over cadet, as well as communicate with it.

Does this many sense to you? If not... what am I missing?

Marcos Marado

reply via email to

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