Hotdry.
归档
systems

社交文件系统的活动访问控制层与协作元数据系统设计

面向AT协议社交文件系统，设计基于活动的访问控制层与实时协作元数据系统，实现细粒度权限管理与多用户协作状态同步。

问题背景：社交文件系统需要动态权限与实时协作

传统的社交应用将用户数据锁在应用内部，权限管理基于简单的角色（RBAC）或访问控制列表（ACL）。然而，随着 AT 协议社交文件系统的兴起，用户数据从应用中分离出来，存储在分布式的 repository 中，每个用户拥有自己的 "everything folder"。这种架构带来了新的挑战：如何在不依赖中心化应用的情况下，实现细粒度的、基于上下文的访问控制？如何在多用户协作编辑同一文档时，实时同步协作状态和元数据？

社交文件系统基于 AT 协议，将用户数据与应用分离，每个用户有 repository 包含 collections 和 records。at:// URI 作为永久链接，DID 作为永久身份标识，支持用户迁移而不破坏链接。应用是反应式的，从 repository 读取数据，可以构建本地缓存和派生数据。在这种分布式架构下，传统的静态权限模型已不再适用。

设计基于活动的访问控制层

1. 属性定义与分类

基于活动的访问控制（Activity-Based Access Control, ABAC）使用用户、资源、环境属性动态决定权限，比传统 RBAC 更灵活。在社交文件系统上下文中，我们需要定义三类核心属性：

用户属性：

  • user.did: 用户的永久身份标识
  • user.handle: 当前已验证的域名句柄
  • user.role: 在特定上下文中的角色（如文档所有者、协作者、评论者）
  • user.trust_score: 基于历史行为的信任评分
  • user.location: 访问时的地理位置（用于合规性检查）

资源属性：

  • resource.type: 记录类型（如app.bsky.feed.post、com.github.document）
  • resource.collection: 所属集合
  • resource.sensitivity: 数据敏感度等级（公开、内部、机密）
  • resource.collaboration_mode: 协作模式（只读、评论、编辑）
  • resource.parent_ref: 父资源引用（用于继承权限）

环境属性：

  • env.time: 访问时间（支持时间窗口限制）
  • env.device_type: 设备类型（移动端、桌面端）
  • env.network_security: 网络安全性（VPN、公共 Wi-Fi）
  • env.session_duration: 会话持续时间（用于会话超时）

2. 策略引擎设计

策略引擎需要支持复杂的布尔逻辑和实时评估。策略采用 JSON 格式定义，便于序列化和分发：

{
  "policy_id": "doc-edit-policy-001",
  "description": "文档编辑权限策略",
  "effect": "ALLOW",
  "conditions": [
    {
      "operator": "AND",
      "rules": [
        {
          "attribute": "user.role",
          "operator": "IN",
          "value": ["owner", "editor"]
        },
        {
          "attribute": "resource.collaboration_mode",
          "operator": "EQ",
          "value": "edit"
        },
        {
          "attribute": "env.time",
          "operator": "BETWEEN",
          "value": ["09:00", "18:00"]
        }
      ]
    }
  ],
  "actions": ["read", "write", "share"],
  "priority": 100
}

策略评估流程：

  1. 属性收集器：从 DID 解析服务、用户 repository、环境传感器收集实时属性
  2. 策略匹配器：根据资源类型和上下文选择相关策略
  3. 条件评估器：使用 Rete 算法或类似优化算法评估复杂条件
  4. 冲突解决器：当多个策略冲突时，按优先级和特异性解决
  5. 决策缓存：对频繁请求的(用户, 资源, 动作)三元组缓存决策结果

3. 实时评估与性能优化

ABAC 策略复杂度高，策略评估性能可能成为瓶颈。需要以下优化措施：

性能参数：

  • 策略评估延迟：< 50ms（P95）
  • 缓存命中率：> 85%
  • 并发评估能力：> 1000 QPS
  • 策略更新传播延迟：< 5 秒

缓存策略：

  • 短期缓存：内存缓存，TTL=5 分钟，基于 LRU 淘汰
  • 长期缓存：分布式 Redis，TTL=1 小时，基于访问模式预热
  • 失效机制：属性变更时主动失效相关缓存条目

