Re: AS = Status+Updates?

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.

> Thinking about Activity Streams in light of this last meeting, where I
> finally came to understand the role it plays in Activity Pump, I'm wondering
> 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 state
> of the world.  I think it might be good to instead have a way to describe
> 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 status.
>

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 minimal
> value in separating them.   But when you think about fixing a typo in a
> Note, and how you propagate that change, and who should be sent that change,
> 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 happens
> 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.  Those
> 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 think
> ActivityPump envisions).   The federation protocol can largely consist of of
> sending around Updates.   The updates can also be kept around as a change
> 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 very
> simple systems.   The payoff doesn't come until you want ACLs or federation
> or something else non-trivial.    Beyond that, are there are other problems
> with this style?
>
> My apologies if I'm missing something obvious that makes this clearly a bad
> idea.
>
>      -- Sandro
>
>

Received on Thursday, 7 May 2015 15:11:53 UTC