Targeting Spec - Last Call

[James M Snell]

Ok, the Targeting Spec [1] has been out there for a while and is
stable. There are implementations available. I think it's time to put
a bow on it and call it done officially.

[1] http://activitystrea.ms/specs/json/targeting/1.0/

[Evan Prodromou]

Oh, cool. So, I'm particularly interested in this issue as we're
starting to deal with limited distribution of activity streams data
over PubSubHubbub for OStatus.

1) Typical semantics of "mentioning" someone on a social network are
that the posted object is distributed to the person mentioned as well
as the author's followers. So, a Twitter post like "@jsnell hello"
would go to user @jsnell as well as all followers.

Does this secondary audience need to be made explicit? If so, how? If
not explicit, I think it would be coded like...

{"to": [{objectType: "person", id: "acct:jsn...@example.com"}]}

If explicit, maybe something like:

{"to": [{objectType: "person", id: "acct:jsn...@example.com"}],
"cc": [{objectType: "group", id: "followers-of-evan"}]
}

? Some networks also make a "public" stream for the site available, so
something like:

{"to": [{objectType: "person", id: "acct:jsn...@example.com"}],
"cc": [{objectType: "group", id: "followers-of-evan"},
{objectType: "group", id: "everyone-on-this-site"}]
}

... or even:

{"to": [{objectType: "person", id: "acct:jsn...@example.com"}],
"cc": [{objectType: "group", id: "followers-of-evan"},
{objectType: "group", id: "everyone-on-this-site"}],
{objectType: "group", id: "everyone-in-the-world"}]
}

Another option is to explicitly list all followers, which might be
tractable for small numbers of followers but falls down with 1M+
follower accounts on some popular systems.

2) If audiences are explicit, there's an implicit ACL in the targeting
-- by analogy with email, where it's unusual to allow a user to view a
message that was not addressed to them. (Auditing and administration
being the main exception here -- email list archives being a secondary
one.)

It would be useful to either call this out ("Processors SHOULD NOT
show activities to people who aren't in the audience"), or explicitly
disclaim it ("Audience != ACL").

3) It's not clear what to do with an activity that has no audience
specification. It could mean either a) this isn't targeted to anyone
b) it's targeted to some system default (followers, the whole site,
the public), or c) the processor doesn't support targeting.

It may be useful to call out a default secondary audience when no
targeting is specified, e.g. "my followers".

Thanks,

-Evan

[James M Snell]

On Mon, Mar 5, 2012 at 8:45 AM, Evan Prodromou <evan.pr...@gmail.com> wrote:
> Oh, cool. So, I'm particularly interested in this issue as we're
> starting to deal with limited distribution of activity streams data
> over PubSubHubbub for OStatus.
>
> 1) Typical semantics of "mentioning" someone on a social network are
> that the posted object is distributed to the person mentioned as well
> as the author's followers. So, a Twitter post like "@jsnell hello"
> would go to user @jsnell as well as all followers.
>
> Does this secondary audience need to be made explicit? If so, how? If
> not explicit, I think it would be coded like...
>
>    {"to": [{objectType: "person", id: "acct:jsn...@example.com"}]}
>
> If explicit, maybe something like:
>
>    {"to": [{objectType: "person", id: "acct:jsn...@example.com"}],
>     "cc": [{objectType: "group", id: "followers-of-evan"}]
>    }
>

In this case, I think targeting the secondary audience would be
optional but yes, that's how it would be done.

> ? Some networks also make a "public" stream for the site available, so
> something like:
>
>    {"to": [{objectType: "person", id: "acct:jsn...@example.com"}],
>     "cc": [{objectType: "group", id: "followers-of-evan"},
>              {objectType: "group", id: "everyone-on-this-site"}]
>    }
>
> ... or even:
>
>    {"to": [{objectType: "person", id: "acct:jsn...@example.com"}],
>     "cc": [{objectType: "group", id: "followers-of-evan"},
>              {objectType: "group", id: "everyone-on-this-site"}],
>              {objectType: "group", id: "everyone-in-the-world"}]
>    }

Yes. I would recommend using the "alias" extension property instead of
id tho. The "alias" is something that was discussed on list a couple
of months ago. I just remembered this morning that I needed to add it
to the spec... I've done so now.. It would look like...

   {"to": [{objectType: "person", id: "acct:jsn...@example.com"}],
    "cc": [{objectType: "group", id: "followers-of-evan"},

             {objectType: "group", alias: "@all"}],
             {objectType: "group", alias: "@world"}]
   }

Or something along those lines.. the value of the alias is some fairly
system specific alias for the object in lieu of using an explicit ID.

>
> Another option is to explicitly list all followers, which might be
> tractable for small numbers of followers but falls down with 1M+
> follower accounts on some popular systems.

Using groups would be ideal, yes.

