Group permission behaviour

[poweruser82]

Considering #176 and #182 suppose this use case:

1. Create a group g with 2 people (e1, e2).
2. Post a post p with group permission set to g.
3. Edit group g adding e3.
4. Edit group g removing e2.

Can e3 after time 3 see post p?
Can e2 after time 4 see post p?

I suggest changing permission.groups to a list of object

{
    "entity": "https://daniel.tent.is",
    "post": "123",
    "version": "ef537f25c895bfa782526529a9b63d97aa631564d5d789c2b765448c8635fb6c",
}

If version is specified, the permission applied is just the one specified.
If no version is given, the last version applies.

The entity attribute can be omitted if is the same of the author of the post. Otherwise it could be useful to use public group permission managed by someone else.

If no entity and version is specified for an entry in the list, that entry could be a string with the post id instead of an object.

[titanous]

Yes, e3 can see the post after she is added to the group. And, no e2 cannot see the post after he is removed from the group. Groups are a way of using the server to update permissions automatically. The latest version of a group is always used.

Adding version references to groups doesn't make a lot of sense. The whole point is that the group permissions are applied to all posts that reference the group when the group is updated. Since a version can never be updated, referencing a version wouldn't have any benefit over specifying the entities in permissions.entities.

Referencing groups from another entity won't work well, because the server isn't guaranteed that it will get updates about the group. This type of synchronization could be done trivially with an application.

[danielsiders]

It's trivial for an app to hardcode permissions by adding all members of a group to a post's permissions when that behavior would be desirable. Otherwise, dynamic permissions are the norm

[poweruser82]

Not so trivial if the group has a lot of members and you want this behaviour fore each one of your posts.
There's a lot of waste of bandwidth and storage.

[titanous]

In that case the app would just update a group post instead of the individual posts.

[poweruser82]

I don't understand.
Why replicate information that server already has to save.
That information is accessed in any case when server have to process a post. The cost of accessing a version is reasonably the same for whichever the version is.

[poweruser82]

Let's do an example. There is a chat service for a company. Every employee is in the group. Conversation in the chat is confidential. Someone (Bob) got fired and so he's removed from the group. Remaining employees talk about the firing. After an amount of time Bob is hired back, so he's added back to the group. With the current model he's able to get the messages about him and this is unwanted.

Another case. The company is working on a project. To accomplish to a particular task, an external group of professionals is added to the group. They must not have to look at all the previous iterations of the project, they can only access the current status and the future one until they are in the group.

If you have huge groups (Foxconn's employees, universities' students) converting the group to list of entities for each post is a huge waste.

My proposal is to simply honor the version property when specified. The server has nothing special to do while retrieving the group post than it has to do for any other post.

[danielsiders]

@poweruser82 The group post only has the name and other metadata about the group. Each member is connected to the group via mentions/refs, so there is not group version to specify; groups are intended to be dynamic.

In very large institutional environments, expect institutions to be running their own Tent servers or using an enterprise SaaS provider who will doubtless implement optimizations for very large groups when used internally. This is a server implementation detail for an edge use case.

An alternative to manually listing all entities from a group would be to create a new group with the specific members you want (and repeat this process in the future). There's nothing stopping apps from creating and using groups as though they were static, although other apps can still alter the groups later (editing/creating groups will probably be a specific permissions scope when authing apps)

[poweruser82]

Can you provide details about how groups are going to work? There's no spec on tent.io and it looks like previous specs differ a lot.

[titanous]

@poweruser82 The basic concept is that there will be a "group" post that contains the name of the group, and one or more "group member" posts containing a single entity that mention/ref the group post.

[poweruser82]

@titanous What's the reason of not just mention/ref entities in the group post?

[titanous]

@poweruser82 Mentions/refs are limited to 100 elements and the content is limited to 1MB. Using a post per entity allows for large groups because we can utilize the built-in feed pagination system.

[titanous]

(It also solves concurrency and change tracking)

[poweruser82]

So to get members of group the_group applied to the post the_post the server queries /posts?types=groupmebers&mentions=the_group. Doesn't it?

"Static" groups could have the same type of standard group with a static fragment. In this case the query would just be /posts?types=groupmebers&mentions=the_group&before=the_post.published_at

[danielsiders]

Groups will be dynamic. There are a variety of ways apps can achieve the same results as a "static" group without changing the standard group behavior.