Fine grained permissions for webRTC handshake

Hi, I am building a WebRTC P2P app for a university project and have hit a security limitation regarding permissions for anonymous users.

The Architecture: We use Appwrite Realtime for signaling. Both the host and joining clients subscribe to a Room row and its related Connection rows (one-to-many relationship). They update these rows with ICE candidates and SDP offers/answers to establish the connection.

The Problem: Since we support unregistered (anonymous) users, we currently have to enable Connection table-level permissions (create, read, update) for role:all or role:guests.

This creates a security vulnerability: any malicious user can read all connection rows in the table, potentially harvesting ICE credentials or sabotaging other sessions.

The Limitation: We attempted to restrict table-level permissions and rely on Row Security, but we hit a roadblock: Appwrite relationships seem to act only as data links, not as permission inheritance structures. We cannot say "If a user has write access to this Room row, they automatically get write access to its child Connection rows."

My Question: Is there a native way to cascade permissions from a parent Table (Room) to child Tables (Connections) without using a server-side Appwrite Function to manually manage ACLs for every insert? If not, is this feature on the roadmap for the TablesDB API?

TL;DR

Appwrite doesn't cascade permissions from parent to child tables, they're evaluated independently. Possible solutions include using document-level permissions with room IDs as a filter or restructuring the signaling flow. Avoid third-party payment requests for assistance.

I can help! The issue is that Appwrite doesn't cascade permissions from parent to child tables they're evaluated independently. Quick question: Are you open to using an Appwrite Function to handle this, or do you need a solution using only permissions?

Thanks! I much rather have a solution that doesn't use Appwrite Functions. If it's absolutely essential, I might consider it, but that's a last resort (We want the WebRTC functionality to be client side as much as possible)

I completely understand wanting to keep it client-side. There are a few workarounds we could explore without Functions like using document-level permissions with room IDs as a filter, or restructuring how you handle the signaling flow. I'd be happy to walk you through some solutions in detail. Would you be open to discussing this privately? I have some experience with WebRTC + Appwrite setups and could help you implement a secure approach that fits your project requirements.