[cristianscheid]

• Relate to: Support OCM 1.3 #2386

Summary

This is a early stage prototype to start using OCM in circles federation instead of its own custom protocol. The goal is to gather feedback and start a discussion on the approach.

As a first step, this is what was done:

• new OCM capability added to /.well-known/ocm: circles-v1
• new OCM routes, to be used when remote servers advertise circles-v1:

  current route -> new OCM route:
  
  POST /apps/circles/event/ -> POST /ocm/circles-v1/event
  POST /apps/circles/incoming/ -> POST /ocm/circles-v1/incoming
  GET /apps/circles/circles/ -> POST /ocm/circles-v1/circles
  GET /apps/circles/circle/{circleId}/ -> POST /ocm/circles-v1/circle/{circleId}
  GET /apps/circles/members/{circleId}/ -> POST /ocm/circles-v1/members/{circleId}
  GET /apps/circles/member/{type}/{userId}/ -> POST /ocm/circles-v1/member/{type}/{userId}
  GET /apps/circles/inherited/{circleId}/ -> POST /ocm/circles-v1/inherited/{circleId}
  GET /apps/circles/memberships/{circleId}/ -> POST /ocm/circles-v1/memberships/{circleId} 
  

  • the first two routes are related to actions performed on a team (e.g. add member, change team name, etc)
    • when action is performed on the server that owns the circle, request it's sent to incoming endpoint of all other servers that contain members, broadcasting the action
    • when action is performed on remote servers that don't own the circle but have members, request is sent to event endpoint of server that owns team, which then broadcasts to all other servers
  • other endpoints are used to gather data from remote servers
• added new config value: "federated_teams_ocm"
  • when enabled, attempts to communicate to other server using OCM endpoints

• existing routes are still there, so servers without this change keep working
• remote servers are still registered with occ circles:remote using WebFinger discovery
• federated items (inside lib/FederatedItems) logic was not changed, meaning server still validates/applies change, and broadcasts it through the async loopback
• what changes is how requests travel between servers, using OCM protocol instead of custom protocol (when enabled and remote supports it)

TODO

• if the approach of this PR is considered valid, maybe as a next step, we could do the remote server registration (occ circles:remote <host>) using OCM discovery instead of WebFinger, by checking if remote has it enabled and lists the capability (circles-v1)

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[cristianscheid]

changes on this file are mainly code being extracted to lib/Service/RemoteEndpointService, so logic can be reused when using OCM