group-refactor.hoon

|%
+$  resource  [=ship =term]
+$  groups  (map resource group)
+$  tag-queries  (map term (set ship))
+$  group
  $:  all-members=(set ship)
      =tag-queries
      =policy
  ==
::
+$  policy
  $:  invite-only=?
      allow-comets=?
      black-list=(set ship)
  ==
::
:: example tags (can be used differently in different apps...):
:: %pending - denotes that member has been invited but not joined yet
:: %admin - denotes that member can add and remove members
::
+$  action
  $%  [%add-group =resource ships=(set ship) tag-queries=(unit tag-queries) =policy]
      [%add-members =resource ships=(set ship) tags=(set term)]
      [%remove-members =resource ships=(set ship)]
      [%add-tag =resource =term ships=(set ship)]
      [%remove-tag =resource =term ships=(set ship)] :: if set is empty, remove tag. otherwise remove tag from ships
      [%change-policy =resource =policy-diff]
      [%remove-group =resource]
  ==
::
+$  policy-diff
  $%  [%invite-only p=?]
      [%allow-comets p=?]
      [%black-list-add ships=(set ship)]
      [%black-list-remove ships=(set ship)]
      [%black-list-clear ~]
  ==
::
+$  update
  $%  [%initial =groups]
      action
  ==
--

They aren’t necessarily namespaced by app. They could be reused across apps if desired.

Can you explain how you imagine solving for 1) apps knowing about each other's assumed tag definitions and 2) tag re-use across apps?

Also, to answer my own question:

why don't they live in the apps themselves? Nobody else will be able to do anything useful with them...

Because we may still want to display these tags in group listings etc.

I view tag re-use as a non-issue. If apps want to make use of the same tags to provide similar semantics, let them. If they want unique app-namespaced tags with custom app-specific semantics, let them. If we end up letting users generate their own tags and assign them custom semantics within certain apps, that works too. I don’t see any downsides or added complexity from this.

We should probably standardise on a set of tags for each cross-app problem domain that we are trying to solve. The big motivator for tags right now is permissions and we should absolutely standardise a set of tags so we can handle permissions consistently across apps. If an app wants to use a tag that is not standardised, then it should be free to do so, but as soon as we want to use this tag across apps we should think properly about the issue that it solving and standardise the tag for all apps. We already have far too many dependencies between apps, we don't want to introduce more. Non-standardised tags should always be namespaced, and should be effectively opaque to the apps that don't use them.

cc: @loganallenc @Fang- @ixv