Hi! On Thu, Jun 27, 2019, 15:57 t3sserakt <t...@posteo.de> 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 https://docs.gnunet.org/#Developer-Introduction? Be > careful, because the information in the C Tutorial, if you follow the > link https://docs.gnunet.org/manuals/gnunet-c-tutorial/index.html#Top, > 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 https://github.com/marado/gnunet-groupchat and a few personal notes of things I was planning to do in https://github.com/marado/gnunet-groupchat/issues 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: [serverside] cadetserver $(gnunet-peerinfo -s) welcome localhost 8888 [clientside] 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? Cheers, -- Marcos Marado
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
