gnunet-developers
[Top][All Lists]
Advanced

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

State of the decentralized groupchat


From: TheJackiMonster
Subject: State of the decentralized groupchat
Date: Tue, 25 Aug 2020 01:33:42 +0200
User-agent: Evolution 3.36.5

Hello everyone,

a while ago we had a discussion about the groupchat we had implemented
in Nim and in C using the cadet-gtk application. It resulted in a plan
for a decentralized chat room (for the start structured in a basic ring
topology).

Because we thought it made more sense to implement it in a separate
library than rewriting the existing code on multiple ends, that's
basically what I did the last months and it's close to finished for
testing.

https://gitlab.com/gnunet-messenger/libgnunet-messenger

The library contains headers to use its functionality on an abstract
layer without hassling with the most logic in the background like
managing all CADET channels, contacts, public keys and messages. It
even provides an automated storage for contacts and messages to load if
necessary for viewing in a UI for example.

The most improvement is handling private chats between two peers the
same as group chats with only two members and that decentralized groups
and centralized ones using one host can change into each other.

This basically means any member joining into a chatroom can also host
it (opening the port for others) and become part of the ring structure.
All other members who don't like to share their peer-id with everyone
except the one hosting peer they connected to can do so as well.

All messages are signed using an ego key you can choose or if none
selected you still sign with the common anonymous key. Contacts will be
identified by the key they use (name is optional and customizable,
member-id belongs to each chatroom and can change if necessary).

It was also added that all messages are identified by their hash and
refer to the previous message with its hash building a graph. They are
even "merge" messages to automatically reduce the leaves of that graph.

The latest feature is a message to request messages by hashes your peer
missed somehow. This will also get handled automatically to complete
the local chatlog. So as long as members don't leave a chatroom forever
being the only one knowing about specific messages, others can still
get them later without permanent connection.

I will probably still change some parts of the abstract API for sending
messages and finish example applications but otherwise it is ready to
use for everyone interested.

I was just thinking if I should make it an actual GNUNET service and
working out how to handle multiple applications using the library at
once with separate egos. (This would also ease testing.) Do you think
this would make sense?

Also... when I'm done with last tweaking I will probably start making
big changes to the cadet-gtk application or maybe rewriting big parts
because it will use the library instead of relying directly to CADET. I
was also thinking about adding features from cadet-gtk to the library
instead (for example the file-sharing and the search for contacts).

Happy Hacking
Jacki

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


reply via email to

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