@dawn009 Teams 是封闭生态，Tailchat 是开放生态。
优缺点就和 ios 、安卓现状差不多。

而 teams 比 ios 更加封闭，就相当于做了一个手机系统，然后系统里所有的 app 都是自己做的。优点是性能会比较高，缺点是不一定足够丰富，而且用户没法选择。
tailchat 的话同样的需求可以由多个插件提供与竞争。用户可以根据产品力而不是生态来选择适合自己的功能

@yidadaa 感谢大佬分享，收费相关的计划是为企业服务，帮助企业把自己的业务整合流转起来，我自身并不做经营相关内容。

@duke807 因为单个业务的价值是比不上连接的价值的，为什么会有 sso ，为什么会有 oauth?
当然可以单独使用多个独立的应用，但是想象一下，假如你收到一个审批，但是因为审批是在单独的网站中，你是喜欢直接在收到的地方（不论是 IM 还是邮件）点一下通过，还是点击链接跳转到审批系统然后登录(或者自动登录)到相关的审批项中点击通过（我们假设是并不复杂的场景，只需要简单上下文就可以做判断，因为这种场景是占大多数情况的）

我承认专业的应用应该交给专业的项目，而不是像飞书这样自己做一套完整的生态。tailchat 更多的是作为一个以 IM 为中心的基座将各种各样的业务连接起来，就和 slack 做的一样（但是我认为 slack 做的太基础了，还是逃不开 im 本身的局限性）

如果光靠连接就能解决所有问题，我觉得互联网很多产品都没有意义了。比如我就很喜欢飞书的一个功能，给对方发一个飞书文档的连接，就能自动给对方授予可读权限，如果是发在群里，那就群组里所有人都自动授权。如果按照你的说法就是把连接发给用户，然后再单独给用户授权。如果忘记了还要二次沟通

另外我看到你提到了 matrix 且着重提到支持联邦。事实上 tailchat 也计划在未来支持联邦功能。想了解一下你认为联邦能解决你什么问题，或者说痛点？

@duke807 不。小而美之所以小而不美就是因为他不是通过加插件实现的，而是一股脑都喂给用户了。用户没有选择权。我不能说因为我不看小视频，所以让微信不要给我任何关于小视频的内容。

以你的例子来说，飞书项目不能满足你的需求，所以你换成了 redmine 。redmine 没有跟飞书有任何打通。所以成为了一些负担。因为飞书只能跟飞书项目有联动

但是 tailchat 给予用户选择权，因为 tailchat 的生态不是 tailchat 开发的而是由用户开发的。有的人喜欢飞书项目，那么就是 tailchat x 飞书项目，有的人喜欢 redmine, 那就是 tailchat x redmine 。

这就是 tailchat 与其他所有的 im 都不一样的地方，也是与钉钉飞书这些同样试图通过 IM 为中心打造企业系统生态的区别。可以更加深入了解一下 tailchat 的设计哲学，就不会说出“99.99% 的公司不会喜欢这种东西”这样的言论。

另外飞书是很受业内欢迎的优秀产品，我不确定这个 99.99% 这个数字是哪里来的？

@shaojz2005 可以推荐一下技术圈子么？

@lilei2023 一个半月可搞不出来。另外也不是 discord 换皮。。。discord 还是传统的 IM 应用，开放性和可拓展性都是远远比不上 tailchat 的。当然在一些细节上 tailchat 海远远达不到 discord 的等级。

@LowBi 加油，我之前也是全职上班，下班后搞搞自己的东西。人生就是要折腾

@winglight2016 仓库里不是有么？

@duke807 noIM 是一个设计思想，小而美是对项目规模的一种描述。
一般不理解的我都会以 vscode 举例，vscode 什么插件都不装的时候就是一个单纯的文本编辑器，装了插件以后就会变成各种各样功能强大的 ide 。
与一开始就做一个大而全的应用有什么区别？区别是 tailchat 是加法且用户可选择的加法
拿经典小而美产品微信距离，tailchat 本体就是一纯粹聊天软件，加了插件以后才能拥有朋友圈、摇一摇、小程序、小视频之类的功能。。用户不喜欢可以不用，这是一种选择权的赋予

@qloog 包含的。
服务端、网页端、桌面端、手机端、包括前后端的 sdk 、各种插件、网站源码都在一个仓库里。咱是正经开源

@encro 是的，大方向就是做生态，插件系统是做生态的最佳解决方案，tailchat 可以作为企业的信息基座，连接内部各种系统

我也准备写一篇 [因为 Tailchat 认识女博士，如今已经领证了。]
现在就差女博士了，有愿意报名的么[手动狗头]

@SolarHurricane 默认就是获取基础配置，如果要额外的可以再加

@SolarHurricane 我是按照自己理解做的第三方登录，通过重定向过来的 code 换取临时的 access token 再换取用户信息，用用户信息匹配用户进行登录（没有匹配则自动注册）。
大致的操作就是达到一个通过第三方平台的 id 映射到自己平台的 id 实现一个无密码登录的操作。
这里是相关的实现连接可供参考，如果我写的不是正经实现方案也欢迎指出讨论，我想了一圈应该是没有安全问题的
https://github.com/msgbyte/tailchat/blob/master/server/plugins/com.msgbyte.iam/strategies/github.ts
https://github.com/msgbyte/tailchat/blob/master/server/plugins/com.msgbyte.iam/services/iam.service.ts


@oneisall8955 通过代理转发肯定能实现操作，但是我考虑到两点:
- 如果用在正式服务上可靠性减半，因为增加了中间环节，而且还需要维护中转节点
- 本来 https 可以保护数据不被篡改，中间加了一层以后出现了安全隐患。

不过你这个方案我学会了，并且打算用一波。因为我后面还打算接入 google 登录。github 还时不时能脸上 google 就真的没办法直连了。感谢大佬分享

@oneisall8955 很懂嘛，是的。辣鸡 gfw

第一，id 可以作为后续操作的唯一标识，比如你要点击到某一条记录肯定不能是第几条或者某个 name
第二，id 可以作为前端缓存的唯一标识，当然如果不做缓存当我没说
第三，如果这个列表是动态更新的，id 可以优化前端渲染性能(在 mvvm 框架)
第四，代码洁癖，一条记录一定要有一个唯一 key ，不然纯粹靠数组会不放心，当然这个洁癖可以没有

@really28 看了一圈你这个最离谱