I have been thinking a lot about this lately. You can see that in my writings here and in the Trello boards. Now it would be nice to have some other Ecobyterians joining the discussion.
I will now say a little to your most important points
- Collaborative Writing
- Peer Review
which both work very reliably. Further on I will go into some detail regarding
Following will be a disambiguation between Ecobytes, allmende.io and co-munity v2.
As you defined yourself, Etherpad Lite is the way to go. It’s a very easy installation process and a reliable service that can be extended by plugins. Which should be done for a professional Service like the one for Degrowth. I suppose the implementation time is around 2 to 4 hours.
If you want to have a more sophisticated approach that doesn’t lack a beautiful UI, please consider adding http://fiduswriter.org/ for real documents with annotations next to pad’ish scribbles.
As I have written in the co-munity v2 Board Peer Review Card Hypothes.is combines annotation with PDFs. I’ve now installed it and it works. Chrome users will have to install a custom-built plugin, that injects PDF.js into the browser, and/or the stock plugin (which is hard-coded at https://hypothes.is, which didn’t launch yet) + a bookmarklet. The bookmarklet works out-of-the-box in Firefox, as it’s using PDF.js internally already.
Coming with Open ID Connect is the tighter integration of authentication and authorization for different web services. These layers can be built connected to some LDAP service, some have it built in. Please refer to the Trello Card about SSO again, where I’ve collected some implementations. I suppose the best would be to rely on the Gluu stack, as it’s already available.
Again, one would need a middleware (thanks @daniel ) that propagates the desired restrictions or permissions to the applications. Also not all applications have access-controls, like Etherpad. So you will have to manage your private URIs from the OA2 frontend solely.
I’m not sure if OA/Drupal is capable of doing so. But if you hard-wire your OA2 instance to the self-deployed Open ID Connect provider only, then people wouldn’t need to provide different login credentials for any service in your grid.
This is the tricky question now, eh? Why I would also like to have Ecobyterians joining this discussion.
I have already laid out my strategy in multiple ways, but will try to resume again for easier comprehensibility. As I didn’t receive too much feedback on my work / comments / etc. on the Trello Boards, I have somewhat slowed down my productions. Otherwise you would now have access to more structural hypothesis images.
For detailed explanations, please also refer to your own research and as a starting point this Wikipedia article.
Infrastructure as a Service means you can spawn virtual machines of different size within a federated cluster of servers. Or move them. Or move storage independent of CPU. Or allocate RAM dynamically. Or create VLANs. Or run docker images.
We would need those for big applications like Groupserver, GitLab, Discourse, database servers or Seafile.
Platform as a Service means you can push application code (Node, Python, PHP, …) to your service and it will be a running program. This can be tightly integrated into Continuous Integration (CI) lifecycle processes.
This would include Etherpad, Fidus Writer, remoteStorage, Open Atrium, WordPress, …
Software as a Service is the tools we want to provide in the end.
Now the tricky part is if and how Ecobytes wants to re-setup the root servers.
Are these strong physical machines that can be transformed into an OpenStack + OpenShift cluster or do you want to keep the current systems (+ data!) and evolve a new system?
I’m here for help, practical work or guidance. But please not that I’m also an autodidact that can strongly fail.
The most interesting question for me is how you see co-munity inside this network of providers and services. Because I have the feeling that co-munity + Ecobytes is the same for you. For me it is not. Also allmende.io remains a research prototype that could slowly evolve, if MMM would have any resources left over or a big sponsorship.
If you want to have me working on this architecture and applications, please let’s go into in depth review of your concept, if there is any, and compare it with the one I’ve clicked together. Then we can say where we work together and where each one follows an own approach.
Like ownCloud, for example. I love to have multiple apps doing different things. ownCloud combines so many different ideas into one product, that it’s hard to say if it’s good or bad. Despite the fact that there are already real large scale deploys on top of this. Let’s take the calendar functionality: Seafile doesn’t have it, ownCloud does. But the Radicale server mentionned in the Seafile quote does have LDAP integration, so does Baikal. Seafile, too. It would be easy to connect CardDavMate and CalDavZap to an existing ecosystem. In a next step I could even imagine adding OpenID functionality to these lightweight web clients.
It always depends on what you want to do.