- 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