W3C home > Mailing lists > Public > public-socialweb@w3.org > May 2015

Re: AS = Status+Updates?

From: Sandro Hawke <sandro@w3.org>
Date: Fri, 08 May 2015 09:36:56 +0200
To: James M Snell <jasnell@gmail.com>
CC: "public-socialweb@w3.org" <public-socialweb@w3.org>
Message-ID: <A927BBD8-5A0D-46CF-B9E7-01ADE9E3302F@w3.org>
On May 7, 2015 5:11:01 PM CEST, James M Snell <jasnell@gmail.com> wrote:
>On Thu, May 7, 2015 at 6:10 AM, Sandro Hawke <sandro@w3.org> wrote:
>> Summary:  it might be good to re-organize AS2 to separate the CRUD
>> operations from the "social" vocabulary
>AS2 does not have any CRUD operations.
>When I send something like the following to a server, I'm notifying
>not instructing:
>  POST / HTTP/1.1
>  Host: example.org
>  Content-Type: application/activity+json
>  {
>    "@type": "Follow",
>    "actor": "acct:joe@example.org",
>    "object": "acct:sally@example.org"
>  }
>Depending on the server, there might be some side effects that occur
>after receiving the POST, but the AS2 payload itself does not carry
>any behavioral semantics or expectations whatsoever.

I understand that.  I think my use of the term CRUD was misleading.

Consider the difference between:

1. Write this down: At 9am Sandro got on the train to the airport
2. At 9am Sandro got on the train to the airport
3. At 8:59am Sandro was at the train station.  At 9:01am, Sandro was on the train to airport.

I believe you're saying that AS is like 2, not like 1.    I completely agree, and I see how the term "CRUD" suggests 1.

I'm suggesting that there might be an advantage to switching to style 3, especially when we consider more complex use cases, such as corrections, changing who is in a target group, robust federation, and extensibility.  It also appeals to my inner MVC coder.

Does this make more sense now?   If not, maybe you can suggest an AS user story and I can show how the walkthrough would be different with this change.   (when I'm not on a train to the airport)

     - Sandro

>> Thinking about Activity Streams in light of this last meeting, where
>> finally came to understand the role it plays in Activity Pump, I'm
>> if it would be good to change the design in a fundamental way.  I'm
>sorry I
>> didn't understand this well enough to say it months ago.
>> Right now, as I understand it, an Activity describes a change in the
>> of the world.  I think it might be good to instead have a way to
>> the state of the world and a separate way to talk about state
>changes.  We
>> could frame it like this:
>>  * A "status" is a post which states something about the world at
>some point
>> in time.
>>  * An "update" is a post which creates, modifies, or deletes a
>It makes sense to create such distinctions within the API but not the
>AS2 spec itself.
>- James
>> In the common case where one is just creating a new status, there's
>> value in separating them.   But when you think about fixing a typo in
>> Note, and how you propagate that change, and who should be sent that
>> and who is allowed to see that change, and how to efficiently
>distribute the
>> change, and who has permission to make the change, ..., and what
>> when a server is down and changes can't be sent right now, ... then I
>> suspect things become a lot simpler when we separate them.
>> The "social API" then can consist of doing CRUD on status resources. 
>> CRUD operations might be done by creating updates (something like
>> update/delete in micropub) or more directly using http verbs as in
>LDP or a
>> whole bunch of them might be streamed in a JSON-LD document (as I
>> ActivityPump envisions).   The federation protocol can largely
>consist of of
>> sending around Updates.   The updates can also be kept around as a
>> log.
>> I'm interesting in spelling this all out in more detail if others
>think it's
>> promising.
>> I suspect the pushback will be that it's somewhat harder to implement
>> simple systems.   The payoff doesn't come until you want ACLs or
>> or something else non-trivial.    Beyond that, are there are other
>> with this style?
>> My apologies if I'm missing something obvious that makes this clearly
>a bad
>> idea.
>>      -- Sandro
Received on Friday, 8 May 2015 08:47:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:17 UTC