Meeting records and file permissions, modeled as a graph

In healthcare and finance, the video call is a commodity and customers pay for the record of the meeting, so the record is what the system has to guarantee.

The hard question is whether a person may open a particular file, and the answer depends on a chain: they attended a meeting, the meeting is linked to a document, the document has versions, a version carries a signature, and permission can come either directly or through the meeting. A document can also belong to several meetings at once, so it cannot simply be filed under one of them.

In a relational schema, every such permission check is a recursive join, which slows down with every new type of relationship and gets harder to maintain with every new rule.

A graph data model in Neo4j. I modeled people, meetings, files and signatures as nodes, and attendance, attachment and permissions as edges. There are four permissions: read, write, download and delete. A permission check becomes a traversal of the graph, which is the operation a graph database is built for.

Google models access control as a graph too, for the same reason, so this is a recognized pattern.

Files added during the meeting. A document can be uploaded in advance or attached while the meeting is running, and the moment it is attached it has to appear for everyone present, with the right permissions for each of them. The graph therefore changes live during the meeting, while people are watching.

Transcripts that feed the next meeting. Transcription runs in real time with speakers separated, and the finished transcript goes into the agenda of the next meeting.

Whiteboard saved as objects. Strokes, shapes and text are stored as separate elements with their own properties, not as a flat image, so the board can be reopened and edited after the meeting.

Guest access, because of HIPAA. A patient should not have to create an account to attend a consultation, so meeting HIPAA meant building a feature: patients can join as guests.

A browser extension with one permission. The extension is optional, is used for starting and reviewing meetings, and has no access to media at all. Extensions for meeting platforms tend to ask for broad permissions, such as tab capture, the microphone and access to every page. In a product sold into healthcare, broad permissions cause three problems: a harder review in the extension store, a warning at install, and a question in the customer's security review that has no good answer.

• Permission checks answered by traversing the graph, however long the chain
• Documents that belong to several meetings, with version history and signing
• Real-time transcription with speakers separated, feeding the next meeting's agenda
• Guest access that satisfies HIPAA
• Product sold to an American bank

Five of us built broadly for eight months, and no shared component layer ever emerged. The data model was the product's strength, but the front end ended up with three UI frameworks and four dropdown libraries in the same codebase. We would build the shared component library first, which is what I did on the next project.