Re: ActivityPump API

On 9/21/12 9:17 AM, Evan Prodromou wrote:
> On 12-09-20 05:15 PM, Kingsley Idehen wrote:
>> On 9/20/12 5:06 PM, Evan Prodromou wrote:
>>> On 12-09-20 05:01 PM, Kingsley Idehen wrote:
>>>> How is user 'bwk' identified by the system in question? 
>>> There's OAuth 1.0 authentication; see 
>>> https://github.com/evanp/activitypump/blob/master/API.md#authentication
>>>> What about a shared outbox?
>>
>> I assume an outbox is just a collection style of resource (like a 
>> folder) for outbound data associated with a specific user, right?
> More like a stream; it's an ordered list of activities with the most 
> recent activities first.

Okay, so its still a resource associated with representation, bottom line.

>
> But, yes, all stuff that has a single person as the "actor".

But, and this is important, it isn't architecturally desirable or 
feasible for "all stuff" to have a single "actor" due to identity 
modality, and ultimate implications etc.

>>> I'm a little confused on that; do you mean something like when 
>>> janeandfrank235@hotmail.com share an email address? Or more like a 
>>> group blog? Or more like a mailing list?
>>
>> More like sharing blog, mail oriented resources, basically a folder 
>> accessible to more than one identity.
> I think that an Activity Streams "group" would match more closely. 
> I've got plans to add groups in the near future, but tried to keep 
> things simple for this upcoming release.

A "group" is just another entity with its own set of characteristics. 
Identity dexterity issues don't go away just because you have a "group".

>
> In my mind, an activity sent to a group would be distributed to all 
> members of that group.

If you have a fine-grained mechanism for identifying the group and its 
members, at the core of the system.

>>>> What happens when 'bwk' seeks to temporarily or permanently 
>>>> delegate privileges to others etc?
>>>>
>>> I'm also not sure I understand what you mean here.
>>
>> How a user can enable another user act on its behalf, thereby 
>> inheriting the privileges required for outbox access etc.. Basically, 
>> like a secretarial agent authorized to act on behalf of a boss.
> That's not even close to being on my radar right now.

It doesn't have to be on your radar per se. You can use architecture to 
reduce such a burden on yourself. If there's one this to always remember 
about the Web, the system was designed to relieve TimBL and others of 
such burdens. That's the key to dexterous architecture.

>
> One thing that is close is letting people set up product or 
> organization accounts, and letting them post as that product or 
> organization. Similar to Facebook Pages or Google+'s thing, or even 
> co-tweet ability in Twitter. ("ReadWriteWeb says, 'Come check out our 
> new blog post!'"). Is that kind of what you're thinking?

Much more than that. I am trying to encourage you to put Web-scale 
verifiable identity at the core of what you do. It will reduce tax on 
time you don't have, down the line.

At this juncture, is there a particular issue that makes WebID 
problematic to you? Crack this nut once, and be done with it.
>
> -Evan
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen