Changes to the important membership roles should be a part of the group timeline. It may be valuable to know who were the members at a previous point in time.
Inviting members. With and without knowing their account ID.
Create an invite blob. Then send that blob (literally or with a CID) to the recipient. Then the recipient can make their first
Accepting the invite to join a group.
owner or admin creates a change that sets members[accountId] = role
Request to join a group.
create a change that sets members[myAccountId] = role (you can request any role probably)
Do we do open membership groups? Or can we model them with the ask to join flow? Maybe a server automatically accepts members in such groups?
if group.openMembership = true, then anybody can create a change that sets members[myAccountId] = 'contributor'
Revoking group membership.
the admin or owner sets members[accountId] = ''
Leaving a group.
the member sets members[accountId] = ''
Do we do Groups and Accounts, or do we unify the concept of a Space?
Yes we can unify groups, accounts, and documents
How can we support multiple drafts? Are they stored in the space? Maybe there's a special "private" space that never gets shared?
One draft per branch.
Do we do fine-grained permissions? Are they expressed on the space? How to convey that certain documents are only meant to be edited by certain members. Do we do the lead editor approach we talked about yesterday? Maybe we should go full on with a very expressive RBAC like in this article: https://tailscale.com/blog/rbac-like-it-was-meant-to-be ?
members + indexRoles permissions are very expressive with the appropriate roles: (controller, editor/admin, author/editor, collaborator)
Do we support subgroups, or folders? It's different from having a separate space that is linked form the parent space, because the parent owner wants the have control over the entire thing, not merely linking to some other space. Also this can be a unit of permissions similar to Google Drive and alike. Expressing folders by using / in paths has the disadvantage of not being able to move the entire subtrees like you can do in a file system.
Yes we can do folders and make them renamable by using some alias magic
Say we have a space with index: { "123/foo": "docVersion" } where 123 is the folder ID (not literally part of the path). Then we would have indexFolderNames: { 123: 'myFolder' }. The final path is myFolder/foo
We can even implement deep subFolders by ... to be explained.
How to close/abandon a branch? Is it different when the branch is merged vs. when it's just abandoned?
A branch can be closed by removing the item from an index where it was previously loacated
Do we support transferring ownership? I guess only meant for spaces, because documents themselves don't have owners.
If it is possible to fork an entity, transfer of ownership should not be necessary. But maybe it is possible
Do we need to "inline" the content of the frontpage into the space itself? We can now make atomic changes for the document being published, and the frontpage, because the "Commit" is now scoped under the Space.
Yes the content of the space home should be saved directly into the space entity (the account or group). This is necessary because the home content is part of the space timeline, not a child timeline.
What happens when pathname changes where it points to, but I still have an old link with a version?
For any version, the index will only point to a single entity (or none). The child identity doesn't really matter.
How can we resolve a link to a document without having to download and verify the entire space?
The whole entity does not need to be downloaded to resolve a document. The latest change is sent, and change dependencies are loaded until the latest index entry is found. The rest of the history can be loaded async from there.
What happens with comments? Do store "blessed" comments in the space?
Depends what is meant by "store". Yes comments are distributed alongside the space, if the commenter has the appropriate permission.
What happens with files and other attachments? Are they "free-floating" and only exist because they are linked in documents?
Yes.
What conflicts do we want to surface to the user?
•
Inside an entity, an indexed document has changed concurrently, both editing the same paragraph
How can we truncate or compress the space history?
Truncation should not be necessary, but compress seems important.
How to "resolve" comments?
Depends who is allowed to resolve the comment. This is an interesting UX question. It could be modeled as a reply maybe.
What about document metadata (the open-ended one)? Is it stored in the document, or in it's "entry" inside a given Space?
Stored in the entity, so it is part of the appropriate timeline and it may be committed alongside changes to content, index, and membership
Why don’t we store files under named paths like we do for documents? Spaces look terrible similar to a file tree now.
We could do this in the future if we decide to, allowing people to directly index ipfs content
How spaces play together with the “information hierarchy” expressed with embeds, outlines, etc.
This is a UX question, does not block backend implementation
How to rewrite history to remove illegal content?
a few ways to do this but basically this breaks the chain
How can members can be securely removed from a space?