评估引擎选择：

  • 轻量级场景：使用@casbin/abac或OPA（Open Policy Agent）
  • 高性能场景：自定义 Rete 算法引擎，支持规则编译为 WASM
  • 边缘计算：策略引擎可部署在用户端，减少网络往返

构建协作元数据系统

1. CRDT 同步架构

协作元数据系统需要实时同步和冲突解决，CRDT 如 Yjs 提供无冲突合并能力。在社交文件系统中，协作元数据包括：

核心元数据类型：

  • 光标位置：用户在文档中的实时位置
  • 选择范围：文本或对象的选择状态
  • 编辑状态：正在编辑的段落或组件
  • 评论线程：实时评论和回复
  • 版本历史：协作编辑的时间线

CRDT 选择标准：

  • 操作型 CRDT：适合细粒度操作（如字符级编辑）
  • 状态型 CRDT：适合粗粒度状态（如文档属性）
  • 混合型：根据数据类型选择合适 CRDT

Yjs 集成架构：

// 协作元数据管理示例
class CollaborationMetadata {
  constructor(did, resourceUri) {
    this.ydoc = new Y.Doc();
    this.awareness = new awarenessProtocol.Awareness(this.ydoc);
    
    // 定义共享数据类型
    this.cursors = this.ydoc.getMap('cursors');
    this.selections = this.ydoc.getMap('selections');
    this.comments = this.ydoc.getArray('comments');
    
    // 设置用户身份
    this.awareness.setLocalStateField('user', {
      did: did,
      name: await resolveHandle(did),
      color: this.generateUserColor(did)
    });
  }
  
  // 同步到社交文件系统
  async syncToRepository() {
    const update = Y.encodeStateAsUpdate(this.ydoc);
    const awarenessUpdate = awarenessProtocol.encodeAwarenessUpdate(
      this.awareness,
      Array.from(this.awareness.getStates().keys())
    );
    
    // 存储到用户的协作元数据集合
    await createRecord('com.collab.metadata', this.resourceUri, {
      crdt_update: Buffer.from(update).toString('base64'),
      awareness_update: Buffer.from(awarenessUpdate).toString('base64'),
      timestamp: new Date().toISOString()
    });
  }
}

2. 活动流与状态管理

分布式协作元数据的一致性保证需要权衡实时性和最终一致性。采用活动流（Activity Streams）模式：

活动流格式：

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Update",
  "actor": "at://did:plc:abc123",
  "object": {
    "type": "CursorPosition",
    "resource": "at://did:plc:def456/com.github.document/doc1",
    "position": { "line": 42, "column": 15 }
  },
  "published": "2026-01-19T03:32:43Z"
}

状态同步策略：

  • 实时同步：WebSocket 连接，延迟 < 100ms
  • 批量同步：每 5 秒或每 10 个操作批量提交
  • 离线同步：本地存储，恢复连接后增量同步
  • 冲突解决：基于逻辑时间戳的 last-write-wins 或自定义合并策略

监控指标：

  • 同步延迟：P95 < 200ms，P99 < 500ms
  • 冲突率：< 1% 的操作需要手动解决
  • 离线恢复时间：< 2 秒（从本地存储恢复）
  • 内存使用：< 50MB / 活跃文档

3. 访问控制与协作的集成

将 ABAC 与协作元数据系统深度集成：

权限驱动的协作功能：

interface CollaborationFeature {
  // 基于权限的功能开关
  canEdit: boolean;      // 由ABAC策略决定
  canComment: boolean;   // 由ABAC策略决定
  canShare: boolean;    // 由ABAC策略决定
  
  // 协作状态
  activeUsers: UserPresence[];
  cursorPositions: Map<string, CursorPosition>;
  selectionRanges: Map<string, SelectionRange>;
  
  // 实时更新
  subscribeToUpdates(callback: (update: CollaborationUpdate) => void): void;
  applyUpdate(update: CollaborationUpdate): Promise<void>;
}

// 权限检查集成
async function checkCollaborationPermission(
  userDid: string,
  resourceUri: string,
  action: string
): Promise<boolean> {
  // 收集实时属性
  const attributes = await collectAttributes(userDid, resourceUri);
  
  // 评估ABAC策略
  const decision = await policyEngine.evaluate(attributes, action);
  
  // 集成协作状态
  if (decision.allowed) {
    const collaborationState = await getCollaborationState(resourceUri);
    if (collaborationState.locked && action === 'write') {
      return false; // 文档被锁定，禁止编辑
    }
  }
  
  return decision.allowed;
}

可落地参数与监控清单

1. 部署配置参数

ABAC 策略引擎：

abac_engine:
  cache:
    memory_limit_mb: 512
    redis_ttl_seconds: 3600
    warmup_enabled: true
  evaluation:
    max_concurrent: 1000
    timeout_ms: 100
    circuit_breaker_threshold: 0.8
  monitoring:
    metrics_port: 9090
    trace_sample_rate: 0.1

协作元数据服务：

collaboration_service:
  crdt:
    yjs_worker_count: 4
    document_memory_limit_mb: 100
    auto_save_interval_seconds: 5
  sync:
    websocket_heartbeat_seconds: 30
    batch_size: 10
    max_retry_count: 3
  storage:
    redis_prefix: "collab:"
    local_storage_quota_mb: 500

2. 监控与告警清单

关键监控指标：

  1. ABAC 性能指标

    • abac_evaluation_latency_ms：策略评估延迟
    • abac_cache_hit_rate：缓存命中率
    • abac_policy_count：活跃策略数量
    • 告警阈值：P95 延迟 > 100ms，缓存命中率 < 80%

  2. 协作同步指标

    • collab_sync_latency_ms：同步延迟
    • collab_conflict_rate：冲突发生率
    • collab_active_sessions：活跃协作会话数
    • 告警阈值：同步延迟 > 500ms，冲突率 > 5%

  3. 系统健康指标

    • memory_usage_percent：内存使用率
    • cpu_usage_percent：CPU 使用率
    • connection_count：活跃连接数
    • 告警阈值：内存 > 85%，CPU > 90%

运维检查清单：

  • ABAC 策略语法验证通过
  • CRDT 文档序列化 / 反序列化测试
  • 离线同步恢复测试
  • 并发压力测试（> 1000 用户）
  • 故障转移和灾难恢复演练
  • 安全审计：权限提升、数据泄露测试

3. 渐进式部署策略

阶段 1：只读协作（1-2 周）

  • 实现光标位置和用户状态同步
  • ABAC 控制只读权限
  • 小范围用户测试（< 100 用户）

阶段 2：评论协作（2-3 周）

  • 添加评论线程 CRDT
  • ABAC 扩展评论权限
  • 性能优化和监控完善

阶段 3：完全编辑协作（3-4 周）

  • 实现实时编辑 CRDT
  • 完整的 ABAC 权限矩阵
  • 大规模部署和负载测试

阶段 4：高级功能（持续迭代）

  • 版本历史和时间旅行
  • 高级合并策略
  • 机器学习驱动的冲突预测

总结与展望

社交文件系统的活动访问控制层与协作元数据系统设计，代表了分布式社交应用架构的演进方向。通过将 ABAC 的细粒度权限控制与 CRDT 的无冲突协作相结合，我们能够在保持数据主权和用户控制的同时，实现丰富的实时协作体验。

关键成功因素包括：

  1. 性能优化：ABAC 策略评估和 CRDT 同步必须满足实时性要求
  2. 一致性保证：在最终一致性和实时性之间找到平衡点
  3. 用户体验：权限变更和协作状态更新需要无缝衔接
  4. 运维可观测性：全面的监控和告警体系

未来发展方向可能包括：

  • 联邦式 ABAC：跨多个社交文件系统的联合权限管理
  • AI 驱动的策略优化：基于用户行为自动调整权限策略
  • 零知识证明：在保护隐私的同时验证权限属性
  • 量子安全 CRDT：面向后量子密码学的协作算法

社交文件系统的真正潜力在于打破应用壁垒，让用户数据真正属于用户。活动访问控制和协作元数据系统是这一愿景的关键使能技术，它们将重新定义我们在数字空间中的协作方式。

资料来源

  1. 社交文件系统架构：https://overreacted.io/a-social-filesystem/ - Dan Abramov 对 AT 协议社交文件系统的深入解析
  2. CRDT 协作技术：https://docs.yjs.dev/ - Yjs 文档，CRDT 实现协作应用的核心技术
  3. 属性访问控制：基于行业标准的 ABAC 实现模式与最佳实践
查看归档