Re: AS = Status+Updates?

Yes I believe we were actually referring to the ActivityPump API

On Thu, May 7, 2015 at 5:12 PM 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.
>
> > 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
> >
> >
>
>