上面有人说用 github 项目不看授权。我仔细想了想确实，因为只比较熟悉常见的开源协议，这种 github 识别不出来的协议确实不熟。

所以我仔细看了下协议内容，想问问懂协议的，我看到协议有两条比较不能理解，求解惑:

1. If you are entering into this EULA agreement on behalf of a company or other legal entity, you represent that you have the authority to bind such entity and its affiliates to these terms and conditions. If you do not have such authority or if you do not agree with the terms and conditions of this EULA agreement, do not install or use Immersive Translate , and you must not accept this EULA agreement.

上文所说使用沉浸式翻译就相当于签署 EULA 协议，那什么情况下属于代表公司签署协议？在公司内部用？还是公司自己开发了一个浏览器然后内置沉浸式翻译？因为公司是一个抽象实体，并不具备下载软件这个行为。所以我不理解这种情况


2. You are not permitted to:
Use Immersive Translate for any purpose that the creators of Immersive Translate considers is a breach of this EULA agreement.

如果我高度遵守该协议，我是否每次使用沉浸式翻译都应当去询问创造者我是否可以在某些地方使用？因为该规定比法律中的“等”更加抽象。所有的决策权取决于创建者本人的想法，如果他认为你不应该这么做，那么你就是违反了该协议。但是没有任何前置的告知。如法律中规定"等"的法律解释是等是包含大众认知的比前面举例情况同类且更加严重的情况。

就类似最终解释权归创建者所有，只要你使用了就可以在任何时候起诉你这样的规定？我不是很确定因为我对这方面不了解。有了解的同学可以帮忙解释一下类似条文的目的么？

我也有类似的标签管理问题。我的问题在于因为工作需要我不得不长期开着一堆标签。
所以我也做了一个标签管理的客户端，把常用的不打算关的网页单独放一个客户端，浏览器开的都是可以随时关不心疼的

https://github.com/msgbyte/webbox

国内开源是这样的。

@ShineyWang 因为这就是 obs 的无摄像头画面，这是视频，没有开视频。。

太强了，我什么时候才能变成和 dalao 一样可以靠自己产品赚钱的开发者

强啊，像我还在为爱发电的状态。产品根本不收费

我看了下我的掘金才 4 级。仰望大佬

道理我都懂。但是可以试试 [tushan]( https://tushan.msgbyte.com/). 真开源

vscode remote server 会内存泄露，卡了打开 top 一看全是 vscode 的进程

@monster1priest 哈哈我就是这样的。不过我写的也不是 RESTful.
我就喜欢 rpc ，微服务操作转 http url 而已，根本不关心你是 get 请求还是 post 请求

@yagamil 不可能，想多了。
全职做开源不代表之前不做开源。我觉得这两者还是有区别的

@tomsun28 已加莫辜负

@cnbatch 哈哈，我也偶尔会有一些我好几年不管的小项目突然被人开了 issue ，就很慌因为我自己都看不懂代码了。。

@dw2693734d 我不是很熟悉 tg 的聊天分组。不过我不理解为什么会很难找到之前的聊天群？因为是固定的几个频道和群组，并不像其他的 IM 会不断地无限制的增加群组。
我用飞书过个半天我就找不到之前的群组了，因为每件事都是一个单独的群组。这就是一般的无频道的群组会出现的问题，难道固定群组的数量控制会比不过动态群组么？

@aapeli 现在就是这样的

@duke807 感谢你的回复。

首先连接的问题就是不方便，这个见仁见智吧。如果你喜欢通过邮件列表的方式沟通的话可能确实链接更加适合你。

其次是链接带参数的问题。如果分享的连接直接就是公开的，那这叫“互联网上通过链接访问的用户均可见”，这也是一个权限层级，如果你用过飞书文档的话应该是知道的。他们不是同样的权限等级。可能你不是很敏感，但是对于权限敏感与风控要求高的企业来说这些差异是非常关键且必要的，同时做到在便利性与权限可控性这点上做到兼顾，这就是我为什么喜欢飞书这个功能的原因

然后是连接的价值，我不认可你说的只对大公司有价值。哪怕是对个人来说也是有价值的，可以看一下这个产品: https://zapier.com/ 专注于做连接的价值

最后关于联邦，你的想法和我的想法是差不多的。我对联邦功能的预期也是不同企业(不同 tailchat 实例)的员工能够进行相互沟通。

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

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

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

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

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

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

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