W3C home > Mailing lists > Public > public-socialweb@w3.org > May 2015

AS = Status+Updates?

From: Sandro Hawke <sandro@w3.org>
Date: Thu, 07 May 2015 15:10:39 +0200
Message-ID: <554B644F.4060506@w3.org>
To: "public-socialweb@w3.org" <public-socialweb@w3.org>
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
Received on Thursday, 7 May 2015 13:10:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:17 UTC