In our scenario we have four users Aviva, Britney, Celine and Doug.

Each user has a public key and all communication (as is always the case in Thali) is over mutual TLS auth.

Our goal is to let the users create multiple “conversations”, invite only the people they want to a conversation and to synch conversations between each other.

Conceptually a conversation is just a group of records. We can even imagine (I’m assuming you, dear reader, are reasonably conversant with PouchDB and its key structure) that the keys for all messages in the same conversation have a form like [Conversation ID]-[User Id]-[Unique Message ID].

So when Aviva creates the new conversation she can prove she created it by generating a UUID, digitally signing it with her public key and then using the hash (just to save space) of the digitally signed statement as the conversation ID. She can then create a record with the key Conversation-[Conversation ID] (I call this the creation record) as the declaration of the conversation’s existence. In that document she would put her digital signature and probably a list of who is allowed to be part of the conversation, in this case, Britany and Celine.

The point is that with this root record it’s possible to prove that it was Aviva who created the group.

For the User ID we can either use each user’s public key or a hash of the key if we want to save space.

The unique message ID is any globally unique value. We could use a count but that could allow Aviva to collide with herself if she has multiple devices that aren’t always in synch. We can order messages by including pointers to the messages they are in response to.

To further complicate things imagine that Britney comes into the room after she had previously synch’d the conversation with Aviva. In the meantime Britney had run into Celine and synch’d with her as well. So as Britney walks into the room with Aviva she not only knows about the conversation but has new messages in it both from herself as well as from Celine. Because Britney is part of the conversation we allow her to forward messages on Celine’s behalf but only in regards to the conversations on which both are members. This is essentially an optimization to allow for state to be spread faster. If we really wanted to we could have everyone sign their entries in order to prevent forgeries but canonicalization in nosql is a nightmare so we’ll leave that for later. For now just assume that we trust everyone in the same conversation to not lie about each other.

So how do we end up with a situation where people are only allowed to see records they are supposed to see and can’t update records they shouldn’t be able to update?

But what happens when Britney wants to put in a post from Celine into Aviva’s database?

In that case we would probably receive a POST request to “conversations/_bulk_docs” and have to reach into the request body to pull out a record that is trying to add a request in Celine’s name to the conversation. So we have to run an ACL check at that point that decides if Britney has permission to add a record in Celine’s name to Aviva’s conversation database as part of a specific conversation.

In this model Aviva’s phone would have four databases, one for Aviva, one for Britney, one for Celine and one for Doug. If Aviva wants a list of all conversations then she has to query across all four databases because anyone could have started a conversation. If she wants to see all the messages in a particular conversation she at least has to look across all the databases of all the members of the conversation since any of them could have contributed some data.

None of this is brain surgery but it just means that the developer has to do extra work. They have to understand which databases have to be enumerated and make sure they talk to the right ones. They can’t just throw a “show me all records whose key is Conversation-* to find all the “conversation started records” or [conversation id]-* to find all the records in one conversation.

Instead the developer has to make the same queries but make them across all the databases for all the users who have databases on the device.

But I don’t really see this model simplifying anything for us. Again, let’s take the scenario where Britney wants to forward a message in a conversation from Celine. In that case Britney would need to write to Celine’s database on Aviva’s phone. I don’t see this ACL check as being any simpler than the one above.

I do wonder thought, how far that goes? Sure we’ll stop Britney from creating views or anything else that is too expensive in Aviva’s device. But what if Britney wants to change the “conversation-[ConversationID]” record for the conversation and so alter the ACLs? Is that o.k.? In our current free for all model it actually would be o.k. Although it will be interesting to see what happens when she removes Aviva from the ACL in the conversation DB!

But this does beg a question about discovery. If Aviva created the conversation on her phone and she runs into Britney, how did Britney know to ask for the DB? My suspicion is that Britney would issue a GET on _all_dbs on Aviva’s phone and we would have to filter the results to only include DBs that Britney has at least read permissions on. That shouldn’t be too hard.

But how does a new DB get created? In other words let’s again imagine that Aviva has created a new conversation and so created a new DB to hold it. She walks into the room for the first time with Britney and their phones synch. How does Britney’s phone know that it’s o.k. for Aviva to create a new DB?

This is a really common problem in ACL land, it’s the Turtle issue. There is always a bottom Turtle, or in this case a bottom ACL and we haven’t hit it yet. It means somewhere there is another DB that says who can create new conversations. That DB also probably has some kind of validation function. For example, they will want to check that the “conversation-[ConversationID]” record’s digital signature matches the DB’s name. But honestly that doesn’t seem like the end of the world. In fact we could standardize on the “conversation-[ConversationID]” record and use it to automatically provision ACLs.

Note btw that this doesn’t make all our problems go away. Imagine we have a conversation board structure where there are multiple boards and each board can have multiple conversations. Now we have to structure database names to encode which board and conversation they are part of and we have to have multiple levels of ACLs. We need ACLs for who can create boards and ACLs for who can create conversations within a board.

Honestly I’d strongly prefer to let developers just have one big database. This makes everything from queries to views much easier to do and do right. So my vote would be for using database + method + resource + record key. Yes, this means we have to go digging inside of _bulk_docs but that isn’t brain surgery. It also means we will need filters on _all_docs (or maybe views or maybe filters on views?) but that isn’t brain surgery either.

So in our example when Britney added Aviva to her app this would cause records to be created/updated in the view stating that:

Thali’s ACL engine would use the data from the view to see if it can find an ACL with entry ID “ACLEntry-CreateRecord” and with the “create” permission for the requester, in this case, Aviva. The ACL engine is smart enough to do group resolution so it can figure out that Aviva is a member of group GUID1 and therefore has create permission. The ACL engine would then return either true or false depending on what it found, in this case it would return true and let the request continue.

When the “conversation-[ConversationID]” record is created the view logic would then need to output a new record into the view of the form:

For those feeling particularly brave you can check out the httpkey and thaligroup URL schemes for portable ways to identify users and groups.