Many people now keep in touch with their social networks (Twitter/Facebook/Buzz/etc) using mobile or desktop "third-party" client apps like Tweetdeck/Seesmic/Twitdroid/Tweetie/Flipboard etc. These apps make use of disparate APIs from all these services, and focus on making it easy and fun to monitor them all simultaneously, and cross-post where appropriate. The UI experience of these apps goes well beyond anything that the actual social network providers (Facebook/Twitter etc) can support in their "silo'd" native interfaces.

Recently attempts to create open-source versions of such social networking systems (StatusNet, Wordpress, etc) have begun coalescing on OStatus as a standard API for public updates and comments that third party client apps could interwork with, with the promise of two-way management of secured updates and comments to come. Even better, OStatus handles interworking across such systems, using federated (Webfinger) IDs. This means that, eventually, someone logged into their university's own Wordpress system could comment on someone else's post on another university's Status.net system - all using the great UI supported by their favourite third party client app.

In theory, if Cyn.in supported OStatus it could also join this club. This gives users the opportunity to use Cyn.in in the same way that they're already consuming their social web, and could open Cyn.in interactions to a legion of other users who are not even registered within Cyn.in initially, but who are trackable through their Webfinger IDs. BTW Webfinger is currently supported by Google (all "gmail.com" addresses) and Yahoo (apparently). This fits the university model very well, where researchers commonly need to discuss across institutional boundaries.

I accept that this is very hard request to fulfill. OStatus is not yet mature, and is a collection of underlying components that are also not yet mature. However the benefits of keeping track of updates from your own organisation's Cyn.in system alongside the rest of your life (Twitter, FB, etc), and interworking with other networks, would increase usage and usefulness dramatically. For these reasons I think that support for OStatus and/or its components should be considered as part of the long-term direction for Cyn.in.

We've been working on improving the Cyn.in buildout for developers (these changes are in SVN trunk right now). One of the coolest little products that we've found and included in the cynindevelop.cfg file is this one called rbco.wfdocumentator - it provides a nice display of the transition graph of the various states of a workflow. More importantly perhaps, it provides a tabular summary of all the states and permissions granted to various roles in each of the states. Permissions required to flow an object through a particular transition are also listed at the bottom.

Much easier than wading through the workflow.xml and rolemap.xml files to understand what's going on, I assure you. :)

Here's what the output for the Space Content workflow looks like:

Instructions on what else is new with the cynindevelop.cfg based buildout and how to use it are coming soon.

Hi!We are engaging another cyn.in space at the academy of fine arts in Vienna. We are using the downloaded version 3.1.1. Now when we set an internal link to an item that is only project-visible we encountered an "Insufficient Privileges" Error. I looked into the error logs and found the reason: "Unauthorized: You are not allowed to access 'title' in this contex". I looked into the code and found that in the template "links_macro.pt" the property "item/title" is being used. I was able to fix the error by using the property "item/Title" - which is accessible on a catalog object. Here's the patch, i hope you can apply it for future versions!

I am Georg Gogo. BERNHARD. I've been playing with plone since i saw it being presentet 2002 at the EuroPython in Charleroi, Belgium. Now I am working at the ]a[ academy of fine arts vienna. I tweeted about our recent ambitions to test cyn.in and @viraf asked me to share our experiences at the #cynapse community pages.

First I thought that there would be a lot to say about which problems we had and how we solved them, but it fact the whole procedure was pretty easy. We already have a ZEO-Cluster setup for the homepage (http://www.akbild.ac.at) and we re-used the infrastructure for cyn.in.

Our Team tested the cyn.in Desktop and WebDAV, everything works pretty well. On Apple Computers we have to use Cyberduck for WebDAV, though; the Operating Systems implementation (Finder) does not work well. We also decided not to "roll out" the Desktop and WebDAV now, because we think it is too complicated for people to actually use it since they "see too many things" in their respective clients - it might be confusing for regular users. In our opinion downstripping is still key.

Language integration for German is not finished and we don't have the resources to complete it ourselves.

When we finally presented cyn.in as a solution for collaboration we had excellent responses. People found it confusing at first sight [sic!] but then realized that it is easy to use since you'd only use some of its functions. We will definitively use it for two pilot projects now, one is a construction project for one of our buildings, the other project is internal communication in a department.

To sum things up: cyn.in seems to be the solution we were looking for.