[讨论] local-first 实现的 Plugin System 有何优势?

[Leizhenpeng]

🥰 需求描述

现在看到 https://github.com/ChatGPTNextWeb/NextChat-Awesome-Plugins 仓库里面的插件, 全部是联网请求类型的.

相比服务端插件,本地系统不仅需要单独设置 http proxy, 还缺少更广泛的oauth支持

所以 local plugin system 的优势在哪里呢?

他可以做到服务端插件做不到的能力?

🧐 解决方案

能否在插件仓库中举例出服务端插件做不到的能力?

📝 补充信息

No response

[nextchat-manager]

Please follow the issue template to update title and description of your issue.

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Title: [Discussion] What are the advantages of local-first implementation of Plugin System?

🥰 Description of requirements

Now I see the plug-ins in the https://github.com/ChatGPTNextWeb/NextChat-Awesome-Plugins warehouse, all of which are network request types.

Compared with server-side plug-ins, the local system not only needs to set up http proxy separately, but also lacks wider oauth support.

So what are the advantages of local plugin system?

Can it do things that server-side plug-ins cannot?

🧐 Solution

Can you give examples of capabilities in the plug-in repository that server-side plug-ins cannot do?

📝 Supplementary information

No response

[Leizhenpeng]

@lloydzhou

[lloydzhou]

之所以local first，是为了兼容App端，让App端也能和网页端以相同的方式使用Plugin

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

The reason why local first is to be compatible with the App side, so that the App side can use the Plugin in the same way as the web page side.

[lloydzhou]

@Leizhenpeng
另外关于oauth这一点，因为在客户端执行的原因，暂时没有支持

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

In addition, regarding oauth, there is no support for the time being because it is executed on the client side.

[lloydzhou]

@Leizhenpeng

设置http proxy仅仅是因为网页端调用第三方服务的时候，可能导致跨域错误，所以需要当前的server提供一个动态的proxy。
如果在App端，由于使用了原生的http client，反而没有跨域问题

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

@Leizhenpeng

The http proxy is set simply because when the web page calls a third-party service, it may cause cross-domain errors, so the current server needs to provide a dynamic proxy.
If it is on the App side, since the native http client is used, there is no cross-domain problem.

[Leizhenpeng]

我倒不关注oauth和proxy的缺点,我想明白优点在哪, 除了兼容性

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

I don't pay attention to the shortcomings of oauth and proxy. I want to understand the advantages, except compatibility.

[lloydzhou]

纯粹就是为了兼容性：

1. 兼容网页端和App端运行。
2. 兼容系统原有的设计（原来调用LLM API也是在client端发起，而使用function tool功能本身就需要调整原来调用LLM API的逻辑。整个Plugin功能是依赖function tool，自然也就在client端实现）

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Purely for compatibility:

1. Compatible with running on the web and App.
2. Compatible with the original design of the system (originally calling the LLM API is also initiated on the client side, and using the function tool function itself requires adjusting the original logic of calling the LLM API. The entire Plugin function relies on the function tool, and is naturally implemented on the client side )

[Leizhenpeng]

Well, maybe it's a treasure trove where we only see the entrance