如果真的要方便使用，我个人的评价是搞个微信登录会更加方便一点。。

在我国有手机就有微信。

@ryan4yin 开源精神不仅仅是局限在代码/技术层面，哪怕 b 站美食区把自己研究了很久的食谱配方分享出来，让别人能够按照步骤复现那也是一种开源啊。开源的好处就在于社区能够推动你的前进，金钱报酬就是物质需求，当我们吃喝不愁的时候更加需要精神报酬。点赞

@vevlins 哈哈，单纯的重复的推广是最没有意思的，我们技术人能够分享过程中顺便推销一下，达成双赢才是最好的。

@guguji5 可以看图片。从 21 年 7 月开始做的。单纯的 IM 其实不复杂几个月就能做一个完成度很高的东西了，但是同质化的内容是最没有意思的，要把底层的设计做好，并实现一些个人的设计哲学，就会花费更多的时间。

@lizheming 啊仔细看了一下就是我想要的。原项目没有用的原因就是因为我想要在原来的内容上修改而不是追加一条回复。研究一下，感谢

@star7th 殊途同归。坚持自己的路，开源就是一条充满荆棘的路，开源人共勉。


@lizheming 看了下你 fork 的 github-translate-action 父项目我 star 过，也准备用来着。能说下你增加的 86 个 commit 是干啥来着的么

@moxuanyuan 工作一般会有其他的更加专业的 IM ，比如钉钉飞书企微，国外一般用 slack ，玩游戏的会用 discord 。吧目光脱离微信，你会发现这软件是真的辣鸡。但是正如我文章写的，因为微信的生态起来了，所以你就没办法撼动他的地位

@BeiChuanAlex 虽然你总结的很对但是第一点抓热点不推荐。

都做开源了，还是建议做长有价值的事情。就比如蹭热点搞个重复的 chatGPT 的代理套壳是有价值的么？我觉得可能短期有利长期无价值，只是为了做短期的话，其实没必要搞开源，赚快钱嘛不寒碜

当然这句话不绝对，如果是想基于 chatGPT 来强化已有的业务比如 chatGPT 生成低代码项目，chatGPT 构建报表之类的还是有价值的（因为 chatGPT 自身是长期有价值的东西）

@fregie 首先做开源是为爱发电是常态，所以做开源的都是一群理想主义者。一个开源项目对于大部分人来说最简单最直白的方式就是方便找工作。见码如见人，这不比一纸简历好用？另一种方式常见就是提供企业服务


@xieyuheng 你可以随意的在本帖子下方宣传你的开源项目，我不介意的，因为本帖子的内核就是分享。但是建议不要在其他人的帖子下面宣传，这其实是一个非常不礼貌的行为。类似 b 站弹幕礼仪 [请不要在无关的地方提 up 主]

@jiulang 我说了这个数据其实并不高，甚至可以是辣鸡。仅仅是分享一下我为此做的努力，期望能帮助到更多为了几个 star 兴奋的开源爱好者。

毕竟大部分人都是为爱发电

@ospider 因为你的项目是无需理解的且目的性比较强的库，因此运营的需求会相对少一点。运营更加在于如何让自己的项目在同类产品中竞争。比如以求职为例，你觉得你的能力很强，那你怎么表现出来让 HR 在 100 个候选人中选中你呢？再比如目前同类的 chatGPT 套壳应用这么多，大家功能大差不差，那么凭什么用户最后选择你呢？

@jokimina
1. 自己写的，但是借鉴了一些比较成功的案例。如果你也想自己写官网的话可以提前收集一下别人好看的官网做参考。重点不是堆积内容而是把重点尽可能简洁的给用户
2. 因为包含大量的同色色块，因此压缩算法的压缩率会比较高。你可以使用在线的压缩工具来帮你压缩图片体积比如 tinyPNG 。另外还有一个小细节是切换亮色 /暗色模式是两张不同的图。

