- From: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
- Date: Thu, 07 May 2015 15:30:31 +0200
- To: Sandro Hawke <sandro@w3.org>
- CC: "public-socialweb@w3.org" <public-socialweb@w3.org>
On 05/07/2015 03:10 PM, Sandro Hawke 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 tried illustrating such distinctions lately in image attached to this
gh issue: https://github.com/w3c-social/social-vocab/issues/12
IRL activities vs. Online Activities
Social Online Activities vs. API CRUD+
>
> 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 13:30:42 UTC