![]() Of course this is an issue because we can no longer get data from the user A full rearchitecting may be in order here however its not impossible to modify the current architecture so far The main issue here is that the cache is doing too much I think If the termion(main input) task does its thing, and a socket task, waits around waiting to build a sub task(socket) then we may be able to pass messages to the socket task to open up sockets when request This allows us to have shared state via message passing and a main task can take care of updating the cache. The renderer can then request data from the cache when it needs to render stuff |
||
---|---|---|
chan-like | ||
docs | ||
freechat-client | ||
invites-manager | ||
json-api | ||
misc | ||
rtc-server | ||
scripts | ||
tui | ||
.gitignore | ||
.gitlab-ci.yml | ||
.gitmodules | ||
contributing.md | ||
docker-auto-build.sh | ||
LICENSE.txt | ||
readme.md |
FreeChat
What this is
A FOSS chatting platform that brings in more modern features that a lot of people have come to expect.
Why not just IRC/Discord/Slack/Mumble etc?
A tonne of IRC channel are basically dead since so many have moved to Discord/Slack. Why? Because those platforms have features that IRC just doesn't have. A lot of people have deemed those features worth the switch.
Discord/Slack are proprietary spyware with no real alternative. The quality of the service is high enough for people to ignore the datamining, it's time a proper client came by.
Mumble could work but has an awful reputation amongst regular non-technical users.
So it's a Discord/Slack clone?
Chat history is limited similar to nearly every chan/booru. This can be turned off to preserve all chat history.
The biggest difference is the lack of data collection; servers collect the following data:
-
User id - generated by the server
-
User password - generated by the server
-
User name - provided by user
-
User chat - How much depends on how the server was configured or if a message was pinned to NOT be deleted.
-
Users Status - user is online/offline: HOWEVER this is controlled by the user.
-
User permissions - To discern admins from less privileged users.
Working Status
Is this finished or almost finished?
Short: The API has basic functionality for chatting but still requires more endpoints to be fully featured. So yes the API at least is in a MVP state. But everything else is either in infancy or not done.
Long: No. A basic client is still underway and the chat API is missing a metric tonne of features. However The state of the chat API is such that it shouldn't be hard to implement many of the desired endpoints.
How to help - if you want to
Check the contributing guide