@wushigejiajia01 有客户端，而且产品思维是完全无关的。电报是注重隐私的 IM ，Tailchat 更多的是注重业务的 IM
相比来说更像是 discord ，工作方式更像是飞书，形式更像是 vscode

正如我文中所说，想要让用户理解你的产品形态与设计哲学是非常困难的一件事。我还在为止不断努力

@harrozze 你可能没有理解端到端加密。端到端加密就是为了避免服务端看到消息。而群组是控制在服务端下面的。。。

你的方案解决的其实是加密传输，这个通过 https 协议就可以解决

@YGHMXFAL 十分感谢你的回复！确实单纯的端到端加密并不会给我带来太多的流量。而我的项目的特色功能是开放式的插件系统，单纯的跟随前人做过的事情给我带来的竞争力并不会有什么优势，我应该更加专注于我的特色功能。
（毕竟万一之后生态起来了有好心人帮我做了 e2ee 频道的插件呢(笑)）

@0o0O0o0O0o 如果讨论到这些情况 e2ee 也并不是完美的。只能说相对安全罢了。信任客户端、信任服务端、信任宿主机、信任服务器，其实没有本质区别。安全的本质就是在不断拉高攻击者的成本与付出。

@MFWT 我也是这么想的，不过人力有限需要考虑优先级，所以问问论坛里大家的看法

@wheat0r 感谢你的回复，不过我作为程序员我确实没觉得端到端加密有什么必要性，毕竟我常用的 90%的软件都没有这个功能。。。反而如果一条消息我在电脑端能看手机端不能看我反而会觉得很困扰（ e2ee 的各种边界 case 之一）。而我的目标用户应该也不会追求 e2ee ，只是我想尽可能满足常规的要求(老实说另一方面是 e2ee 虽然可能在乎的人实际并不会很多，但是作为一个宣传点是非常好的)

@delete26 是的，设计时对市面上的竞品都有一些调研。

@nielinjie 区别是重写的部分 react-admin 的设计，让其更加合理。
比如 react-admin 没有级联菜单需要自己实现，tushan 很好的解决了这一问题
比如 react-admin 是 material design 设计的不符合国内的普遍审美，tushan 使用了扁平化的 UI 风格
比如 react-admin 的各种场景需要使用不同的组件(比如输入场景、列表场景、详情页场景)，而 tushan 统一了字段定义，真正做到了定义一次用在多处（也对自定义字段的实现进行了简化）。
具体还有很多细微的调整，基本上除了为了复用 react-admin 的生态然后用了同一套 api 协议以外，设计的概念全部重写了



@kemistep523 tushan 更多的是一个库而不是一个项目，一个库需要二次开发么？在 tushan 你根本不会有二次开发的概念（你尝试以后就知道了）。
你可以理解为 tushan 给你提供了一个开箱即用的工具库，来帮助你做一个加法。而像是那种直接给你一整套项目让你做减法的，可能短期内你可以做一个看上去非常强大的、完整的项目。但是这些相当于天然给你套了一堆技术负债，因为现有的模板不是完全贴合你的业务做的，因此很多外包同学也不愿意接手别人写的项目宁愿自己写。
当然如果你的预期就是拿别人现成的项目改个标题改个模型，然后不进行长期维护的话，那么这种模板项目可能是适合你的。

@LiuN1an 我都用过。用了很久我决定自己重新写一套来填坑。

@loading 界面使用的是字节的 arco design ，你说的简陋可能只是简洁，因为设计目的是让用户做加法而不是做减法，如果想要一开始很复杂的、花里胡哨各种功能的，可能并不适合使用 tushan 。你说的成型的脚手架也是有的，可以通过命令行工具直接创建。

@loading 有没有可能前端不像后端有这么多语言可以选择。网页前端只有 js 。。。后端随便用什么语言可以自己实现，只要接口协议能时适配上就好了。

@sphawkcn 是的。api 接口完全 match react-admin 。可以直接嫖他的生态