Re: AS = Status+Updates?

I think this is a great way of thinking about things. Another way of
phrasing it is the primary purpose of the API is to do basic CRUD
operations to modify the state of the system. (For example, adding a new
note, or adding a follower, modifies a collection). The effect of the CRUD
operation is that it generates an activity, which has its own URL. The
activity is the thing that allows the other servers to sync this data. The
activities act as a changelog on the data. Does this sound like a
reasonable summary?

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>


On Thu, May 7, 2015 at 3:10 PM, Sandro Hawke <sandro@w3.org> wrote:

> Summary:  it might be good to re-organize AS2 to separate the CRUD
> operations from the "social" vocabulary
>
> 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.
>
> 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
>
>
>