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

a wrote:

> the "reply control" FEP seeks to prevent is not the reply itself, but the
> automatic threading behavior of existing software

This is, of course, a great example of why the vocabulary must be carefully
composed to reflect the SocialWeb context, rather than simply assuming that
what makes sense in other contexts can be unthinkingly imported into this
new context. I'm not stuck on any one definition of the semantics of Reply. In
fact, I quite like the idea that "inReplyTo" should be merely a statement
of intent while the author of the reply's subject is able to exercise
control of the subject's replies collection. This means that a Reply is
really just a normal Note with an attribute. One would never need
permission to make a Reply, but you might need permission to have
your Reply included in the subject's replies collection.

the only part of such a scheme that is remotely related or possible with a
> rights expression language is the `canReply` signal

I agree. And, my example used the REL for nothing more than identifying
those who have permission to reply -- however, one defines the meaning of
that term.

one might imagine "delegating permission to post on an account" as a
> capability delegation,. ...  like ZCap (which has properties like
> `caveats`...

Yes. If I had imagined that everyone on this list was intimately familiar
with ZCap-LD <https://w3c-ccg.github.io/zcap-spec/>, I would have said,
"The rights expression language is like the caveats in ZCap." In fact, I
expect that a "ZCap capability" would be generated for anyone authorized to
exercise one of the rights, or capabilities, delegated via the REL. Given
that a "Capability" is composed of the identification of some resource or
operation and a set of permissions, I am confident that there is no
conflict between what I'm suggesting and what ZCap is trying to do. I'm
simply suggesting that a more expressive language be used for describing
caveats or permissions in the context of social apps. If, in fact, that
language is provided to serve other purposes anyway, there should be a
minimal development burden to use it in another context.

Thanks for your comments. If I haven't understood them, please let me know.

bob wyman


On Mon, Mar 6, 2023 at 6:15 PM a <a@trwnh.com> wrote:

>
>  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.
>
>>