Re: [GNUnet-developers] Contribute to groupchat. was (Re: Hello! (brief introduction and lots of questions))

[t3sserakt]

Hi Marcos,

On 27.06.2019 23:02, Marcos Marado wrote:

Hi!

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

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

Correct, that is the reason for planing what we like to achieve with groupchat. At the moment it is a prototype to use and try out Cadet.

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;

Yes, we will separate the code. Furthermore we like to get rid of the server completely, because this contradicts the core principles of GNUnet to have no clients and servers at all.

* 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.

Actually we already have something like that. That is the gnunet-cadet cli.

* 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?

If you just want to use existing services over Cadet you can try GNUnet VPN.

As mentioned above we like to get rid of the client/server paradigm when using GNUnet for all kinds of fututre application.

What the secushare group likes to achieve is described here http://secushare.org

The groupchat is only a starting point to reach the goals behind secushare.

Some near future high level goals are:

- having nim bindings for the GNUnet identity api
- implementing a psyc parser in nim
- get rid of the groupchat server, but using available (being online) peers in a group to do the multicast.  This obviously needs peers of the group being online to have asynchronous messaging.
- better usability of the TUI
- a REST Interface for the groupchat functionality.
- a web interface using that REST interface

Far future goals

- introducing relay (not part of the group) nodes, for doing the message multicast in case no peer of a group is online. Therefore we need to introduce some group encryption.
- Metadata protection when using the relay nodes. Therefore we need an additional layer above cadet to hide the cadet route. Ideas for achieving this is onion routing, or decentralized mixnets.

If you like to know more details join our weekly mumble on Wednesday 20:15 CEST.

Happy hacking!

t3ss

cheers

t3sserakt

signature.asc
Description: OpenPGP digital signature