>
> 2) If audiences are explicit, there's an implicit ACL in the targeting
> -- by analogy with email, where it's unusual to allow a user to view a
> message that was not addressed to them. (Auditing and administration
> being the main exception here -- email list archives being a secondary
> one.)
>
> It would be useful to either call this out ("Processors SHOULD NOT
> show activities to people who aren't in the audience"), or explicitly
> disclaim it ("Audience != ACL").

Disclaiming it would be good. The targeting information is meant to
express the intent of the sender not necessarily control what the
recipient does with it (with clear exception of bto and bcc handling).

>
> 3) It's not clear what to do with an activity that has no audience
> specification. It could mean either a) this isn't targeted to anyone
> b) it's targeted to some system default (followers, the whole site,
> the public), or c) the processor doesn't support targeting.
>
> It may be useful to call out a default secondary audience when no
> targeting is specified, e.g. "my followers".

I would rather leave this up to the implementation. Like I said, the
targeting information is meant only to express the intent of the
sender. It's up to the implementation to figure out how to actually
handle the activity, including selection of the default audience.

>
> Thanks,
>
> -Evan
>
> --
> You received this message because you are subscribed to the Google Groups "Activity Streams" group.
> To post to this group, send email to activity...@googlegroups.com.
> To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.
>

[Bob Wyman]

If the intent is to submit this draft to the IETF, then I would suggest that Section 4 (The "Alias Object") needs additional work. My concern is that IETF documents are supposed to facilitate inter-working between systems, yet, as drafted, the "alias" feature seems inherently single-system in its definition and thus no useful interworking is possible.

The problem is that an address like "@friends" can't be usefully processed by more than a single system (and, it isn't obvious which system that is...). Interworking is not possible because the meaning of "@friends" is context or scope sensitive. Because the definition of  "@friends" may have different meanings depending on the system that processes it, there exists significant risk of interworking issues -- one system might mistakenly attempt to use its own definition of "@friends" when interpreting aliases defined in a scope that has a different definition of "@friends." 

In order to facilitate interworking, it seems to me that whenever an identifier is used in an "inter-system" context, there should be some specification of the scope of the identifier. If that scope is not explicitly included in the encoding of the identifier, then at least we should expect that the specification text would detail how, in fact, a processor is expected to determine the scope of the identifier.

Note: The current definition of the Alias Object reminds me very much of the problem that we used to have decades ago when we were converting from closed to open email systems. (i.e. when we started to worry about interworking between email systems.) In earlier times, we had many systems that allowed you to send mail to "Tom" or "Bob." But, those systems had to be modified to support sending to "t...@exmple.com" or "b...@example.com" instead. Of course, the "short cut" method of addressing to "Tom" or "Bob" was often maintained as a local client feature, however, it *was not* propagated into the IETF addressing specifications whose only reason to exist is to support interworking. System specific or purely local features have no place in IETF specifications.

bob wyman

[Martin Atkins]

On 03/05/2012 10:58 AM, Bob Wyman wrote:
> If the intent is to submit this draft to the IETF, then I would suggest
> that Section 4 (The "Alias Object") needs additional work. My concern is
> that IETF documents are supposed to facilitate inter-working between
> systems, yet, as drafted, the "alias" feature seems inherently
> single-system in its definition and thus no useful interworking is possible.

I suppose it depends on what you mean by "system".

The intent as I understood it was to define a syntax for referring to
"well-known" objects, but leave the definition to be defined by other
specifications.

So, to take an example, OStatus (a protocol that builds upon Activity
Streams) can define a set of well-known objects that are defined for all
systems implementing OStatus. It is the Targeting Spec that defines the
syntax but the OStatus spec that defines the meaning.

Since Activity Streams is merely a serialization format and not a
messaging or notification protocol I think this is the right separation
of concerns.

[Laurent-Walter Goix]

