Ente 相册协作完全指南:共享相册协作模式与公开收集链接的权限模型、存储计费与实战配置
2026/9/12 16:44:53 网站建设 项目流程

Ente 相册协作完全指南:共享相册协作模式与公开收集链接的权限模型、存储计费与实战配置

【免费下载链接】ente💚 End-to-end encrypted cloud for everything.项目地址: https://gitcode.com/GitHub_Trending/en/ente

Ente 提供两种互补的相册协作方式:面向 Ente 用户的协作共享相册(Collaborative Albums,基于邮箱邀请与 Viewer / Collaborator / Admin / Owner 四级角色体系),以及面向非 Ente 用户的照片收集链接(Collect Links,公开链接 + "允许添加照片"能力,无需账号即可用浏览器投稿)。本指南以官方文档 collaboration.md 为主体,结合服务端源码、移动端实现与存储优化文档,完整讲解两种模式的权限边界、存储计费规则、删除建议(Suggest Deletion)工作流、收集链接的保护与限额配置,帮助你根据场景选对协作方案。

一、两种协作方式总览

Ente 的协作能力分为两条路径,适用场景截然不同:

维度协作共享相册(Collaborative Albums)照片收集链接(Collect Links)
参与者是否需要 Ente 账号是(通过邮箱邀请)否(任何有链接的人)
访问方式邮箱邀请公开链接
存储计费方各自上传者相册所有者
适用场景与 Ente 用户长期共建相册面向大批人群的一次性照片收集
平台支持移动端、Web、桌面端所有平台(通过 Web 浏览器)
可否设置上传/访问限额否(基于信任)是(密码、有效期、设备数限制)

简言之:协作共享相册解决"家人朋友都在 Ente 上"的持续共建需求;收集链接解决"婚礼、聚会、旅行、会议等场景下收集一大群不常用 Ente 的人的照片"的需求。

二、协作共享相册:基于角色权限的多人共建

2.1 核心角色模型

协作共享相册围绕四个角色组织,在服务端源码 access.go 中以CollectionParticipantRole枚举定义:

  • 相册所有者(Owner):创建相册的人
  • 参与者(Participants):通过邮箱地址添加,必须拥有 Ente 账号
  • 权限(Permissions):所有者可为参与者分配 Viewer、Collaborator 或 Admin 角色
  • 存储(Storage):每张照片的存储计入其上传者名下

从源码看,服务端通过roleRank()(access.go)对角色排序:VIEWER(1) < COLLABORATOR(2) < ADMIN(3) < OWNER(4),并用Satisfies(min)判断某角色是否满足最低要求,用于权限校验。其中两个关键能力谓词体现了权限边界:

  • CanAdd()(access.go):仅 OWNER、COLLABORATOR、ADMIN 可以添加照片,VIEWER 无权添加
  • CanRemoveAny()(access.go):仅 OWNER 可以移除任意照片,这也与文档中"Admins 不能永久删除他人上传的照片"的规则呼应。

2.2 邀请参与者的操作步骤

在移动端或 Web/桌面端,添加参与者的流程一致:

  1. 打开要分享的相册
  2. 点击/轻触分享(Share)图标
  3. 选择"与 Ente 用户共享"(Share with Ente users)或直接输入邮箱地址
  4. 选择权限(Viewer、Collaborator 或 Admin)
  5. 发送邀请

被邀请方会收到通知,并在其 Ente 应用中访问该共享相册。支持多选相册:长按进入多选模式后,选择"分享"会将同一套分享设置一次性应用到所有选中的相册。

从服务端实现看,分享请求最终落在 share.go 的shareCollectionWithUserID:服务端会校验不能分享给自己(validateBulkShareRecipient),并调用AllowParticipantSharing校验相册类型是否允许以该角色分享,随后写入Share/ShareAutomatically记录。被分享的相册密钥以加密形式(EncryptedKey)传递,延续了端到端加密的链路。

2.3 三级参与者权限详解

Viewer(查看者)可以:

  • 查看相册内所有照片
  • 下载照片
  • 将照片添加到自己的相册(此时会创建一份副本)
  • 评论与表情回应

Collaborator(协作者)可以:

  • 拥有 Viewer 的全部能力,此外:
  • 向共享相册添加新照片和视频
  • 移除自己上传的照片

Admin(管理员)可以:

  • 拥有 Collaborator 的全部能力,此外:
  • 移除相册中的任意照片(包括他人上传的)
  • 添加或移除参与者(可设为 Admin、Collaborator 或 Viewer 角色)
  • 对他人的照片发起删除建议(Suggest Deletion)

Admin 不可以:

  • 管理链接设置(密码、有效期、设备数限制)
  • 删除整个相册
  • 永久删除非自己拥有的照片

相册所有者(Owner)可以:

  • 拥有 Admin 的全部能力,此外:
  • 管理链接设置
  • 删除整个相册

