这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 105 天前的主题，其中的信息可能已经有所发展或是发生改变。
在博客、论坛的各种环境，经常需要图床用于保存和分享图片，但是很多付费和免费的图床都有一个问题，可能比较长时间后（也有可能短时间），图床网站不在了……
一般来讲，每个图床网站同一个图片会生成不同的链接，导致一个图床挂了，就会让所有链接失效，而且只能新上传到一个图床，所有老链接只能手动一个一个修改。
为了解决这个问题，ipfs 图床 使用的了 ipfs 的技术，同一张图片每次上传的文件链接都一样的，然后通过 p2p 技术，一张图片链接可以通过多个网站同时打开。
原理
每个图片上传后，会根据图片文件生成固定的一个哈希，这个哈希规则是通用的。然后通过这个哈希值，可以在全球几百个的网站访问这种图片，如果其中一个网站挂了，更换一下图片链接就马上打开了。
一个图片被多个网站打开后，图片就被复制更多份，让图片的可靠率更高。
使用方法
在线网站
打开ipfs 图床 ，然后上传图片获取图片链接地址。
客户端上传
下载 ipfs-desktop 客户端，在客户端里面上传图片，然后获取图片地址，然后修改图片的域名。
这个方法有一个好处，始终保证你自己掌握一份图片备份，然后通过 p2p 技术，其它网站就可以随时打开这张图片。
如果你追求你的图片 100%可靠性，就需要使用这种方式。
优势
- 通过这种方式上传的图片，都不会被压缩，也不会被打码，100%原图。
- 不会因为网站停止运行导致图片丢失。
- 不会因为审核导致图片丢失。
- 图片看的人越多，图片被复制到的节点越多，越可靠。
62 条回复 • 2024-09-12 17:25:13 +08:00
 |
1
andforce 105 天前
|
 |
2
lizhenda 105 天前  1
我好奇的是为啥原文网站头部的 logo 图裂了？这对宣传可信度严重打击啊
|
 |
3
chenjia404 OP @lizhenda #2 因为没有配置 logo ，想不到配置什么比较合适的。
|
 |
