Re: Federated Collab Group use case draft

On 12/09/2014 05:17 AM, Bassetti, Ann wrote:
> Hi All –
> 
>  
> 
> I just made an attempt to put the Federated Collaboration Groups
> scenario
> <https://www.w3.org/wiki/Socialig/Use_Case_TF/Profile_Scenarios#Federated_Collaboration_Groups>
> into our Use Case template format: 
> 
> https://www.w3.org/wiki/Socialig/Use_Case_TF/Profile_Use_Cases/Federated_Collaboration_Groups
Awesome Ann, thank you so much for that!

I remember a lot of critique, back in OStatus days, that one can not do
much more with it than sharing pictures of cute kittens :D


> 
> There are a few things that are not right (links, justification of the
> graphic, ..) and you'll probably help improve the text.  Eager for your
> help!

"In the best situation, all participants use a common tool, into which
they easily populate their own information (profile, contact, etc) from
their own tool(s). Data that is not to be shared, does not flow. The
user does not need to know which data is approved for sharing, and which
is not -- the systems manage it."

I would like to clarify what you mean by *common tool*. I like to
compare it to email, while we all can exchange messages directly or over
mailing lists, we all have freedom to choose our favorite email clients.
http://en.wikipedia.org/wiki/Comparison_of_email_clients

Currently on a web I see very unfortunate coupling between data spaces
and human interaction interfaces. All the prototypes I currently work
with[1] use CORS heavily and expose full functionality via APIs. Then
frontend apps, which provide human interaction interface, use those
APIs. This way we get n to n relation between frontends and backends.
Crosscloud developed by Sandro and Andrei takes similar approach[2], as
well as clients using IndieWeb MicroPub[3] which Aaron will present
today during WG telecon.

[1] https://github.com/elf-pavlik
[2] http://youtu.be/z0_XaJ97rF0
[3] http://indiewebcamp.com/micropub#Clients

Received on Tuesday, 9 December 2014 08:10:38 UTC