这里值得强调的是权限的"阶乘式"关系:Owner 是唯一拥有CanRemoveAny()能力的角色;Admin 虽然能移除任意照片,但无法永久删除他人上传的照片(仅能将之从相册中移除,所有权仍归上传者);Viewer 是最纯粹的角色,CanAdd()直接返回 false,从服务端层面就杜绝了其上传行为。

2.4 何时使用 Admin 角色

Admin 适合被信任的、帮助管理共享相册的参与者:

  • 家庭相册:被信任的家庭成员帮助筛选与整理照片
  • 集体旅行相册:某人负责在旅行结束后筛掉重复或模糊的照片
  • 活动相册:婚礼、派对或聚会中的共同组织者协助管理照片

而对于只需"添加和查看照片、无管理职责"的参与者,应使用 Collaborator 角色。

2.5 协作相册中的存储计费

协作共享相册的存储规则非常明确:

  • 协作者添加的照片计入协作者本人的存储配额
  • 由于协作者通常在自己的账号里已保留该照片,因此实际不会产生额外开销
  • 相册所有者不需要为协作者上传的照片付费
  • 同一张照片即使出现在多个相册中,存储只计一次

这与 share.md 中关于"整理共享内容"的说明一致:当你把共享照片收藏或归入自己的相册时,Ente 会创建一份你完全拥有的硬副本,该副本计入你的存储空间——这是为了避免原主删除照片后共享内容的归属歧义而采取的保守设计。

2.6 参与者退出/被移除时的处理

当参与者被移出共享相册(或主动退出)时:

  • 他们上传的任何照片也会从相册中移除
  • 这些照片仍保留在参与者自己的账号中(所有权不变)
  • 其他参与者上传的照片继续保留在相册中
  • 被移除的参与者将失去查看该相册的权限

三、删除建议(Suggest Deletion):端到端的策展工作流

删除建议是协作相册中独有的策展机制,仅相册所有者与 Admin 可用,用于在集体旅行或活动后整理相册。

3.1 发起删除建议

  1. 打开一个你是所有者或 Admin 的共享相册
  2. 选择由其他参与者上传的照片
  3. 点击"建议删除"(Suggest Deletion)操作
  4. 确认建议

发起后会发生两件事:

  • 照片立即从相册中移除
  • 照片所有者会在其"删除建议"队列(Delete Suggestions queue)中收到该建议

照片所有者可逐条接受(删除)或拒绝(保留)。

3.2 在移动端处理删除建议

照片所有者可在Settings > Backup > Free up space > Delete suggestions(设置 > 备份 > 释放空间 > 删除建议)中查看并处理建议。对于每条建议:

  • 接受(Accept):将照片移入回收站(Trash),可在 30 天内恢复
  • 拒绝(Reject):保留照片并消除该建议

[!NOTE]

删除建议功能目前仅在移动端可用。

从移动端源码看,该功能由 collections_service.dart 的suggestDeleteFromCollection驱动:先通过collectionFilesGateway.suggestDelete(collectionID, fileIDs)调用服务端接口,随后将文件从本地相册索引中移除(_filesDB.removeFromCollection),并触发CollectionUpdatedEventLocalPhotosUpdatedEvent刷新界面。对应地,处理删除建议的独立页面为 delete_suggestions_page.dart,入口位于"释放空间"设置项 free_space_options.dart。

关于"为什么建议删除后照片立即从相册消失、但需要我确认才真正删除"的设计逻辑,官方在 storage-optimization.md 中进一步解释:删除建议是他人发起的建议而非强制操作,最终决定权始终在照片所有者手中;即便你拒绝建议,照片也不会自动回到共享相册,仍需由你主动重新添加。

四、照片收集链接:让没有 Ente 账号的人也能投稿

4.1 什么是收集链接

收集链接就是启用了"允许添加照片"(Allow adding photos)选项的公开链接。任何拿到链接的人都可以在浏览器中查看现有照片并上传自己的照片——无需 Ente 账号,也无需安装应用

典型使用场景:

  • 收集婚礼宾客的照片
  • 生日派对回忆
  • 度假旅行照片
  • 会议或活动照片
  • 任何希望从群体中收集照片的聚会

4.2 创建收集链接

移动端:

  1. 打开用于收集照片的相册
  2. 点击右上角分享图标
  3. 选择"收集照片:创建协作链接"(Collect photos: Create collaborative link)
  4. 点击"复制链接"
  5. 将链接分享给想收集照片的人

Web/桌面端:

  1. 打开相册
  2. 点击分享相册图标
  3. 选择"收集照片"(Collect photos)
  4. 点击"复制链接"
  5. 分享给他人

拿到链接的人即可在浏览器中查看现有照片并添加自己的照片;如果你未禁用下载,他们还可以下载照片。

如果此前已为该相册启用过公开链接,可通过"管理链接"(Manage link)> 启用"允许添加照片",直接将其转变为收集链接。

