开发扩展（Manifest V3）版本

[MotooriKashin]

exe文件天然旧具有不安全感，Windows用户天然就抵触运行来历不明的exe文件，而且本人学习C++实在浅陋，WindowsAPI更是学了点皮毛，虽有精进之心，却没那个精力和能力。
于是我就想既然IDM官方有浏览器扩展文件，我们也可以逆向着写一个，浏览器扩展而已，不像exe那样有病毒之虑。
其实之前就研究过IDM官方扩展与IDM的通信机制，总共三条信道：

1. websocket：这是全双工的网络通信，IDM后台程序有web服务器，扩展访问本地端口来交流信息，这是官方的首选方案。
2. http POST：这是单向web通信，用来发送单条下载数据。
3. Native Message：扩展专属与本机程序通信的机制，类似于websocket。

作为第三方，首选当然是websocket，毕竟在js环境中有开箱即用的支持，唯一的问题是IDM后台web服务器有白名单机制，来自第三方的web请求直接pass（http POST也一样pass）！根本无法建立连接。实际上是通过referer，这在Manifest V3时代通过declarativeNetRequestAPI似乎可以伪装一下解决？没试过🤣
次选方案Native Message，这在扩展环境是也是开箱即用的支持，不过这个也有白名单机制，不过这个白名单判定权在浏览器一方，而不是IDM本身，所以绕过方式非常简单，生成一份伪·白名单覆盖IDM安装目录下的json文件即可。

目前选择还是通过Native Message，扩展负责与IDM建立连接，然后暴露接口到页面上下文中，实现页面js直接拉起IDM进行下载的目的，相比于原exe方案，有以下优势：

1. 无须写入注册表关联，对于讨厌别人乱动注册表的人来说是好事。
2. 可以直接批量下载无须通过ef2文件。
3. 未来或许可以实现主动呼出IDM浮动条。

唯一的劣势是第一次安装需要覆盖白名单，相比写入注册表完全由exe代劳，白名单可得用户自己去放，毕竟每个人IDM安装路径不尽相同——未来或许可以使用批处理（bat文件）处理，双击一下也很快🤣

其实选择扩展，主要还是为了第3点，拉出IDM浮动条，这个浮动条相比直接下载数据强大太多：

1. 可以用来解析m3u8文件，这以往只能靠IDM自己捕获，本地想主动解析都没门！
2. 可以用来自动封装DASH流媒体，再也不用分别下载一条视频轨一条音频轨了！
3. 只要IDM官方浮动条支持的功能，大概都可以主动呼出……

目前虽然有了些进展，但只能通过Manifest V2扩展，因为拉出浮动条的很多参数只有MV2的API才获取的到。如何以MV3的API实现，还是得看IDM官方的扩展样品放出代码，毕竟那些参数究竟有何意义只有IDM官方才知道。
Google已于2022年6月禁止新MV2扩展上架，并将在2023年6月彻底禁止chorme运行MV2扩展，留给IDM的时间已经不多了，所以符合新标准扩展什么时候上架，快点端上来吧IDM🤣

当前进度并未推送上来，毕竟第3点不实现扩展相比于exe优势实在不大，这个feature可能要长期放着了。

[MotooriKashin]

暂时关闭，等待IDM官方的Manifest V3扩展。