Swift-chat: Showcase for distributed application

Community Showcase
, ,
17

It's been a long time since I have posted here, and actually I continue to develop repo from time to time and improving it with small steps.

But recent changes to Discord, and the way how our Swift community is scattered across different platforms, lead me to think—maybe I should finish it in some form and let people actually communicate there? Sure, it's hard to compete with Slack and Discord, and there are lots of other open source solutions‚ but in the end it's also about trying to make something better, while keeping some fun in the process. Another point to work on it is that previous work pushed me to continue developing Cluster system before, so going further will eventually help finding some edge cases and help Migrating Cluster system to Swift structured concurrency.

So, what's the current state?

  • Chat is actually working. :blush:
  • While working on it I've also abstracted and created Event sourcing plugin—basically for persistence, and Virtual actors—where system guarantees one actor across nodes. When combining virtual actor + event sourcing—you have it's always there guarantees if something happens, e.g. node dies with some chat in it—it should quickly recover with latest state on other node.
  • There are some simple iOS, macOS and web clients (based on GitHub - elementary-swift/elementary-htmx: HTMX + Elementary: Hypertext web apps with Swift).
  • It has some basic login + jwt functionality, but needs to be improved.

What should be next steps for basic MVP?

  • Finishing UI to have list of channels where people can join, chat updates also should be streamed (new message and etc.)
  • Some small stuff here and there, e.g. finishing login functionality, or handling some error and recovery edge cases.
  • Proper node discoverability—while Cluster System should work with any, I need to check how this works with k8s or some other simpler orchestration.

Of course this will be a very simple chat, but looking at amount of code—it's actually interesting to see what could be achieved in terms of scalability and reliability with such little. Current plan is to deploy it to some VPSs from multiple providers + my Raspberry Pi at home to monitor how this would work and look like.

After that other features that could also be included, are:

  • Secure 1 to 1 chats, or overall security customisation for chats.
  • Threads inside chats.
  • Push notifications.
  • Video calls for community hours—never worked with WebRTC, would be nice to check, but not sure when.
  • ...

and other features to make this chat a proper place to communicate.

Now the most interesting, but also hard part—what would make this chat unique and competitive? Here I have some quick ideas, could be non feasible, but why not dreaming, right?

  • Having an ability for anyone to deploy it, including adding nodes for anyone to existing chats—to increase scalability and also keeping chat really part of communities.
  • Adding nodes could also work for extending chat possibility—could imagine one would want to add some API or MCP agents on the fly.
  • Maybe not related to chat, but would be nice to have some framework to wrap MCP agents and even run custom LLMs on dedicated devices, that could be easy accessible afterwards. Plus adding some WebAssembly on top to run those actors in a better isolation.
  • Also not quite related to chat itself, but again—this is a showcase for Swift technologies, wanna create some durable workflows on top of virtual actors + event sourcing, like writing in chat /plan Notify @some @another in 90 days which will send notifications in 90 days and this will be reliable if something happens/crashes in-between.
  • While Slack only gives you an option to keep a history for 90 days, and on other hand Discord keeps if forever, which is quite a problem if you have limited disk space—having an option to either keep history and scale, or ability to reduce history log and snapshot to keep memory size strict. Also then some documentation + search functionality could be implemented for that.

I know this is a ton of work to be done, considering also I'm trying to improve Cluster System in parallel, and I don't know where and when it will land. But:

  1. As I said earlier working on some real cases helps understand what should be done better.
  2. One of the Erlang/Elixir advantages that lot's of developers notice and describe is that you can do complicated things with little effort and human resources. Would be nice to prove that it's also a case for distributed actors in Swift.

I will most likely post updates to Swift Open Source Slack (before publishing a proper chat :face_with_tongue:) and maybe some bigger things here. As always if you have any thoughts, concerns, or objections, please let me know—I’d really appreciate the feedback.

9 Likes