期望增加图片WEB直传方式(Expect to add web direct transmission mode)

[byebyehair]

期望增加图片WEB直传方式（疯狂期待）、更改评论的逻辑、更改图片前后缀拼接逻辑为相对地址

Is your feature request related to a problem?

1. 现在图片传输慢，希望能够增加图片WEB直传方式
2. 现在评论也是一条memo，导致使用api获取memo数据时还要判断parent来区分，期望评论逻辑是否可以再斟酌
3. 现在存储的前缀后缀设置后，直接拼接死在external_link字段里，导致使用非常不便，期望拼接功能逻辑可以再斟酌

Describe the solution you'd like

1. 期待直传（非常期望）：
   现在传图的逻辑是经过服务器中转，带宽直接限制了图片传输速度，国内机器带宽是最昂贵的，一般部署memos的机器带宽在3Mbps左右，图片数据流从本地传输至服务器用时太久了，从服务器传输到云存储又要双倍甚至更多的时间，建议能参考阿里OSS和腾讯COS的Web直传方式，参考资料：OSS Web直传最佳实践 ，使用此方式，就可以达到超极速上传，传输完成拿到资源地址回写服务器数据库，同时直传采用预签名的方式也是安全可靠的。
   刚才翻阅issues，发现也有人提出了类似的建议 #2141

2. 期待评论逻辑重新设计：
因为memos本身的前端界面设计适合的场景不多，并且有很多体验可以提升的地方，所以现在更多的人是使用api方式来获取数据，渲染到自己设计的html页面中，但是现在评论功能推出后，很多人页面上突然评论数据也展示成为了一条memos，查看数据库后发现，原来一条memo的评论竟然也是一条memo，通过关联关系捆绑，很不解为何评论的逻辑是这样设计的，人们并不期望评论和memo在是平级关系，更重要的是，这样的设计是否违反了数据库设计范式（一个字段有多重类别含义）？这一点我不太能确定，还是期望大佬能够再斟酌考虑是否有改变设计的必要。

3. 期待图片前后缀不拼接写死在external_link：
现在的存储设置中，可以设置图片URL的前缀和后缀，但是前缀和后缀最后和上传地址一起拼接写死在了external_link字段中，这导致几个问题：
(1)前缀写死的问题：更换图床域名或图床厂商时，除了在数据库执行replace之外无法用其他方式设置，我看有人也提了类似的issue #2419
(2)后缀写死的问题（严重）：
使用云存储的图片动态裁切，例如腾讯云的万象功能可以直接在图片URL后面加参数来放大缩小图片和质量。
如果在memos中添加了URL统一后缀裁切参数[缩小图片质量到15%]，那么在访问memos的时候，所有的图片、包括点击后的放大图，都是15%质量的低质量缩略图片。
而如果不加URL统一裁切参数后缀，那进入memos列表页面会由于大量加载原图而浏览器或手机卡死！
期望达到【缩略图状态使用带后缀的图片地址，点击图片放大查看时，使用不带后缀的原图地址】，所以是否考虑将设置中的URL前缀后缀使用一个单独的字段或json保存起来，在展示数据的时候，动态的去判断是否要追加这些URL前后缀。

------------------我是难过的分界线------------------

我深知开源项目是需要非常谨慎的设计的，也理解开源软件作者各种权衡的不易。
以上只是我在使用过程中比较痛苦的几点，当然最重要的还是第一点图片传输经服务器中转十分缓慢的问题。

无论是否采纳，都期待各位作者加油，能够让memos更加易用和强大，Memos已经是我个人自建微博及笔记，不可或缺的一部分了。

Additional context

No response

[Issues-translate-bot]

Issue is not in English. It has been translated automatically.

---

Title: I hope to add a direct transmission method of pictures via WEB, change the logic of comments, and change the logic of splicing suffixes and suffixes of pictures.

Is your feature request related to a problem?

1. The picture transmission is slow now. I hope to add a WEB direct transmission method for pictures.
2. Now the comment is also a memo, so when using the API to obtain the memo data, it is necessary to judge the parent to distinguish it. I hope the comment logic can be reconsidered.
3. After the stored prefix and suffix are set, they are directly spliced ​​into the external_link field, which makes it very inconvenient to use. We hope that the splicing function logic can be reconsidered.

Describe the solution you'd like

