Project: Information Hierarchy in Groups
We just had a call with Gabo, and this document summarizes my idea about subgroups combining all the information we all have been discussing so far. Let's consolidate any further discussion about subgroups under this project.
This document opens up some rabbit holes that we should probably address before deciding to implement anything.
Problem
Group users often want to create some sort of a hierarchy for their information. Graphs and hypertext are great, but it can become too overwhelming to maintain, especially for people that are not used to this model of thinking.
We've been talking a lot recently about subgroups and about different ways to implement information hierarchy in groups.
Gabo has discovered the side-effect of embedding one group in the document of another group, so that it gets published as a reference materials, and proclaimed that we already have subgroups :)
This side effect has a bunch of trade-offs and doesn't stop being a side-effect, i.e. it's not something to rely on.
The main issue is that there's no way to make pretty paths for subgroup docs. You always have to specify the full ID of the subgroup, like
https://example.com/g/<my-subgroup>/hello.As an alternative, I was advocating that most simple use cases could be supported by allowing nested paths, and treating them as "folders".
Say that I could publish a document with a path
/notes/my-note, so that all the documents under /notes/* are listed separately from documents under /*.This could support simple use cases when the same group of people just want to have some order with their listings.
Solution
Allow group paths point to other groups, not only documents. These links should be "latest" links.
When such a group is published to a site, the subgroup paths can be resolved by traversing through the parent, e.g.
https://example.com/subgroup-name/subgroup-path.In addition to that we can also support nested paths, which we can handle however we want.
This way simple use cases can just use nested paths, and complex use cases can reference groups. We probably need to do something to prevent cycles though.
Rabbit Holes
•
Maybe groups don't need hierarchy?
•
Maybe we could have hashtags (real ones, not backlinks) on documents, and have a selector for hashtags on sites. Similar to Discord forum tags.
=== I CAN'T REMOVE THIS FREAKING LINE ===•
Or we automatically group posts by date on a site, similar to Wordpress to make the list of documents make more sense.
•
Maybe a huge list of documents is not even bad? At least when listed by date of posting. Lots of people have their blogs with no categorization and it seems to be fine. Maybe a good search is a solution?
•
OCAP instead of ACL for access-control in groups.
This is a crazy-pill idea.
Imagine if all non-owner group changes must carry a special token issued by the owner. All memebers get such a token when they are invited to a group. This token carries information about their permissions in the group: which subpaths can they publish, whether they can publish at all, etc.
Owners can revoke tokens when members are removed from the group.
Owners can reissue tokens to expand their permissions if necessary.
The benefit is that member management is consolidated under the same entity, and you won't end up with weird situations that you can often get into when you manage permissions in Linux filesystems for example. That's one of the main argument in favor of OCAP in general.
Powered by Mintter + The Hypermedia Protocol