4.3 收集照片的存储归属

通过收集链接添加到相册的所有照片,都计入相册所有者的存储配额。当有人通过收集链接添加照片时:

  • 照片存储在你的账号中
  • 你可以像处理其他照片一样查看、下载和管理它
  • 你可以随时移除已收集的照片
  • 投稿者上传后无法删除照片

从服务端源码可以印证这一归属逻辑:collection_link.go 的CreateFile明确将新文件的OwnerID强制设为collectionOwnerID(相册所有者),file.ID = 0表示"公开链接不允许更新文件"。这与协作共享相册"各自计费"形成鲜明对比。

4.4 保护与限制收集链接

你可以为收集链接设置以下保护与限制:

  • 密码保护(Password protection):访问链接需输入密码
  • 链接有效期(Link expiry):设置链接停止生效的时间
  • 设备数限制(Device limits):限制可访问链接的设备数量——服务端以"IP 地址 + 浏览器/应用组合"来标识一台设备(源码注释见 collection_link.go)
  • 禁用下载(Disable downloads):阻止他人下载原始质量照片
  • 禁用上传(Disable uploads):关闭"允许添加照片"将其变为纯查看链接

停止收集照片的三种方式:

  1. 移除链接:在分享设置中删除该公开链接
  2. 禁用上传:编辑链接设置,关闭"允许添加照片"
  3. 改为仅查看:将收集链接转换为普通公开链接

4.5 设备数限制的服务端实现细节

设备数限制并非简单的"每链接 N 台设备"计数,服务端实现包含多个值得注意的细节(见 collection_link.go 与 collection_link.go):

  • 免费用户设备数上限为 10(FreeUserDeviceLimit = 10),超出该值的请求会被capFreeUserDeviceLimit钳制;
  • 设备限额存在阈值机制:DeviceLimitThreshold = 50,当设置的设备限额等于 50 时,实际按50 × 10 = 500计(DeviceLimitThresholdMultiplier = 10);
  • 设备判定在中间件checkDeviceLimit中进行,同时会在内存缓存中记录"该设备曾访问过该链接"(基于 IP + User-Agent 的组合键),后续访问不再重复计入;
  • 设备数达到阈值时返回ErrLinkDeviceLimitExceeded(HTTP 错误)拒绝访问,并伴有告警日志(DeviceLimitWarningThreshold = 2000,每 200 次计数输出一次)。

免费套餐的设备数限制为 10,付费用户则无设备数限制(参见 share.md 的 Limitations 一节)。

4.6 收集链接的投稿者归属现状

当前无法查看谁通过收集链接添加了哪些照片——所有收集的照片在相册中不显示投稿者归属。官方表示正根据用户反馈考虑加入该功能。这是选择收集链接方案时需要知晓的一个限制。

五、两种方案的对比与选型建议

特性协作共享相册收集链接
参与者需要 Ente 账号
访问方式邮箱邀请链接
存储由谁承担各自上传者相册所有者
最适合场景与 Ente 用户长期协作向大批人群一次性收集照片
平台支持移动端、Web、桌面端所有平台(通过 Web 浏览器)
能否设置上传限制否(基于信任)是(密码、有效期、设备数)

选型建议:如果协作方都已注册 Ente,优先使用协作共享相册——存储各自承担、权限粒度细、支持删除建议策展;如果要面向不熟悉 Ente 的大众收集活动照片,使用收集链接——门槛低、可设密码与有效期,但要清楚存储由你承担、且目前无法识别投稿者。

六、深入阅读

本文是 Ente Photos 分享与协作主题的一部分,官方文档体系提供了更多关联内容:

  • 分享总览 —— 所有分享方式、端到端加密说明与免费/付费套餐限制
  • 公开链接 —— 通过链接分享相册(含快速链接与收集模式)
  • 库共享 —— 与家人共享当前及未来相册
  • 评论与点赞 —— 共享相册内的互动能力
  • 自定义域名 —— 为链接使用自有域名
  • 存储优化指南 —— 含"删除建议"的处理流程详解

如果你想从代码层面验证本文中的权限模型与存储归属逻辑,可直接查阅:

  • 服务端角色枚举与能力谓词:access.go
  • 服务端批量分享校验与落库:share.go
  • 收集链接创建与文件归属:collection_link.go
  • 设备数限制中间件:collection_link.go
  • 移动端删除建议入口与处理:collections_service.dart、delete_suggestions_page.dart

相关 FAQ 可参考官方文档索引(见 collaboration.md 底部的 Related FAQs 清单),覆盖"Admin 在共享相册中能做什么""Admin 与 Collaborator 的区别""谁为协作相册的存储买单""收集照片是否计入我的存储"等高频问题。

【免费下载链接】ente💚 End-to-end encrypted cloud for everything.项目地址: https://gitcode.com/GitHub_Trending/en/ente

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询