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

[xrs]

Hi Marcos,

On Mon, 1 Jul 2019 12:44:41 +0100
Marcos Marado  wrote:

> Unfortunately, I won't be able to attend to the weekly meetings. Are
> there minutes, logs or recordings of those meetings?
> 
> 
> Thanks for taking your time helping me understand more about the goal
> here, and for your work on secushare in general,

Yes, we have repo at https://git.gnunet.org/secushare-spec.git with a
mumble.log. We can give you access. 

If you like we could arrange an out-of-order meeting with you and get
to know each other. Please propose time (with timezone)! What we have so
far are some WIP design spec (research is still necessary), C code of a
former secushare implementation, and the nim code of the groupchat. 

Hope to hear from you :-)

Happy hacking,
xrs


pgpRz9vNNhXZ9.pgp
Description: OpenPGP digital signature
___
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

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

[Marcos Marado]

Hi there,

On Mon, Jul 1, 2019 at 11:36 AM t3sserakt  wrote:
> Hi Marcos,
[...]

Thanks very much for your reply, it was quite elucidative.

I know about the aims of secushare (I've been lurking and trying to watch its
development, as my particular interest on it is really a the realization fully
decentralized virtual world, which is what groupchat could be the start of).
However, when I learned about groupchat, and looking into its code, I saw no
relation between it (as it is, at least) and secushare: it looks to me as being
fully a client-server model...

So, what I was failing to see was that there is a plan to evolve what groupchat
currently is into a serverless, distributed chat system. The 'main task' to
achieve that (and the one I'm personally more interested in) seems to be this
one:

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

Is there something written up explaining in more detail what, in practical
terms, does this mean? A list of tasks to implement, or something like that?

As it is, I have several ideas on how to contribute with groupchat as it
currently is, but that would be mostly working on the current usability *with*
the server model, which seems like a bit of a waste of time, considering the
goals for groupchat.

Unfortunately, I won't be able to attend to the weekly meetings. Are there
minutes, logs or recordings of those meetings?


Thanks for taking your time helping me understand more about the goal here, and
for your work on secushare in general,
-- 
Marcos Marado

___
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

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  > 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 
>
> [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 .
>
> 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
___
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

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

[Marcos Marado]

Hi!

On Thu, Jun 27, 2019, 15:57 t3sserakt  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 

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

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