blueprint-freespeech / ricochet-refresh

Anonymous peer-to-peer instant messaging
https://www.ricochetrefresh.net
Other
157 stars 27 forks source link

Feature request, add a optional group chat ability #163

Open ASmith- opened 1 year ago

ASmith- commented 1 year ago

Feature request, add a optional group chat ability

There are times encountered by many using ricochet-refreshed and other communications utilities when the user wished the application had a optional group chat ability for them to more quickly address a group of contacts at the same time rather than one at a time.

Thanks for your development on this encouraged communications application and your consideration on this request.

odiferousmint commented 1 year ago

I do not think that it is as easy as it sounds. Cwtch achieved group chats but I am not sure if they had to sacrifice anything[1]. Regardless, group chats might not end up being implemented anytime soon.

(It has been a while since the last time I read the current protocols and such.)


[1] Found this: https://docs.cwtch.im/docs/groups/introduction

pospeselr commented 11 months ago

I can comment on this broadly to give some context here.

So long term we definitely want some group chat functionality.

In the short-term we need to finish up our work on gosling and get that to a 1.0 stable initial release. The tldr there is that Gosling will replace the lowest level of the Ricochet-Refresh backend and provide a more secure+private by default foundation for a future chat protocol, and give users more control over their own privacy+metadata.

Once its ready is ready for prime-time, then we can re-imagine the Ricochet-Refresh chat protocol from the ground up, what features we want to implement such as group chat, and how to do so without sacrificing the sort of core properties we're going for:

A group-chat features makes the decentralization and metadata resistance requirements challenging, but hopefully not impossible.


At this point I'm welcome for discussion/ideas around how group-chat would be implemented, particularly in the context of a gosling backend.

I suspect the right way to do this is to require all members of a group chat to be contacts with each other, to avoid the need of running extra onion services specifically for group chats.

We'll need some kind of synchronization mechanism to handle branching and joining conversations as sub-groups inevitably shard-off believing the other members aren't online, and then rejoining.

We'll need to be able to somehow do group file-sharing.

etc etc