对这个项目挺感兴趣的，有没有计划继续把这个项目完善起来。

[arden]

这几天找了一下关于go做im的开源项目，发现这个研究非常不错，比原版更轻量，也更符合go的生太体系，有没有计划把这个项目做的更完善一些，比如增加离线消息处理等。

[helloddyl]

这几天找了一下关于go做im的开源项目，发现这个研究非常不错，比原版更轻量，也更符合go的生太体系，有没有计划把这个项目做的更完善一些，比如增加离线消息处理等。

我也很感兴趣,提前报个名

[tsingson]

兄弟们, 不好意思, 没看到消息就锁定了.

请转到 https://github.com/tsingson/goim 讨论可好, 或者在 goim 官方 repo 里 @我:

作开发的, 有一说一, 个人这样认为:

1. goim 的架构不错, 隐含的部署方式也比较出色, 是一个非常非常棒的技术原型. goim 选择 kafka 也是符合商业项目的要求, 还是建议在原版基础上进行扩展

2. 我已经在 https://github.com/tsingson/goim 这个 repo 上, 把这个实验项目的一些代码, 抽到 goim 上, 并尽量不修改 goim 原体系结构, 可以去看一下

3. goim 是一个技术原型, 成熟度非常高, 几乎可以放在小型应用环境里. 但是, 这个原型在业务形态上, 就需要自行开发扩展了. ----------> 这些开发扩展, 众口难调, 也许需要讨论清楚再动代码.

4. ex-goim 关停的原因有, 一来, 这个就是个学习过程, 通过修改来学习 goim 的思路, 二是, 仅仅为了学习目标( 甚至是个人阅读/修改的便利), 个人未加计划性的修改了很多代码, 这不利于多人协作共同开发.

5. 如果有兴趣, 确是可以拉一个小组, 尝试在学习 goim 优点基础上, 折腾一个 im 来.

以上, 祝愉快......

.

[tsingson]

这几天找了一下关于go做im的开源项目，发现这个研究非常不错，比原版更轻量，也更符合go的生太体系，有没有计划把这个项目做的更完善一些，比如增加离线消息处理等。

离线消息, 我采用 liftbridge 已经支持消息存储了, 需要实现离线处理是比较容易扩展的.
不过, liftbridge 是 nats 的一个内容持久化扩展, 这个库还比较新