[Continued from this post that collects some of the questions/requirements]

Here are our thoughts on how a protocol to manage groups of REST-ful entities could look like. First, here are some design principles:

• Anybody can create a group of anything, at any time, there is no central "group registration service" or anything like that that's required.
• Any group is identified with a HTTP/HTTPS URL (or other identifier, such as XRI, that's resolvable into such a URL). To set up a group, all that's needed is that somebody declare that a particular URL represents a group. In the extreme case, that URL may not actually have any behavior — yep, there are some cases where that may be useful — but usually such a URL will support a few operations (see below).
• The members of the group are URLs themselves (or any other kind of identifier, such as e-mail addresses, etc. There are fewer restrictions on the contained identifiers because there's no need for those identifiers to be REST-ful).
• There are no restrictions between the location of that identifier, and the members that the group has. For example, URL http://example.com/mygroup could be a group that contains only members on netmesh.org, but no other host. There is no requirement that such a group would have to reside on netmesh.org as well. Anybody can group anything from anywhere on the web.
• There are a number of operations on that group (see below); it's very important to recognize that different clients may be allowed to perform different operations, so this ability — essentially ACLs on the various operations — must be designed in from the beginning. For example, only some clients may ever be allowed to see the entire membership list of a group.

Now, the operations. Recall that any of them may be subject to access control on a per-client basis and only some clients may be allowed to perform any one of them.

• Obtain a list of all members of the group.
• Add a member to the group. Not all groups may implement this. For example, a group such as "all users who blog commented at this site in the last 24 hours" should not have an addition operation.
• Remove a member from the group (not all groups may implement this).
• Determine whether or not a certain potential member of a group is actually a member of that group (return boolean).
• subscribe to the group, i.e. obtain change notification (think: e-mail) when the group changes.

Of course, there is no reason that a group http://example.com/mygroup could not be a "projected group" that takes its membership from other groups, such as "this group contains all members that are members of group http://example.net/joesgroup but not of http://spam.example.net/spammers".

Finally, a concrete implementation could look like this, where GROUPID is the group identifier (e.g. its HTTP URL). All these operations would be subject to an ACL defined for the GROUPID and clients would be required to authenticate first using OpenID or GPG-based authentication:

• GROUPID?action=groupid-list-members: return the list of members of the group. An optional format parameter, as we have it in LID, could specify a MIME type for the result, such as text/plain or text/html or RSS-FOAF.
• GROUPID?action=groupid-add&id=MEMBERID: add a new member with the identifier MEMBERID.
• GROUPID?action=groupid-remove&id=MEMBERID: remove a new member with the identifier MEMBERID.
• GROUPID?action=groupid-check-member&id=MEMBERID: determine whether or not MEMBERID is a member of the group.
• GROUPID?action=subscribe&id=SUBSCRIBERID: send change notifications to the subscriber with SUBSCRIBERID, which can be an e-mail address or a URL that supports the LID Authenticated Messaging protocol.
• GROUPID?action=unsubscribe&id=SUBSCRIBERID: cancel change notifications to SUBSCRIBERID.

While more complex capabilities can be envisioned, I think this is about all that's needed for most of the applications that we came across. (and one can always add operations)

The only other thing I'd add is to perform the operations only directly on the identifier GROUPID if GROUPID is an HTTP URL, and does not support Yadis meta-data discovery. If it does, more types of identifiers can be used, such as XRIs, and the actual implementation can be delegated. This is desirable largely for the same reasons as identity server delegation is desirable in OpenID. (If this paragraph makes no sense to you, don't worry about it, Yadis should be optional for this kind of thing and you don't need to understand Yadis to understand what I'm talking about here.)

In a future post, I will discuss a few of the really interesting capabilities that this kind of protocol will all give us. We first started thinking about this more than a year ago, and that's where my Rsfoaf proposal (later superseded by RSS-FOAF) came from, in case you have been following that and were wondering ... The groups in those feeds are exactly the kinds of groups that I'm discussing in this post.