Re: Rights Expression Language (REL) for Activity/Streams/Pub?

>  I'm sure that folk will propose either that this is "not a problem" or
> that simpler syntax should be used. However, I am convinced, after
> listening for a long time to a wide range of user issues, that the need for
> something like this, if not precisely this, will eventually be
> broadly recognized. My hope is that we'll be able to reduce the
> implementation and specification burden by having one facility that can
> address a wide range of otherwise disjoint problems.
>

simpler syntax *should* be used -- especially for things that aren't
"rights" in the first place, like replying.

anyone can put whatever they want for `inReplyTo`, and what the "reply
control" FEP seeks to prevent is not the reply itself, but the automatic
threading behavior of existing software, based solely on `inReplyTo`. the
use case relies on having some concept of a "conversation" which is
controlled by some authority -- an authoritative context. rather than
solely trusting that authority to distribute everything, you want to allow
for trusted distribution of authorized activities by the participants
themselves, to other actors outside of the "conversation". if you restate
the problem, it's like saying, "how do i know this object is part of a
collection without checking the contents of the collection?"

note that this is a problem of verifiability, not rights expression. you
are not asking others to respect your rights, but rather, you are giving
them proof of authorization, like a notarized paper or a postage stamp. if
someone sends you a "reply" and you don't accept it, then you can discard
it and not show it underneath your own post. if that person sends the reply
to their followers, and their followers are aware of the authoritative
context, then the followers' softwares can act upon that information. you
could show a "verified" indicator on approved replies, or you could demote
unapproved replies underneath a divider, or you could hide unapproved
replies behind a click-through, or you could drop the message entirely.

the only part of such a scheme that is remotely related or possible with a
rights expression language is the `canReply` signal (working title), which
is a single property that indicates all actors which can reply -- typically
at least yourself and anyone mentioned. but this is purely advisory, so
that you might guess ahead-of-time whether your interaction will be
accepted. the actual mechanism is the proof of approval.

similarly, one might imagine "delegating permission to post on an account"
as a capability delegation, not as an expression of rights. the general
observer has no need to know who you have given permission to manage the
account -- granting permission is a private action. you might use ODRL to
describe the metadata of such a capability delegation, but that is
something you should take up with a specific capability framework, like
ZCap (which has properties like `caveats` to indicate that certain
capabilities have been attenuated out). i have not personally reviewed the
compatibility of ODRL and ZCap, so i cannot speak further on the matter.

>