provide "nested" groups piggy-backing on DNS

### Problem you are trying to address with this feature

- As an H user, I might like to see all annotations by my members of my lab.
- On another occasion I might want to see all annotations by members of any lab at my research institute.
- As an H group administrator, I would like to create groups that can be discovered (via a naming convention) by other members of my institute.
- As an adherent of open annotation, I require distributed and unfettered public group administration .
- As a organization committed to open annotation, and also seeking to "establish sustainable business models for the Hypothes.is web annotation platform", I want a "value-added" proposition to pitch to organizations once they are "sold" on H.

Imagine, where example.org is a medical research institute, a member can follow/participate:

- journalClub.professorX.lab.example.org - professorX's journal club
- professorX.lab.example.org - all the h.activity in her lab
- lab.example.org - h.activity of all labs at the institute !
- example.org - institute-wide h.activity anyone?
- foobar.project.example.org - what are people annotating on the foobar project?

### Your solution - a new group type: "open domain groups"

- consider groups names as extensions of domain names: professorX.lab.example.org professorY.lab.example.org lab1.example.org
- require (by default) that such group names may only be created by group admin accounts having emails verified to come from the domain (i.e. you have to have a verified email from example.com to create professorX.lab.example.org).
- allow to retrieve annotation by group, respecting the hierarchy (i.e. group="example.org" implies group %like% "example.org*")
- develop and sell advanced controls over group admin (i.e. LDAP sync). When/if example.org wants to exert control of group management, they will have an avenue to do so.
- develop integrations with other platforms and sell services around their configuration.
- a widget for [Open Science Framework](https://osf.io/)
- Slack!
- Microsoft Teams!

You could require that
- new top-level 'open domain" groups (named directly after the domain) only be create-able by someone coming from within the domain
- new lower-level groups names only be create-able by h member of parent group.

This might be a nice balance of being "open" and providing an on-ramp for organizational users to "grow like topsy". Let them admin their own internal group structure user by user, group by group, and get the whole institute "hooked" on openAnnotation,

Then, when example.org decides they want/need to
- make things even easier on their institutional users.
- tie it into other supported initiatives (library services, journal club, reference managers)
- _control_ (shudder) this thing!

... thats when you **sell** the institutional client The WHOLE enchilada:
- tools/configuration scripts to install the chrome extension preconfigued on all their PCs!
- periodic group sync with auth (LDAP, AD, ...)
- custom integration with their intranet with templates/training/evangilism for, example: "how to use H to run an efficient journal club"
- ????

FWIW: I also am a member of F1000 which provides for sharing annotations within a group, but, alas, I can not get a group RSS feed of them though I have pitched the idea to their team.

F1000 has a laudable literature recommendation system, but, honestly, I prefer to have an excellent open annotation system and get my literature recommendations through other means. So, please don't use H to drive recommendation systems, or, at least, make it opt-in. Who knows, there may be $$ for you to lash on one!

No files, tests, or entry points are named. Start by reviewing the existing group creation, membership, and annotation-retrieval behavior, then define the domain hierarchy, authorization rules, and integrations required; done would include an agreed design and implementation plan for nested open-domain groups.

Written by the indexing model from the issue text.