4
yb2313 104 天前
我试试, 不好用, v 这里都不能加载出图片来
![图片][https://gateway.ipfsscan.io/ipfs/QmNr8Ffhb7GbtPE2YVsK8MAeULyuKd71W9JMdhnYgxA3qm?filename=CqGDDDoavo.png] |
 |
5
OWLS 104 天前
愿长久。
|
 |
7
Livid MOD 1
@yb2313 我在考虑可能会支持这种 CIDv0?filename= 的新语法。
因为这种方式的一个优雅之处就是，前面的 gateway prefix 是可以随便换的，只需要用正则把后面的 CIDv0?filename= 这部分提取出来。 比如这些地址都可以访问到同一个文件： https://gateway.ipfsscan.io/ipfs/QmNr8Ffhb7GbtPE2YVsK8MAeULyuKd71W9JMdhnYgxA3qm?filename=CqGDDDoavo.png https://magic.decentralized-content.com/ipfs/QmNr8Ffhb7GbtPE2YVsK8MAeULyuKd71W9JMdhnYgxA3qm?filename=CqGDDDoavo.png |
|
8
Livid MOD 另外，如果把 CIDv0 转换成 CIDv1 （以上面出现的那个 CIDv0 为例），那么还可以用这个 Limo Gateway：
 https://bafybeiahrt6nz6j2ksvf2tbhrv3iv54entu3jzzll2ekgelhxvg45ikmzq.ipfs2.eth.limo/ |
|
9
Livid MOD |
|
10
Livid MOD |
|
11
Livid MOD |
|
12
Livid MOD 只要 CID 存在于某个节点上，就肯定可以从某个 gateway 上掏出来。
解决可靠性问题的一个方式就是从前端实现图片加载地址不要强依赖于某个特定的 gateway 。 比如可以用 web component 实现一个 <cidimg src="bafybeiahrt6nz6j2ksvf2tbhrv3iv54entu3jzzll2ekgelhxvg45ikmzq" /> 然后这个 component 到底用哪个 gateway ，可以去读一个外部配置。 |
 |
13
Tink 101 天前
主要是，能否通过 http 协议访问到，又一定程度上依赖于 gateway ，这个 gateway 是不可控的
|
|
16
Livid MOD |
|
18
Livid MOD |
 |
20
admol 101 天前
看回复，我还以为是站长在发帖
 |
 |
21
gbadge 101 天前
|
|
22
gbadge 101 天前 1
不好意思，楼上的链接衔接没处理好，重发一遍，支持 ipfs
一直认为 ipfs 是一项很好的技术，这个网站有更多的 pin 服务： https://ipfs-shipyard.github.io/pinning-service-compliance/ 防止以后的人们看不到，所以另附网页存档： （ 1 ） https://archive.ph/gIaKL （ 2 ） https://web.archive.org/web/20240705152256/https://ipfs-shipyard.github.io/pinning-service-compliance/ |
 |
23
cnrting 101 天前 via iPhone
可 ipfs 真的真的很慢很慢
|
 |
24
CSGO 101 天前
第一次了解到这个 ipfs ，是不是理解就是你的服务器现做了图床，然后如果正好有人也装了 ipfs 客户端，那么打开这个图，会被缓存，然后在缓存被清空前，且正好在线，那么它也就成为节点？
|
 |
25
h404bi 101 天前 1
「 100%可靠性」其实是对 ipfs 有些误解，ipfs 存在着与 BitTorrent 同样的 p2p 局限。所谓「 100%可靠性」只对资源生产者而言（除非自己删掉了最后一份备份），在消费端非热门资源的可访问性一直不太行，很多情况下访问一个 cid 就卡在那里了很长一段时间（梦回 BitTorrent 挂着很长时间找寻 peer ），极大消耗耐心。
尤其是个人博客图片，绝大多数都是非常冷门低访问量的资源，这种劣势会被放大。这时候提高可靠性，无非就是让消费端访问固定一个 gateway （背后是生产者自己/代理的 Pinning ，消灭掉寻址过程），这样又回到了自托管/代托管方式。使用 ipfs ，只是多了一个广播到网络上其它 peers 的功能。对于博客图片这样的场景，换来的可能是比用传统图床更差的用户体验（尝试 gateways 的 overhead ）。 把 https://gateway.ipfsscan.io/ipfs/QmNr8Ffhb7GbtPE2YVsK8MAeULyuKd71W9JMdhnYgxA3qm 换成 ipfs://QmNr8Ffhb7GbtPE2YVsK8MAeULyuKd71W9JMdhnYgxA3qm 让 IPFS Companion 去挑 gateway 立马就能体验到这个 overhead IPFS 很好，但就这个使用场景而言，我觉得 IPFS 是不如传统图床甚至于 Arweave 的。 |
 |
26
liudon 101 天前
还得保证这个文件有被 pin 吧？不然节点的缓存过一段时间就没了
我的 ipfs 站点 https://liudon.eth.limo ，我现在是在 vps 和 filebase 各 pin 了一份数据，保证文件可以访问到 |
|
27
Livid MOD @liudon 如果一个 CID 持续被从不同的 gateway 上访问，其实就是在每个 gateway 的 IPFS repo 里都存了一份。不一定永久，但很多情况下其实够用了。
|
|
28
Livid MOD 1
这种一个地方上传，然后可以从无数个其他地方拿到的感觉，真的太好玩了。
比如这是 Planet 的轻量级版本 Croptop ，我把图片拖拽进去，就可以加入到本地的 IPFS repo ，然后这个 CID 又可以从楼主的 gateway 里拿到：  https://gateway.ipfsscan.io/ipfs/QmfLTaFU17G4GqfdcQLk4XJ163wkyejzrnPZkXmB35DVgU |
|
29
Livid MOD 中长期可能会面临的一个问题是如果单个节点的 repo 里的 CID 数量到达 1e5~1e6 之间的时候，IPFS 的 reprovide 可能会出问题。
|
 |
30
ochatokori 101 天前 via Android 1
我的博客就是内容只存图片后缀，前端在列表中找可用的前缀
|
|
31
chenjia404 OP 1
@Livid #28 我的节点都有几百万的对象以上，我保存了一份维基百科的最新镜像，目前来看没有发现影响性能。
|
|
32
Livid MOD @chenjia404 之前有人基于 IPFS MFS 来做 Linux 包镜像，遇到过一些问题。
https://github.com/ipfs/notes/issues/296#issuecomment-707912467 |
|
33
chenjia404 OP 1
@Livid #32 看日期是 2020 年的，最新版应该解决了，这个 cid 里面有几百万个文件 bafybeichypzjch6uuo5pe6btkctcusdwvp77xidgbh5kc2ipowvuaexhiq
|
 |
34
qweruiop 101 天前
不知道有啥方法可以保障 1 年之后数据不丢失不。。。
|
 |
35
jackkkie 101 天前
所以为啥不部署个 minio ？
|
 |
36
crz 101 天前
还是依赖 ipfsscan.io 这个域名吧
|
|
37
chenjia404 OP @crz #36 这个域名也可以随时换，路径是一样的，随时都可以搭建一个新的网站出来，老的图片一样访问。
|
|
38
crz 101 天前
@chenjia404 博客好说，但是博客对图床的依赖相对有限
类似论坛的环境，要一个个帖子编辑过去吗，像是 v2 ，直接编辑不了 |
|
39
chenjia404 OP @crz #38 对，有这个问题，论坛可以解析路径，另外可以用自动跳转的网关，网关不保存图片，但是会自动跳转到最新可用的网关。
我这个域名默认的网关就是跳转网关。 |
 |
40
wogogoing 101 天前 via iPhone
路过的来瞅瞅我的呗：
https://www.v2ex.com/t/1071339#reply23 |
 |
41
cue 101 天前
自建 lsky pro + cloudflare R2
|
 |
42
kitty7030 101 天前
怎么没人说网速的问题
图片无法审核的话 就不会有国内网关了吧 |
 |
44
mayli 101 天前
@chenjia404 随机出错的体验不大好 ("Gateway time-out Error code 504")
而且 CF 也下线了他的 gateway： https://blog.cloudflare.com/cloudflares-public-ipfs-gateways-and-supporting-interplanetary-shipyard 这个页面上有个图就加载不出来 https://gateway.ipfsscan.io/ipfs/bafybeichypzjch6uuo5pe6btkctcusdwvp77xidgbh5kc2ipowvuaexhiq/wiki/ https://gateway.ipfsscan.io/ipfs/bafybeichypzjch6uuo5pe6btkctcusdwvp77xidgbh5kc2ipowvuaexhiq/I/W-circle.svg.png.webp 而且好多链接都是半天打不开，然后超时之后报错。 |
|
45
mayli 101 天前
|
|
46
chenjia404 OP @mayli #44 这个网关遇到了一些问题，现在修复了
|
 |
47
xuanwu 100 天前
以后应该有越来越多代码动态生成图片的工具，如 https://github.com/zengm-games/facesjs
|
 |
48
zoharSoul 100 天前
支持 api 上传吗
|
|
49
mayli 100 天前
@chenjia404 但是随便点一个链接等半天的体验有点差
|
|
50
chenjia404 OP @mayli #49 维基这个有点特殊，里面几百万个对象，加上这个网关随机每次从 300 个节点里面选取一个，你换一个，一般图片来讲就好很多。
这个网关的速度就快很多 https://ipfs.blockframe.io/ipfs/bafybeichypzjch6uuo5pe6btkctcusdwvp77xidgbh5kc2ipowvuaexhiq/wiki/ 。 |
 |
51
nicoljiang 100 天前
如果直接回答，那肯定是“你预备足够的钱，养你自己的图床”。
|
|
52
qweruiop 100 天前
不知道，是否可以自己实现
1 ，通过某个 api 或者某种方法查看自己某个资源的存活时间。 2 ，在快过期之前，调用某个 pin service 保活。。。 |
 |
54
gochendong 100 天前
ipfs rapid api https://rapidapi.com/gochendong/api/ipfs-interplanetary-file-system
 网关查看 https://ipfs.github.io/public-gateway-checker/ 拼接上返回的 cid 就行 |
|
55
qweruiop 100 天前
@img2ipfs 老哥请教下，我看网上很多地方说只能存 1 年，但是，貌似，也不能真正的确认某个对象的生命周期还剩多少天。。。那如果，自己写个业务，每天都去刷，这样，资源还会被清理吗？
|
 |
58
iqoo 99 天前
充分利用图床
网站图片很耗流量，不少人将图片上传到图床、相册等第三方站点，充当免费 CDN 。但这也存在诸多难以预测的情况，例如图片被删、限制外链、添加水印、有损压缩、限速等等。 这导致很多人认为免费图床不可靠。事实上，不可靠的不是质量，而是数量！你把所有图片都放在单个图床上，这显然有很大的风险。但如果有多个图床，它们同时出现故障的可能性就呈指数级下降了。 因此，你可以像上述公共库那样，将图片也进行冗余处理，每个图片准备多个 URL ，从而实现一个高度稳定的分布式图床。 ... https://github.com/EtherDream/freecdn/blob/master/docs/feature/README.md#%E5%85%85%E5%88%86%E5%88%A9%E7%94%A8%E5%9B%BE%E5%BA%8A |
Select Language