1. Looking forward to direct transmission (very much looking forward to it):
   Now the logic of image transmission is to be transferred through the server, and the bandwidth directly limits the image transmission speed. Domestic machine bandwidth is the most expensive. Generally, the bandwidth of the machine deploying memos is around 3Mbps. It takes too long to transmit the image data stream from the local to the server. It takes double or even more time to transfer from server to cloud storage. It is recommended to refer to the Web direct transmission methods of Alibaba OSS and Tencent COS. Reference: [OSS Web Direct Transmission Best Practices] (https://help.aliyun. com/zh/oss/use-cases/use-postobject-to-upload-objects-by-using-web-clients?spm=5176.8465980.top-nav.5.4e70145072E7nU&scm=20140722.S_help%40%40%E6%96 %87%E6%A1%A3%40%4031923.S_RQW%40ag0%2BBB2%40ag0%2BBB1%40ag0%2Bhot%2Bos0.ID_31923-RL_web%E7%9B%B4%E4%BC%A0-LOC_consoleUNDhelp -OR_ser-V_3-P0_0)

2. Looking forward to redesigning the comment logic:
   Because the front-end interface design of memos itself is not suitable for many scenarios, and there are many areas where the experience can be improved, more people now use API methods to obtain data and render it into HTML pages designed by themselves, but now the comment function is launched Later, many people's pages inexplicably displayed the comment data as a memo. After checking the database, it was found that the original comment of a memo was also a memo, tied through an association relationship. It was very confusing why the logic of the comments was designed in this way. People did not We don’t expect comments and memos to have a horizontal relationship. More importantly, does such a design violate the database design paradigm? I'm not sure, but I still hope that the boss can reconsider whether it is necessary to change the design.

3. Expect the image suffix and suffix to be written in external_link without splicing:
   In the current storage settings, you can set the prefix and suffix of the image URL, but the prefix and suffix are finally concatenated with the upload address and written into the external_link field, which leads to several problems:
   (1) When using multiple domain names at the same time, pictures may be accidentally blocked.
   (2) When using cloud-stored pictures to dynamically crop, such as Tencent Cloud’s Vientiane function, in memos, both thumbnails and enlarged pictures are added with a crop suffix, which cannot achieve [thumbnail status using the The image address of the suffix. When clicking on the image to enlarge it, use the original image address without the suffix]
   So consider saving the URL prefix and suffix in the settings in a separate field or json, and dynamically determine whether to append these URL suffixes when displaying the data.

---I am the dividing line of sadness---

I know that open source projects require very careful design, and I also understand the various trade-offs that open source software authors face.
The above are just a few of the more painful points during my use. Of course, the most important thing is the first problem of image transmission being transferred through the server too slowly.

Regardless of whether it is adopted or not, I hope all authors will work hard to make memos more easy to use and powerful. Memos is already an indispensable part of my personal Weibo and notes.

Additional context

No response

[Irvingouj]

To implement this feature, an S3 Bucket is necessary.
Do Alibaba Cloud or Tencent Cloud have S3 compatiable OSS?
Our strategy should be to initially support a basic, self-hostable S3-compatible object storage service as our primary OSS. From there, we can expand and include more services based on their compatibility and our requirements.

We may use a driver like we do with database

@boojack

[byebyehair]

@Irvingouj

---

阿里云的OSS和腾讯云的COS都是兼容S3的云存储，也是目前使用最广泛的云存储之一。
Web端直传，主要就是希望实现OSS（兼容S3）或COS（兼容S3）的直传，当用户使用S3或兼容S3的云存储时，图片等资源的数据流没有必要经过服务器中转，因为这代价昂贵且效率低。
现在的Memos使用S3的模式是「UserDevice -> Memos Server -> S3 Cloud」
期望的Memos使用S3的模式是「UserDevice -> S3 Cloud -> Resource URL write to Memos Server Database」

---

Alibaba Cloud's OSS and Tencent Cloud's COS are both S3 compatible cloud storage and are among the most widely used cloud storage at present.
Web side direct transmission, the main hope is to achieve OSS (compatible with S3) or COS (compatible with S3) direct transmission, when users use S3 or compatible with S3 cloud storage, the data flow of resources such as images do not need to pass through the server, because it is expensive and inefficient.
The current Memos use S3 mode is "UserDevice -> Memos Server -> S3 Cloud".
The expected pattern for Memos to use S3 is "UserDevice -> S3 Cloud -> Resource URL write to Memos Server Database".

---

期待！

[Irvingouj]

let me know if this is the good feature, I can support this for AWS s3 and MinIo.

@boojack

[Irvingouj]

@Irvingouj

阿里云的OSS和腾讯云的COS都是兼容S3的云存储，也是目前使用最广泛的云存储之一。 Web端直传，主要就是希望实现OSS（兼容S3）或COS（兼容S3）的直传，当用户使用S3或兼容S3的云存储时，图片等资源的数据流没有必要经过服务器中转，因为这代价昂贵且效率低。 现在的Memos使用S3的模式是「UserDevice -> Memos Server -> S3 Cloud」 期望的Memos使用S3的模式是「UserDevice -> S3 Cloud -> Resource URL write to Memos Server Database」

Alibaba Cloud's OSS and Tencent Cloud's COS are both S3 compatible cloud storage and are among the most widely used cloud storage at present. Web side direct transmission, the main hope is to achieve OSS (compatible with S3) or COS (compatible with S3) direct transmission, when users use S3 or compatible with S3 cloud storage, the data flow of resources such as images do not need to pass through the server, because it is expensive and inefficient. The current Memos use S3 mode is "UserDevice -> Memos Server -> S3 Cloud". The expected pattern for Memos to use S3 is "UserDevice -> S3 Cloud -> Resource URL write to Memos Server Database".

期待！

If @boojack thinks this is worth doing, I'll take it, you might need to create a sperate PR for support Ali Cloud or Tencent Cloud if default AWS implementation now working for you.

[github-actions]

This issue is stale because it has been open 14 days with no activity.

[github-actions]

This issue was closed because it has been stalled for 28 days with no activity.