I have a follow-up question on the alias part: whose alias is the
target referring to? The actor's alias? Or the one where the activity
is posted (eg in opensocial posting on someone else's stream). In the
case the group of followers for example may be different. But maybe
this has already been addressed at that time: James could you point to
that thread?

What would be the semantic difference between using this alias into a
single "target" or into a "to"? I understand there may be multiple to
whilst there may be at most one target. Is this difference related to
some default behaviour like evan was mentioning? Eg target only goes
there, whilst the 'to' is more like a mention than an exclusive/
restricted set of recipients?

Also, my apologies if I missed it but is there any atom counterpart of
this extension? (eg for pubsub or salmon)

Walter

On 5 mar, 18:07, James M Snell <jasn...@gmail.com> wrote:

[Bob Wyman]

Unfortunately, examples "teach" as much, if not more, than does specification text. Thus, I'm concerned that readers of the specification will come to the faulty conclusions based on the specific examples you provide. Consider the following slight modifications to the examples:

• Readers might concluded that a tag URI that only specifies year is sufficient when identifying individuals... This would be unfortunate. Would you consider wasting a few bytes to expand the temporal specificity of the tag URIs to at least provide "day of year" resolution? For instance, instead of "tag:example.org,2011:bob" use "tag:example.org,2011/08/18:bob".
• It would be useful to show something other than a tag URI as an identifier. Consider, for example, a web-finger id such as acct:b...@example.com or an email identifier such as mailto:b...@example.com

bob wyman

[James M Snell]

On Mon, Mar 5, 2012 at 11:08 AM, Martin Atkins <ma...@degeneration.co.uk> wrote:
> On 03/05/2012 10:58 AM, Bob Wyman wrote:
>>
>> If the intent is to submit this draft to the IETF, then I would suggest

Not IETF... published on activitystrea.ms website... under OWFa terms...

>> that Section 4 (The "Alias Object") needs additional work. My concern is
>> that IETF documents are supposed to facilitate inter-working between
>> systems, yet, as drafted, the "alias" feature seems inherently
>> single-system in its definition and thus no useful interworking is
>> possible.

The alias is necessarily system-specific. Martin's response is right
on, the alias is to allow references to semantically well-known
objects, e.g. "a group of friends", "a group of followers", "everyone
in the world", etc. Specifications such as OStatus or OpenSocial can
define the specific alias values or they can be defined by specific
systems. As far as the syntax is concerned, the specific meaning and
use is not important.

>
>
> I suppose it depends on what you mean by "system".
>
> The intent as I understood it was to define a syntax for referring to
> "well-known" objects, but leave the definition to be defined by other
> specifications.
>
> So, to take an example, OStatus (a protocol that builds upon Activity
> Streams) can define a set of well-known objects that are defined for all
> systems implementing OStatus. It is the Targeting Spec that defines the
> syntax but the OStatus spec that defines the meaning.
>
> Since Activity Streams is merely a serialization format and not a messaging
> or notification protocol I think this is the right separation of concerns.
>
>

[James M Snell]

I'm not sure I follow the question... for the most part, the system
processing the activity is responsible for interpreting the value of
the alias based on whatever context information it has available and
the specific definition it assigns to the alias. For instance, if I
said:

POST /foo HTTP/1.1
Host: example.org
Authentication: bearer 213123123
{
"to" : [ {"alias":"@friends"} ],
"actor" : [ {"alias":"@me"} ],
"object" : {"objectType":"note","content":"foo"},
"verb" : "post",
"target" : {"objectType":"wall","id":"http://example.org/wall/foo"}
}

The system receiving this has to make a determination about whether it
understands what "alias":"@friends" means within the context of this
request. It's up to the system to figure that out but in general, the
reasonable interpretation of this post is that the @friends will be
interpreted as my group of friends as known to the system. If the
system is unable to determine the meaning of "@friends" it can choose
to reject the POST.

Use of alias is necessarily system specific because it will be up to
the system to interpret the alias and link that back to a concrete
object.

- James

[James M Snell]

Ok.. I can make these changes.

[Bob Wyman]

James,

I have been assuming, perhaps incorrectly, that Activity Streams can be aggregated. By this I mean that we should be able to construct the equivalent of the synthetic feeds familiar to RSS and Atom users. These feeds would combine together the content of many streams into one or more synthetic streams. But, when reading your comments and those of others, I can't help thinking that when you say things like "it can choose to reject the POST" that you are only interested in point-to-point data exchange (i.e. the sort of stuff that is modeled by a single POST) rather than the potentially multi-hop distribution of data that we work with in the world of syndicated feeds.

Am I wrong in thinking that I should be able to aggregate and syndicate Activity Streams? The reason I ask is that if I can, in fact, aggregate them, then I also assume that I can aggregate or syndicate the aggregations. The result will be that the processor of any particular activity may not have much information about the system that actually generated any particular activity and thus not have enough context to be able to determine the scope of an identifier. 

I tend to think it would be unfortunate if we can't, in fact, syndicate activities in the same way we do Atom entries. There are many cases where it seems like it would be useful to do so. 

bob wyman

[Martin Atkins]

On 03/05/2012 12:32 PM, Bob Wyman wrote:
> James,
> I have been assuming, perhaps incorrectly, that Activity Streams can be
> aggregated. By this I mean that we should be able to construct the
> equivalent of the synthetic feeds familiar to RSS and Atom users. These
> feeds would combine together the content of many streams into one or
> more synthetic streams. But, when reading your comments and those of
> others, I can't help thinking that when you say things like "it can
> choose to reject the POST" that you are only interested in
> point-to-point data exchange (i.e. the sort of stuff that is modeled by
> a single POST) rather than the potentially multi-hop distribution of
> data that we work with in the world of syndicated feeds.

I think it's valid to say that the "alias" feature is a point-to-point
one: it relies on some shared context between the sender and the recipient.

The use-cases around aliases are largely about eliding some data that is
already known to both sender and recipient as a form of data
compression. I'd expect that if that data were then re-published it
would either have the alias objects expanded into the underlying
fully-qualified object or there would be a different set of aliases that
is meaningful for that second hop.

> Am I wrong in thinking that I should be able to aggregate and syndicate
> Activity Streams? The reason I ask is that if I can, in fact, aggregate
> them, then I also assume that I can aggregate or syndicate the
> aggregations. The result will be that the processor of any particular
> activity may not have much information about the system that actually
> generated any particular activity and thus not have enough context to be
> able to determine the scope of an identifier.

In the general yes, it is possible to aggregate activity streams.

For aliases I expect that the aliases would be resolved and replaced
with the underlying object before re-publishing, unless the publisher
knows (based on a contract established by a higher-layer protocol) that
the recipient will be able to understand the aliases.

[Bob Wyman]

On Mon, Mar 5, 2012 at 4:12 PM, Martin Atkins <ma...@degeneration.co.uk> wrote:

On 03/05/2012 12:32 PM, Bob Wyman wrote:

James,
I have been assuming, perhaps incorrectly, that Activity Streams can be
aggregated. By this I mean that we should be able to construct the
equivalent of the synthetic feeds familiar to RSS and Atom users. These
feeds would combine together the content of many streams into one or
more synthetic streams. But, when reading your comments and those of
others, I can't help thinking that when you say things like "it can
choose to reject the POST" that you are only interested in
point-to-point data exchange (i.e. the sort of stuff that is modeled by
a single POST) rather than the potentially multi-hop distribution of
data that we work with in the world of syndicated feeds.

I think it's valid to say that the "alias" feature is a point-to-point one: it relies on some shared context between the sender and the recipient.

The use-cases around aliases are largely about eliding some data that is already known to both sender and recipient as a form of data compression. I'd expect that if that data were then re-published it would either have the alias objects expanded into the underlying fully-qualified object

Sometimes, when you use an alias, it isn't just to provide a short-hand or compressed encoding for a longer list, but rather the intention is to hide the actual data behind an obscuring indirection. (It can be useful to know that I copied something to "my_friends" or to "foobar" even if you don't know who they are and even if I don't want you to know who they are.) Thus, even if a receiver of an activity containing an Alias Object knew how to expand that object, it might not always be appropriate to do so. This is one reason why many systems have relied on using scope indicators on identifiers instead of requiring that downstream processors rewrite the identifiers. The provision of a scoping value allows for the eventual definition of a method by which the maintainer of the alias can be interrogated about its expansion and can thus make decisions concerning who can and cannot access the expansion.

 

or there would be a different set of aliases that is meaningful for that second hop.

Am I wrong in thinking that I should be able to aggregate and syndicate
Activity Streams? The reason I ask is that if I can, in fact, aggregate
them, then I also assume that I can aggregate or syndicate the
aggregations. The result will be that the processor of any particular
activity may not have much information about the system that actually
generated any particular activity and thus not have enough context to be
able to determine the scope of an identifier.

In the general yes, it is possible to aggregate activity streams.

For aliases I expect that the aliases would be resolved and replaced with the underlying object before re-publishing, unless the publisher knows (based on a contract established by a higher-layer protocol) that the recipient will be able to understand the aliases.

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.

To post to this group, send email to activity-streams@googlegroups.com.
To unsubscribe from this group, send email to activity-streams+unsubscribe@googlegroups.com.

[James M Snell]

Bob,

Perhaps if alias were defined as either a path segment or fully qualified uri? Would that address the concern? The single path segment would allow for the simplified "@whatever" pattern that is resolved relative to some system specific context and the full uri option would allow for scoping as you suggest.

To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.

[Bob Wyman]

I realize that this comment may be considered a bit too abstract to motivate a change... Nonetheless:

This specification is clearly influenced by experience with existing distributed, push-based message routing systems. This is seen in the choice of To:, CC:, etc. keywords as well as in the fact that members of the intended audience are identified with the kind of unique identifiers that are typical of messaging systems. 

However, it seems to me that activities will not always be "pushed" but will sometimes be "pulled." (A system designed for "pull" processing would be different, I think). Also, my guess is that those who target activities will not always be able to enumerate all those in their intended audiences (even with the help of distribution-list like aliases.) Note: This is a general concern that I've had with email addressing ever since I implemented my first email system back in 1980...

Often, what I would like to do is create a message which is targeted to anyone who has some "quality" or "attribute" where that attribute is something other than a personal identifier. For instance, if I create the activity "Observed a fire at 85th St. and Lexington Ave!," I might want the audience for that activity to be "Anyone now within one mile of 85th and Lexington Ave." This is addressing based on an attribute of the intended audience members, rather than just just the "name" or "address" attribute of the audience members. It is also addressing based on an attribute that may be constantly changing. Certainly, it would be possible for some system to implement a set of Alias Objects that are modified whenever people move from place to place, however, that would be relatively gross. I would rather have some more general method of specifying audience selectors that supported, as a subset, a means of identifying a well-known predefined list as well as sets of "addressees" based on their qualities.

The desirability of "addressing by qualities" of the audience rather than the identities of audience members increases as we begin to consider the kind of pull-based message retrieval that happens when we store data and later "search" for it. For instance, I might create an activity that announces that I've "Created a new code for prospective search" and I want my audience to be "C++ Programmers." Well, it might serve my immediate purpose if I defined my audience as everyone currently on some actively maintained "C++ List". However, membership in that list is likely to change over time and thus those who search for relevant activities in the future might not be considered part of the audience unless they were on the original list or unless someone has been faithfully maintaining the list. (This would be a very real concern if aliases were "expanded" when activities transited system boundaries.) In this case, it would be much better for me if my reference to "C++ programmers" meant "Anyone with the C++ Programmer badge in their profile" rather than simply "anyone on the named list."

it should be obvious as well that there are times when I'd like to be able to define my audience selector as: "C++ Programmers living or working in New York City" which would require a bit of Boolean logic applied to various attributes values...

What this all boils down to is that I suggest that while the "Alias Object" might be a fine solution to the specific problem considered by the author, it may be non-optimally general in its ability to address other needs that either exist but weren't considered or that might arise in the future. The result might be unnecessary complexity in the future if someone finds that they need to define yet-another-spec in order to provide for "addressing by qualities" rather than just "addressing by identifier."

What I'd like to suggest is that you replace "Alias Object" with an "Audience Selector Object" that supports "Alias" as one member of a set of selector types.

bob wyman

[James M Snell]

Bob,

Note that, in the targeting spec, the to, cc, bcc and bto properties
are defined in terms of an array of Objects... meaning any type of AS
Object, not just people or groups. Imagine, for instance, we someone
were to define a "Filter" objectType that did precisely the kind of
thing you're suggesting... e.g.

{
"to": [
{"objectType":"filter",
"objectTypes":["person"],
"filters":[
{"objectType":"place",
"position":"+12.123+123.123",
"radius":"10",
"radius-unit":"miles"}
]
],
...
}

This would be a perfectly valid use of the audience targeting
extensions and makes the mechanism extremely flexible long term. Of
course, standardization of the objectTypes would be most desirable but
that's a separate issue from the syntax.

- James

[Bob Wyman]

On Mon, Mar 5, 2012 at 6:28 PM, James M Snell <jas...@gmail.com> wrote:

Bob,

Note that, in the targeting spec, the to, cc, bcc and bto properties
are defined in terms of an array of Objects... meaning any type of AS
Object, not just people or groups. Imagine, for instance, we someone
were to define a "Filter" objectType that did precisely the kind of
thing you're suggesting... e.g.

{
 "to": [
   {"objectType":"filter",
    "objectTypes":["person"],
    "filters":[
      {"objectType":"place",
       "position":"+12.123+123.123",
       "radius":"10",
       "radius-unit":"miles"}
    ]
 ],
 ...
}

This would be a perfectly valid use of the audience targeting
extensions and makes the mechanism extremely flexible long term. Of
course, standardization of the objectTypes would be most desirable but
that's a separate issue from the syntax.

Thanks for correcting me. Yes, I can see how the missing element isn't in your spec but rather lies in the absence of a "Filter" object. If we had a "Filter" object, then the value of the Targeting properties could include objects that *describe* a person or individual instead of the objects that merely *represent* a person or individual as in your current text.

I suspect that such a Filter Object would have utility in many more contexts than just this one.

bob wyman

[James M Snell]

Yes..  Yes it would.

[James M Snell]

Ok... Updated draft based on the feedback given here..

http://activitystrea.ms/specs/json/targeting/1.0/

Specific updates:

- Language that clarifies that any objectType can be used.
- Define "alias" as either a single path segment or fully qualified IRI
- Language that warns that the use of single path segment aliases are
ambiguous and are recommended only when the communicating parties
share a common understanding of their meaning.
- Language clarifying that there is no spec-defined default primary or
second audience in the absence of targeting properties.

- James

[Laurent-Walter Goix]

thank you james for the update that greatly improves the spec.

the fully-qualified iri as group "alias" resolves the ambiguity issue
so that it becomes clear whose "friends" (or other) i am talking
about, also in a distributed context. As a side question in this case
would it make sense to reuse the standard "id" property and keep alias
only for this "non uri"/ambiguous value?

if i understood the new wording properly:
- the case of Evan's related to "mentions" is covered by using the
"to" property to draw attention
- the other case related to "restricted distribution" of content is
covered using the "bto" (or "bcc") property that would automatically
make the specific activity accessible *only* to that audience. in this
case it would be essential that recipients (eg servers) of activities
containing this extension do support it indeed, in order to avoid
privacy issues when storing/forwarding that activity and make it
available to others

am i right?

thank you again
walter

On Mar 6, 1:26 am, James M Snell <jasn...@gmail.com> wrote:
> Ok... Updated draft based on the feedback given here..
>
> http://activitystrea.ms/specs/json/targeting/1.0/
>
> Specific updates:
>
> - Language that clarifies that any objectType can be used.
> - Define "alias" as either a single path segment or fully qualified IRI
> - Language that warns that the use of single path segment aliases are
> ambiguous and are recommended only when the communicating parties
> share a common understanding of their meaning.
> - Language clarifying that there is no spec-defined default primary or
> second audience in the absence of targeting properties.
>
> - James
>

> On Mon, Mar 5, 2012 at 4:18 PM, James M Snell <jasn...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Yes..  Yes it would.
>
> > On Mar 5, 2012 4:17 PM, "Bob Wyman" <b...@wyman.us> wrote:
>

> >>> > On Mon, Mar 5, 2012 at 11:02 AM, James M Snell <jasn...@gmail.com>

[Daniel E. Renfer]

I think it's best not to conflate targeting a user as a recipient of a
message with ACL rules for that same message. Adding recipient
information to an activity should indicate that that message should be
delivered to those recipients (in addition to normal routing rules) and
that that post should have a slightly higher visibility than the normal
post.

If I @-reply a user, they automatically are pushed a copy, and depending
on the system, are sent an email notification, have a pop-up message
displayed, or have that message routed to special purpose streams. (A
user's "mentioned" feed)

So you would only cc the "public" stream if you wish that message to be
brought to the attention of all the subscribers of that stream.

Assuming I see an alias in an activity, how would I discover more
information about that group? This may be out of scope, but would there
be something similar to webfinger lookup that would allow me to get the
meaning of the alias? Enumerating the users in that group can be
problematic for the reasons Evan stated. (Good luck listing all the
followers of identi.ca's public stream.)

[James M Snell]

On Tue, Mar 6, 2012 at 3:41 AM, Laurent-Walter Goix
<laurentwa...@gmail.com> wrote:
> thank you james for the update that greatly improves the spec.
>
> the fully-qualified iri as group "alias" resolves the ambiguity issue
> so that it becomes clear whose "friends" (or other) i am talking
> about, also in a distributed context. As a side question in this case
> would it make sense to reuse the standard "id" property and keep alias
> only for this "non uri"/ambiguous value?
>

The "id" property would be used to express a specific globally unique
id for a particular item, while the "alias" is intended to express a
well-known "common" label that may necessarily be unique in it's own
right. For instance, within the OpenSocial standard, there's a notion
of using the @me and @friends labels within a URI... Imagine the
following case:

{
"to": [
{
"objectType":"group",
"id":"http://example.org/api/groups/abc123xyz456",
"alias":"http://example.org/api/people/@me/@friends"
}
]
}

This example is a bit contrived as there generally wouldn't be much of
a need to specify both the id and alias in a single object like this
within the "to" property, but it illustrates the point. The @me in the
URI is dependent entirely on the authentication context. The group
represented by the alias "http://example.org/api/people/@me/@friends"
has a distinct globally unique id
"http://example.org/api/groups/abc123xyz456". Given a different
authenticated user, the same alias could map to a different globally
unique id.

[James M Snell]

On Mon, Mar 5, 2012 at 9:31 AM, Daniel E. Renfer <duck1...@gmail.com> wrote:
> I think it's best not to conflate targeting a user as a recipient of a
> message with ACL rules for that same message. Adding recipient
> information to an activity should indicate that that message should be
> delivered to those recipients (in addition to normal routing rules) and
> that that post should have a slightly higher visibility than the normal
> post.
>
> If I @-reply a user, they automatically are pushed a copy, and depending
> on the system, are sent an email notification, have a pop-up message
> displayed, or have that message routed to special purpose streams. (A
> user's "mentioned" feed)
>
> So you would only cc the "public" stream if you wish that message to be
> brought to the attention of all the subscribers of that stream.
>

+1 to all this...

> Assuming I see an alias in an activity, how would I discover more
> information about that group? This may be out of scope, but would there
> be something similar to webfinger lookup that would allow me to get the
> meaning of the alias? Enumerating the users in that group can be
> problematic for the reasons Evan stated. (Good luck listing all the
> followers of identi.ca's public stream.)

This is out of scope for this particular spec. Other specifications
that define aliases (e.g. OpenSocial with it's notions of @friends,
@all, etc) can provide means of resolving those aliases back to their
specific aliased objects. E.g. hypothetically, if I'm using OpenSocial
(just for example) and I have an "alias":
"http://example.org/api/people/@me/@friends".. then I would know to
use whatever mechanism OpenSocial provides for resolving information
about that particular alias.

- James

[Laurent-Walter Goix]

On Mar 6, 4:50 pm, James M Snell <jasn...@gmail.com> wrote:
>
> The "id" property would be used to express a specific globally unique
> id for a particular item, while the "alias" is intended to express a
> well-known "common" label that may necessarily be unique in it's own
> right. For instance, within the OpenSocial standard, there's a notion
> of using the @me and @friends labels within a URI... Imagine the
> following case:
>
> {
>   "to": [
>     {
>       "objectType":"group",
>       "id":"http://example.org/api/groups/abc123xyz456",
>       "alias":"http://example.org/api/people/@me/@friends"
>     }
>   ]
>
> }
>

that makes sense thanks.

[Laurent-Walter Goix]

On Mar 6, 4:53 pm, James M Snell <jasn...@gmail.com> wrote:

> On Mon, Mar 5, 2012 at 9:31 AM, Daniel E. Renfer <duck112...@gmail.com> wrote:
>
> > I think it's best not to conflate targeting a user as a recipient of a
> > message with ACL rules for that same message. Adding recipient
> > information to an activity should indicate that that message should be
> > delivered to those recipients (in addition to normal routing rules) and
> > that that post should have a slightly higher visibility than the normal
> > post.
>
> > If I @-reply a user, they automatically are pushed a copy, and depending
> > on the system, are sent an email notification, have a pop-up message
> > displayed, or have that message routed to special purpose streams. (A
> > user's "mentioned" feed)
>
> > So you would only cc the "public" stream if you wish that message to be
> > brought to the attention of all the subscribers of that stream.
>
> +1 to all this...

based on this it seems then that i can use "cc" for mentioning (in
addition to normal routing/distribution/audience), and "to" (or "bto")
for exclusive distribution (the only difference being that in one case
those recipients will see each other names, in the second not).
otherwise how can i address this "restricted" targeting (in lieu of
the normal routing etc)?

walter

[James M Snell]

The key difference between to and cc is that "to" identifies the
Primary Audience and "cc" identifies the Secondary Audience. The
differences can be subtle... it can also be somewhat system
specific...

If I mention you in a note posted to my wall, I would consider you to
be part of the primary audience. All of my followers are the secondary
audience... e.g.

{
"to": [ {"displayName":"Laurent-Walter Goix"} ],
"cc": [ {"alias":"@followers"} ],
"verb" : "post",
"actor": { "alias":"@me" },
"object" : { "objectType":"note","content":"..." }
"target" : { "objectType":"wall", "id":"..." }
}

If, however, I mention you in a private note I'm sending to someone
else, the intending recipient is the primary audience and you are the
secondary (like cc'ing you on an email)

{
"cc": [ {"displayName":"Laurent-Walter Goix"} ],
"verb" : "send",
"actor": { "alias":"@me" },
"object" : { "objectType":"note","content":"..." }
"target" : {"displayName":"Bob Smith"}
}

(Note that in this example, the to can be omitted since the primary
audience is implicit in the target)

In either case, you're being mentioned, but the specific way you're
targeted (to or cc) is different.

For your "restricted targeting".. I'm not quite sure I understand what
you're aiming at, but for each activity, you need to identify the
Primary and Secondary Audiences and go from there.

- James

[Bob Wyman]

Address/Targeting lists (composed of To:, CC:, etc.) are, of course, simply the push-based doppelgangers of the Access Control Lists that we often find in pull-based environments. The two concepts are semantically identical at their core: Roles are specified and processors are directed to vary message access based on role... The difference is largely found in the context of use and language used to describe the concepts -- but these are not essential differences. And, of course, whenever we have rules controlling distribution or access rights, we often have questions concerning legal rights and causes of action. This leads to at least a few questions:

• Does the Targeting spec provide all of what Activity Streams may need for Access Control? It seems to me that a more fully worked ACL specification might provide, for instance, for a variety of roles in addition to that of "primary" and "secondary" audience. One might, for instance, wish to define a "redistributor" role (Authorizing redistribution of the activity), etc.
• The spec doesn't actually explicitly say whether or not a targeted message MAY be delivered to someone not identified as a target... Does this indicate that its ACL-like functions are limited to handling of BTO and BCC cases? (i.e. The only explicit "Access Control" required in the spec concerns access to the contents of the BTO or BCC lists which "MUST" be removed.)
• Would a system that either intentionally or accidentally violated the rule that it "MUST remove addresses" be considered to have violated some "licensing" specification and thus create a legal cause of action for the publisher of the mishandled activity? (Note: See recent discussion on Google+ concerning James Snell's Link Relation types.) Does the Targeting spec tread the dangerous ground of suggesting to some that enforceable licensing semantics have been added to ActivityStreams?
• Similarly, would a system that allowed a non-targeted reader to access a targeted activity (even if BTOs and BCCs are removed) be considered to have violated some license?

bob wyman

On Mon, Mar 5, 2012 at 11:02 AM, James M Snell <jas...@gmail.com> wrote:

Ok, the Targeting Spec [1] has been out there for a while and is
stable. There are implementations available. I think it's time to put
a bow on it and call it done officially.

[1] http://activitystrea.ms/specs/json/targeting/1.0/

[James M Snell]

On Tue, Mar 6, 2012 at 9:05 AM, Bob Wyman <b...@wyman.us> wrote:
> Address/Targeting lists (composed of To:, CC:, etc.) are, of course, simply
> the push-based doppelgangers of the Access Control Lists that we often find
> in pull-based environments. The two concepts are semantically identical at
> their core: Roles are specified and processors are directed to vary message
> access based on role... The difference is largely found in the context of
> use and language used to describe the concepts -- but these are not
> essential differences. And, of course, whenever we have rules controlling
> distribution or access rights, we often have questions concerning legal
> rights and causes of action. This leads to at least a few questions:
>
> Does the Targeting spec provide all of what Activity Streams may need for
> Access Control? It seems to me that a more fully worked ACL specification

I would say definitely not...

> might provide, for instance, for a variety of roles in addition to that of
> "primary" and "secondary" audience. One might, for instance, wish to define
> a "redistributor" role (Authorizing redistribution of the activity), etc.
> The spec doesn't actually explicitly say whether or not a targeted message
> MAY be delivered to someone not identified as a target... Does this indicate
> that its ACL-like functions are limited to handling of BTO and BCC cases?
> (i.e. The only explicit "Access Control" required in the spec concerns
> access to the contents of the BTO or BCC lists which "MUST" be removed.)
> Would a system that either intentionally or accidentally violated the rule
> that it "MUST remove addresses" be considered to have violated some
> "licensing" specification and thus create a legal cause of action for the

Given that the targeting properties are optional extensions it stands
to reason that there will be plenty of Activity Streams
implementations that do not "properly" handle the bto and bcc
requirements (as is acknowledged in the Security Considerations in the
draft). Entities that are producing and sending activities with
explicit targeting information, especially using bto/bcc, need to be
aware of where they're sending those things and how they're likely to
be handled by the recipient.

The inclusion of targeting properties is not a restriction as to who
can see the activity. It's metadata that helps software figure out how
to intelligently route and handle the activity (e.g. who to notify,
how to notify, etc). If I POST a targeted activity to a public,
world-readable stream that does not support the targeting properties,
then I need to expect that everyone in the world is going to be able
to see it...

> publisher of the mishandled activity? (Note: See recent discussion on
> Google+ concerning James Snell's Link Relation types.) Does the Targeting
> spec tread the dangerous ground of suggesting to some that enforceable
> licensing semantics have been added to ActivityStreams?
> Similarly, would a system that allowed a non-targeted reader to access a
> targeted activity (even if BTOs and BCCs are removed) be considered to have
> violated some license?

No. Absolutely not.

[James M Snell]

Ok.. I've expanded the discussion in the spec a bit...
---
Implementations are free to use what they know about an activity's
Primary and Secondary audiences to determine access, change and
redistribution controls for the activity (e.g. limiting who is able to
see the activity). However, the mere presence of targeting properties
does not imply that distribution of the activity is limited to only
explicitly targeted entities. Audience targeting information included
within an Activity using these mechanisms is intended only to express
the intent of the entity creating the activity. With clear exception
given to the appropriate handling of "bto" and "bcc", this
specification leaves it up to individual implementations to determine
how the audience targeting information is to be utilized. Further, in
the absence of any targeting information within an Activity, this
specification does not define any default primary or secondary
audience. The selection of default primary or secondary audiences is
solely at the discretion of the implementation.
---

Basically, this leaves access control entirely up to the
implementation. The targeting properties express the original intent
of the creator, but they don't restrict distribution.

- James

On Tue, Mar 6, 2012 at 9:05 AM, Bob Wyman <b...@wyman.us> wrote:

[Bob Wyman]

LGTM, Thanks.

[Laurent-Walter Goix]

+1

As i need to identify private activities, iwouldrather use target
alias @me than any of the targeted audience properties in that case...

Walter

On 6 mar, 18:59, Bob Wyman <b...@wyman.us> wrote:
> LGTM, Thanks.
>

> > > On Mon, Mar 5, 2012 at 11:02 AM, James M Snell <jasn...@gmail.com>

[Laurent-Walter Goix]

> As i need to identify private activities, iwouldrather use target
> alias @me than any of the targeted audience properties in that case...

ok i realized that this does not work either. my use case is really
about acl...
i do want to define the privacy level of the content i post. using the
"target" is no good idea as i could post to an album (target) but
still would like to have some way to indicate that this picture is
restricted to my best friends only, my family, etc and not to all my
followers (or even public to the world)

it seems that neither AS, nor OpenSocial spec has the solution at this
stage: in AS he closest i can get is if the "to" is used as exclusive
audience (not "in addition to the default", unless the default is
"private" :) ). in OS it may be POSTing to other than @self, but this
is limited too...

any hint on how to solve this?
thanks
walter

PS: since the to/bto/cc/bcc is quite distinct from the "alias"
concept, would it make sense to split the spec in 2? or make the alias
part of a new version of the core spec?