- From: Harry Halpin <hhalpin@w3.org>
- Date: Wed, 04 Feb 2015 19:02:23 +0100
- To: Evan Prodromou <evan@e14n.com>, "henry.story@bblfish.net" <henry.story@bblfish.net>
- CC: "public-socialweb@w3.org" <public-socialweb@w3.org>
On 02/04/2015 02:54 PM, Evan Prodromou wrote:
> On 2015-02-04 06:01 AM, henry.story@bblfish.net wrote:
>> So all the user stories currently could be user stories for totally
>> siloed social networks.
Also, note that the API does not itself have to deal with federation,
just be a generic API for social use-cases and
consuming/displaying/using ActivityStreams 2.0. Again, see charter.
Federation will be a separate protocol, as noted in the charter. Since
the deliverables will be ran at the same time, we can later modify the
API to take into account federation as needed.
cheers,
harry
>>
> YES. That is exactly the case.
>
> The difference is when you get to the developer stories. Those describe
> some unique advantages of using a standard API between client and server.
>
> If you'd like I can make this more explicit in the user cases.
>> We could extend the user stories to make them more clearly cross
>> organisational.
> That would be a grievous mistake at this point.
>
> We have as one of our deliverables a federation protocol. Our social API
> is the client-to-server piece; the federation protocol is the
> server-to-server piece.
>
> We should make a point of not putting forward a social API that isn't
> compatible with federation. However, it should not be dependent on
> federation.
>
> -Evan
>
>
>
>
Received on Wednesday, 4 February 2015 18:02:36 UTC